DME 5.0 by Soliton Systems

DME, now owned by Soliton Systems is the leading provider in secure device management with clients throughout the world. DME (Dynamic Mobile Exchange) is an application for corporations and governments to securely exchange information and separate work and personal communication. In addition, DME allows clients to securely move files between devices and the corporate network. DME gives clients the power to protect company assets by allowing remote wipe of user’s work data.

My role in designing DME 5.0

  1. Worked closely with management and the rest of the team to understand important business goals, deadlines, engineering and infrastructure limitations.
  2. Explored solutions for DME 5.0 within the realms of conventional interfaces, for reasons involving timelines and engineering limitations.
  3. Extensive prototyping in Origami Studio to test and validate design decisions.
  4. Worked closely with engineering in providing implementation assistance. Provided detailed specifications of implementation details, along with prototypes to better communicate how a feature should be built.
  5. Provided extensive feedback to engineering on internal builds and was available to answer any questions in connection to how the interface should be built.

Version 4.0 — How its usability issues hindered its place in the market

  1. DME 4.0 relied heavily on vague iconography causing usability issues for users. Icons don’t scale well across different countries with different cultures and this was evident in the usage patterns for the app.
  2. The product was unintuitive and the way the app handled navigational hierarchy was a critical factor. The way the app transitioned users into parts of the UI was different and proved difficult for users to orient themselves in the UI.
  3. Version 4.0 of the app didn’t reflect today’s software in terms of aesthetics and this affected the way people thought of the app. It didn’t inspire confidence in buyers that the app was a secure way to exchange communications.
  4. By designing solutions to solve important issues like making core functionality clearer in the interface to the modernization the UI. All these efforts made for a better DME. A DME that is a more competitive product in the market and a product that is well received by customers all around the world.

Case Study

If you’re interested in learning about the design process for DME 5.0, feel free to keep scrolling. I go really in-depth and discuss designing inclusive software, how constraints influenced every design decision, trade-offs, prioritization, the use of hierarchy to provide context and more. It’s long and I don’t expect you to read it all, no hard feelings. You can scroll to see prototypes and sketches. If you have any questions or want to say hi, email me.

Designing an inclusive product — how characteristics in language systems influenced the design process

  1. Understanding the customer base and requirements meant understanding the need to design an inclusive product.
  2. Designing with the requirement of 13 localizations in mind was an important part of the design process. Designing for 13 different language systems and future localization goals meant understanding how different language systems influence layout, hierarchy in the interface and how languages like Hebrew and Arabic influence layout through its right-to-left writing system.
  3. An important consideration and one that influences the interface is how we convey hierarchy in our UI. The support for font-weights is not universal across languages and if colors and proper spacing isn’t well established in the interface, hierarchy can be lost.
  4. Other characteristics that influenced DME were languages like Korean. The Korean alphabet, known as Hangul relies on digraph. Digraph is the pairing of characters. Languages like Korean need larger text-sizes to be legible and it’s absolutely necessary on lower resolution displays.

Inclusivity goes beyond localization — how designing for the billion people that have a disability shaped design decisions

  1. Inclusive design means designing an accessible product that anyone can use. 1 billion people world wide have some kind of disability and 1 in 12 men in the world are color blind.
  2. Some of the efforts in designing an accessible product include using adequate contrast ratios for the use of text.
  3. In addition, destructive operations carry a heavier font-weight, along with a different color to communicate the difference between delete and other options. A user with a visual impairment will have an easier time distinguishing between an option with a regular font-weight and one with a different color and a heavier font-weight.
  4. Communicating unread and flagged emails with a badge and color alone is not the accessible product I want to ship. Users with achromatopsia will have a really difficult time distinguishing between the two. Using an icon with the shape of a flag to handle flagged emails is a much more accessible solution. This solution looks different and doesn’t simply rely on colors to convey its meaning.

Designing Mail for iOS and Android — How the use of design conventions was critical to staying inside our set of constraints

  1. Goals were straightforward: design a modern and intuitive experience that is able to compete in today’s market within our set of constraints.
  2. Engineering resources were tight and budgets didn’t allow for custom, unfamiliar design patterns and extensive research to support a potentially inferior solution.
  3. @uberbryn on Twitter said it best

