At Zendesk I led the design of the native Mobile SDK, defining the design strategy since its inception. Zendesk's Mobile SDK is the most popular native support software on both Android and iOS. Built into thousands of apps on the App Store and Google play store, every month this SDK handles millions of tickets and chats from some of the most popular mobile apps in existence.
The SDK gives Zendesk customers the ability to easily implement Zendesk products natively within their mobile apps, allowing their end users to browse help center articles, or contact support in a familiar conversational interface. Minimal code is needed to get up and running, and a smart theming system was created to allow a plug and play approach if needed, with little to no design consideration needed from the developer.
When it comes to the interface, there are two types of customers consuming the SDK. Consumer apps that require a seamless interface that sits comfortably within the iOS Human Interface Guidelines and Android Materiel design system. And the other are the mobile gaming companies, who need a support experience to fit within the custom world they’ve created for their users.
Traditionally we tried to satisfy both these needs, and ultimately that ended up with us hitting the middle of the line above. We provided a UI which could be highly customised, but that still is never enough for gaming experiences, and the tedious customisation options frustrated the customers that want a more plug and play experience.
For the 2.0 release engineers worked on exposing better APIs to satisfy the gaming customers and those that need a highly custom interface. For the other customers, I defined a simplified theming system allowing SDK implementors to get set up far quicker while providing a best in class mobile support experience, and still maintaining visual consistency with the host app.
With this new theme system, on iOS there is only 1 colour to set – user for buttons and NavBar tints. The background of NavBar is inherited from the host app. And on Android the Primary and Accent colour specified by Material design is used. The interface for Tickets, Chats and Articles will always be light with an accessible contrast ratio.
With the last major release we moved to a fully conversational interface, regardless of whether the chosen support channel is ticketing, chat or messaging. Based on past feedback, and the familiarity mobile consumers have with messaging, the conversational interface enables SDK to handle other channels that may come in the future in a more seamless manner. One day this interface will become the hub of all of the end-user’s conversations.
By taking this approach we reduced choice paralysis over which channel the end user should choose and simply route them to available agents on chat or tickets depending on support capacity or customer profile.
It was great to play a part in the success of this product, I look forward to seeing how the team progress this in the future.
Usually an over abundance of settings in a product is often a sign of indecision, however in this instance Asana have provided an experimental section of the app where you can turn on these hacks. It's an interesting approach not usually found in enterprise productivity software. I wonder what the adoption rate of one or more of these hacks is, and if any of these experimental features have made it fully into the product?
Originally posted on Medium
Almost every app has them, but no-one wants to see them. Yet these are a fundamental element in designing a product where content loading is a consideration. These little animations that progress while content is fetchedserve as a reinforcement of our expectation that something is happening, and what we are looking for will eventually arrive.
While working on an app this week I wanted a circular spinner that would fill from 0–100% based on the data received. Principle is great for linking screens and animating differences, but on first look for this type of animation the tool can be limiting.
With some trickery, I’m going to share how you can create the effect of a circular progress indicator, which will result in something like the above.
Ok, let’s create our shapes. Principle has sufficient drawing tools to achieve the shape in the finished example above, so this time there’s no need for Sketch or Photoshop, however this technique will work fine with raster images also.
Firstly we’re going to create a rectangle, and then set a radius so that it appears as a circle. For the purpose of this demo I’m going to set the scale value to 2 to make everything legible, but I would usually design in Principle and Sketch and 1x for iOS apps. Set the rectangle to 24pt x 24 pt, with a transparent fill, and a 10% black stroke of 2 pts.
Next, we’re going to copy that shape and change it’s colour to the fill we want for our progress indication. We’re also going to put the shape into a rectangle that will act as a mask. Make sure ‘Clip Sublayers’ is ticked on the rectangle mask, and set it to 24 pts high, 12 pst wide at 2x scale.
Once we have our mask, duplicate it and flip that 180°.
We’re going to simulate the effect of the circle filling by animating the height and width of both the left and right side masks. The construction and what is actually happening is illustrated below.
Before we create multiple artboards in Principle to animate this effect, we need to change the width and height of each mask to 0. Because the left mask is a 180° duplicate of the right our starting points to grow the mask’s width and height is ideal.
Next, we’re going to create an additional artboard to animate the spinner to completion. Below is how the scene is set up. Firstly the circle, fill and masks have been placed into a containing group called Spinner –this will come in handy later.
I’ve adjusted the timing of the transitions so that the left side of the mask animates after the right has completed. Note that the X and Y transitions need to match the corresponding width and height transitions. I’ve set these to linear for a smoother transition, but other easings will work as long as both X, Y, Width and Height match.
And this is the result of those animations. It’s not that exciting right now, so there’s a couple of final tweaks that will give the load indicator a more natural and fluid feel.
Let’s play with some rotation, scale and opacity to add to the movement. As this is 2x scale, on the first artboard we’re going to change the spinner group to 1x and the opacity to 0%. We’ll also make the angle of the spinner group -45°.
We’re going to leave the second artboard as it is with one exception, we’ll give the spinner group an angle of 135°.
Finally, duplicate the second artboard to create a third. This will be used for the exit animation. Let’s set the angle of the spinner group on the last artboard to 45° and match the scale and opacity of the first artboard (1x and 0%). Remember if you were creating this at 1x just devide by 2 and use .5 for the scale. This will create a nice effect as the spinner leaves the scene.
That has us most of the way there. I prefer to use a spring animation for most scaling effects, so let’s go ahead and do that. Also, let’s put in an auto transition from artboard 3 back to artboard 1 so it’s easy to click through it multiple times.
And this is our final result. This can easily be copied into more comprehensive prototypes and Principle will maintain the transitions and timing as it has been set here. There are many variations that could be done using this technique and manipulating the elements in different ways.
I find for smaller UI elements it can be helpful working isolation and bringing them into an app prototype once they have been adjusted to the desired behaviour.
And here's the final source file for reference. Happy prototyping!
The same approach should work on InVision Studio, I'll update the post soon to include the necessary steps!
The things I truly enjoy using all have something in common. They are meticulously crafted. A culmination of years of work, iteration and experience, but it’s more than that. These are products that are so obvious, so normal you have to stop and think before you realise the work that has gone into them.
Functions have been distilled into the purest, most efficient form. Using these products is a thoughtless action. They are full of ‘of course’ moments. Moments where you can’t imagine any other way of doing things. The interaction presented is so obvious that it must be the only one. ‘Of course it works this way, how else would one do it?’.
Jasper Morrison and Naoto Fukasawa, designers at Muji use the term super normal to describe a design philosophy they define their work by. Products that are unnoticeable, almost boring but yet enhance our environment and our lives so positively.
“The objects that really make a difference to our lives are often the least noticeable ones, that don’t try to grab our attention. They’re the things that add something to the atmosphere of our homes and that we’d miss the most if they disappeared. That’s why they’re ‘super normal.” — Jasper Morrison
While the above was written about physical objects, I believe the same to be true for technology. When I first read about the super normal philosophy from Dave Morin’s excellent post it immediately resonated. I had made the move to product design about six months prior and over time I began to truly embrace convention.
As a product designer there are many opportunities to impress the people using your products with slick interfaces, but these moments are short lived, and rarely useful. What we should be aiming for is to create a something so intuitive and so frictionless it’s unnoticeable. Only then have we created something of true value.