DME by Soliton Systems

Work Securely Anywhere — a case study

What is DME?

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 responsibilities for this project

  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 notes 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 and lacked organization in its feature set.
  2. The product was unintuitive and many factors contributed to this. A diversion from how UINavigationController handles hierarchal content was a big factor.
  3. An unintuitive product with usability problems and a visual interface that didn't reflect today’s products had a negative impact on the business.
  4. DME 5.0 was an opportunity to make DME a more competitive product in the market place.

Designing DME

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.

Understanding the problem — Lack of navigational hierarchy, vague iconography and lack of organization throughout the app

  1. One of the main problems was the lack of established hierarchy in the interface. In addition, important functions like filtering emails were behind a vague icon and the product was lacking order. A walkthrough of V 4.0 can be seen here: DME 4.0
  2. The goals were clear: design an intuitive product with design patterns used in today’s products and create a software experience that can compete in the market today. This meant designing a product that handled all the email in one view, enabled users to filter their email and provided the ability to manage settings for specific mailboxes in an organized fashion.

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.

What failed and why — Placement and prioritization

  1. One of the biggest problems was making sure the tool bar for email did not cause accidental taps on the tab bar. This problem only affects the iPad and tablet on Android.
  2. What failed was largely the placement of these buttons and which buttons were designated to the tool bar.
  3. All options in the tool bar was not a realistic approach. It would cause accidental taps in the tab bar and it would become a problem on smaller displays when the third pane in the split view is activated.
  4. The solution to the problem of accidental taps is to have a tool bar with move to and delete to the right side of the tool bar and reply and flagged on the top right corner of the navigation bar. Icons for actions like move to are really vague and text is a requirement for clear communication.

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.

What failed and why — Failure to account for a diverse set of screen sizes and localization requirements

  1. Moving emails between mailbox is an important feature for any piece of software that handles mail.
  2. The example I cite failed because it didn’t account for the complexity that is Android when it comes to screen-sizes. Moving an email from the left side of the screen to the right makes sense. It’s how people perceive progress.
  3. Other reasons it failed had to do with localization. When you reduce your space in the UI by half, localizing for languages like Russian or German proves to be really difficult. Far too much space is wasted with the approach illustrated below.

Ergonomics in email — and necessary trade-offs

  1. I explain the process in designing a comfortable physical experience for one of the most important parts of the product.
  2. The short explanation: designing a comfortable experience meant designing one that wasn’t only near people’s thumbs but one that was simple and obvious.

The importance of ergonomics — 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.

What failed and why — Clarity

  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 affordances — 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.

Designing contacts — the steps taken to clearly separate work from personal

  1. DME’s core feature set is the ability to separate work from personal and this mission extends to contacts as well.
  2. An effective way in solving this problem involves using appropriate copy to clearly identify work and personal. Material Design provides cards that allow the interface to more clearly separate work from personal. A combination of good copy, table view sections and Material Design cards make it really simple to easily identify work and personal information.

More tab — Why the technicality of UISplitView required visual changes

  1. Why the technicality of UISplitView mandated visual changes on iPad and Android tablet to differentiate between additional features that require another view that rely on UISplitView and a table view that just displays more content.
  2. The short version: We can’t have a SplitView within a SplitView. Technically speaking, it’s impossible. A SplitView is able to present more data on the right side of the screen. A great example is settings: if you tap general, additional data is revealed on the right. We can’t do that with to-do because to-do it self relies on the SplitView.

How the technicality of UISplitVIew influenced how More behaves

  1. The problem only affects the iPad and Android tablets. This was still a problem and one that involved understanding a bit of how UISplitViewController works.
  2. More on the iPhone and on Android phones consists of a list with two sections: additional functionality like To-Do and Notes and app settings. When a user taps on any of the options on the phone, it animates and is loaded into the UINavigationController. UINavigationController is the class that is in charge of managing the hierarchal content on iOS. On the back end, it’s similar on iPad but visually it is not.
  3. The problem on the iPad and tablet involves two items that look the same but behave very differently when users interact with them. If a user taps on settings, information will be presented on the right side of the split view. We can’t do that with To-Do or Notes because those features themselves rely on the SplitView.
  4. The solution is to visually separate settings from the additional functionality. By separating them visually you avoid breaking certain expectations a user might have from the patterns used in the Split View.

What failed and why

  1. I explored a lot of potential solutions, from collapsing side menus to showing our new feature set in the split view. The reality is that it was really disorganized and it would consume far too many engineering resources for a mediocre solution.
  2. The better solution to this problem is to visually differentiate the extra feature set from the data that would be shown in the split view. This approach doesn’t create a set of expectations in how the UI will behave for users and it’s a way to visually separate different behaviors.

To-Do — The use of color for communication and cultural considerations

  1. How color is used to communicate critical information and the considerations for the Chinese market and their interpretation of colors.
  2. The short version: Colors are used to communicate important information like items that are past due. However, colors aren’t seen equally around the world. Relying on color alone to communicate information is problematic across borders and cultures.

The use of color to communicate critcal information — and the consideration for international users

  1. Colors play an important role in interface design and are a critical part in communicating context to users.
  2. There were a few things to consider: colors aren’t interpreted equally across the world and DME is a worldwide product.
  3. Red, for example is seen very differently in Asia in comparison to North America. To mitigate this, we use a combination of text and color and highlight key parts of copy in the UI to communicate important information like past-due To-Do’s.

Notes — Providing contextual feedback when traditional mechanisms were not available

  1. Forms of contextual feedback are components like the selected item in the tab bar or the title of the navigation bar. Those two forms of context are not available because the user is in the more tab and search is in the navigation bar.
  2. The short version: Providing contextual feedback is a problem on the iPhone. The iPad relies on its SplitView and navigation bar to provide that context. To provide contextual awareness to users we use UI components like our tool bar that communicates sync progress and we also use our search bar in our navigation bar to communicate to users where they are in the app.

Providing context when traditional mechanisms were not available

  1. Providing contextual feedback is only a problem on the iPhone. Because the iPad app is designed slightly differently to take advantage of the larger screen, the SplitView and navigation bar serve as a feedback mechanism.
  2. To solve this problem we had to take advantage of existing elements to communicate context to our users. Elements like our system status toolbar and search field rely on copy to communicate to users where in the UI they are.

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

  1. iOS Human Interface Guidelines
  2. Material Design Guidelines
  3. Origami Studio by Facebook
  4. Sketch
  5. Facebook Devices
  6. Nielson Norman Group
  7. WWDC 2016 - Inclusive App Design
  8. WWDC 2016 - Typography and Fonts
  9. WWDC 2016 - The Universal Benefits of Accessible Design
  10. Stark - Sketch Plugin