Why the use of design conventions fit our needs — and how it helped the team stay inside our set of limitations

  1. Management, the team and my self included wanted an experience that is familiar to users in accordance with the platform they’re using. Relying on established patterns reduces any ambiguity the user might have about how a particular feature works.
  2. The team was mostly constrained by engineering resources and timelines. There wasn’t enough time to test and validate foreign and unfamiliar design patterns.
  3. There’s a great body of research on the subject of diverting from established patterns and their effects. The effects of diverting from established patterns - Nielsen Group.

What failed and why — How a slight diversion from design conventions introduced unnecessary complexity

  1. One approach in communicating email states is to use a blue and orange rectangle at the edge of the screen. My reasoning behind this approach involved the pattern of colors used throughout many email apps to communicate this information.
  2. However, internal feedback yielded exactly the opposite result. The diversion from conventional forms of communication failed in this instance. A rectangle by the edge of the display was simply not clear to users what it meant and it would be a usability problem for users that have visual impairments.

How requirements and constraints mandated the use of a side menu — The use of Dynamic Type and a large list of active folders contributed to this solution

  1. Allowing extensive functionality like accessing folders and creating new folders was easier through a side menu. This applies to both user experience and engineering resources. The side menu is a recognizable pattern and it scales well for system wide functionality like Dynamic Type.

What failed and why — Why context is important in setting expectations

  1. The sketch I list below is one of the many explorations that failed. It largely failed because it was really slow to browse. An expanding menu from the navigation bar that allowed access to their mailboxes was a poor solution to the complex problem that is an email account with active folders.
  2. Providing access to app settings through the side menu was not a great idea. This is why it’s a bad implementation: when a user sees the side menu, the context in that view relates to their email. From their sent mailbox to custom folders. Tapping the settings icon with the available context, users would expect to see settings for their email, based on the available context. The settings icon instead presented settings for the app and not their email. This was a confusing experience, to say the least.

The importance of ergonomics — and how constraints influenced the solution

  1. Explanation regarding the placement of Move To and Delete near the bottom, as opposed to having all four options at the bottom.
  2. The short explanation: performance for icons communicating features like Move To perform rather poorly and a combination of text and icons doesn’t work because of the diversity of screen sizes and localization needs.

Ergonomics and compromise — Why the tool bar is limited to two options and why move to and delete are in the tool bar.

  1. Ideally, all important actions would be at the bottom where it’s easier to access them.
  2. One option is to just rely on icons to communicate important functions. Icons for features like move to are really vague and confusing. We tested a few icons for this feature and the response was not promising. Icons to communicate functionality routinely perform poorly. Nielson Group conducted a study on a university website and relying on iconography to communicate vital information yielded no interaction. Breaking Web Design Conventions = Breaking the User Experience.
  3. A combination of text and icons is another possibility but not a very practical one. Not everybody carries a Google Pixel and even if they did, increasing the font-size at a system level or translating to another language breaks the interface. There’s simply not enough room to fit every option.
  4. Prioritization was crucial in designing the best solution. Icons for reply or flag are really common and are almost identical throughout many apps. People understand these icons well. Placing these icons in the navigation bar without text made sense and in our test group, people interpreted these icons and their value well.
  5. Using icons to communicate something as complex as moving an email to another folder is much harder to do well with an icon and equally difficult for people to interpret them accurately. Our approach is to use an effective and proven solution to clearly communicate value and that is achieved through the use of text. Text is effective in removing any ambiguity the user might have. Here is a really informative article on the usability of icons by Nielsen Group: Icon Usability.

Moving emails — Using color, hiearchy and affordances to create something that is simple and obvious.

  1. The process in designing an experience that allows users to easily move email between mailboxes.
  2. The short explanation: How the user of color, hierarchy and affordances in our interface allowed for an interface that is simple and obvious.

Interface affordance, color and hierarchy

  1. Color is used in combination with hierarchy in the UI to identify the email that is to move moved. The email that is to be moved is tinted with a light blue to differentiate the email from the rest of the menus and designated to the top of the UI to emphasize the email that the user wants to move.
  2. A UI element that is used throughout the app is a tool bar that provides instruction, affordance and a feedback mechanism. I use this element to provide instruction to users when they first open this view. This tool bar serves as a feedback mechanism, too. If a user taps Junk as the destination, the tool bar will update to reflect those changes. An example of how it communicates this information: “Move email to: Junk”. As the tool bar provides feedback, it also displays a clear affordance to move the email and accomplish the task.

Ergonomics in email and necessary trade-offs

  1. Core functionality that sells this product should be easy and clear to identify in the UI. Implementing this functionality above the keyboard makes sense because it’s at a level where it’s physically comfortable to interact with, regardless of the screen size.
  2. No solution is perfect and there were trade-offs. On Android, the attachments and priority buttons are placed near the top. It’s a common pattern in the platform and performed well internally.
  3. The reasoning behind breaking away from how iOS handles this problem has to do with the set of constraints Android introduces: custom keyboards with different heights, a diverse set of screen resolutions and a diverse set of operating systems that may introduce complexity for an already constrained engineering team. It was better to use a recognizable pattern for Android and place these features in the navigation bar.

Ergonomics in email and necessary trade-offs

  1. Core functionality that sells this product should be easy and clear to identify in the UI. Implementing this functionality above the keyboard makes sense because it’s at a level where it’s physically comfortable to interact with, regardless of the screen size.
  2. No solution is perfect and there were trade-offs. On Android, the attachments and priority buttons are placed near the top. It’s a common pattern in the platform and performed well internally.
  3. The reasoning behind breaking away from how iOS handles this problem has to do with the set of constraints Android introduces: custom keyboards with different heights, a diverse set of screen resolutions and a diverse set of operating systems that may introduce complexity for an already constrained engineering team. It was better to use a recognizable pattern for Android and place these features in the navigation bar.

Why the lack of clarity was a point of failure

  1. The big selling point for DME is the ability to encrypt emails. The mechanism that handles this feature set has to be really clear to users and some of the explorations weren’t very clear. Expanding menus with vague icons performed really poorly.
  2. A superior solution is one that is clear to users about its purpose and value. The better approach is one that was accessible and fast to use. Users can attach a file by tapping once in the attachment button above the keyboard and proceed to add a file.

Securing emails — and why the use of hierarchy and context facilitates the process

  1. Providing context to users and informing them of what they are about to encrypt is critical. The more effective way to do so is to allow visual access to the email they’re about to encrypt by way of a modal view.

The use of hierarchy — and how it's used to provide context

  1. Email Details is a big feature in DME and an important feature for the business. Email Details is where customers encrypt their emails and set priority details.
  2. The reasoning behind the modal view not taking over the screen is to allow visual access to the previous view. When users access Email Details and they decide to encrypt an email, they can see exactly what they’re encrypting or prioritizing.
  3. This solution brought into question the consumption of resources and timeline constraints. It was clear that this can be achieved by using UIPresentationController on iOS.

The influence of localization requirements — and how cultural interpretations guide the use of color

  1. Localization requirements influenced the interface throughout the app and specifically how our toolbar was influenced by different language systems and cultural interpretations of color.

The use of design signifiers — and the influence of localization requirements

  1. I’d like to focus on the toolbar specifically and explain how localization requirements influenced it.
  2. Call-to-action buttons are blue accross iOS and Android and that is because DME is a product that crosses borders where different cultures interpret colors in different ways.
  3. The height of the toolbar and the button it self is designed to adapt to tall-writing language systems, larger font-sizes to accommodate languages that rely heavily on digraphs and to simply adapt to larger font-sizes at a system level.

Concluding Thoughts

Designing DME 5.0 was fun and challenging in many levels, including designing for Android, a platform I hadn’t previously designed for or even used. Designing a product so many people use is rewarding and intellectually stimulating. Having to understand how customers use this product was difficult. It went beyond localization, cultural interpretations and accessibility. It also entailed having an understanding of how the corporate world functions and their expectations. Corporate culture, specially the customer base of this product is really conservative and that, like many other variables influenced the design process. Having the opportunity to work with a great team in Denmark and Japan was a privilege. Proud of what we have all accomplished.

Special thanks to my team in 🇩🇰 and 🇯🇵

  1. Jan Johnsen — Product Manager
  2. Ricardo Del Toro — Product Designer
  3. Emil Mourier — Product Designer
  4. Yang Li — iOS Engineer
  5. Morison Yoshinobu — Android Engineer

Resources used in this project

Let's Chat

If you want to talk, feel free to reach out. I’m pretty open and look forward in chatting. You can email me or tweet me. Whatever works best for you.

Next Project

Dewey for iOS

Dewey is a life automation platform. From chores to scheduling to any other monotonous task, the platform will manage your life so you can focus on what necessitates your brain power. Worry less about laundry or what social event you’ll be attending. Instead, invest your energy in tackling challenging issues that only a human can solve.