If you visit sites such as dribbble.com or behance.net you will note that there are a multitude of design mockups posted that look spectacular, but you rarely see apps in that style in the app store. There are a variety of reasons for this. For one, a gorgeous design mockup can quickly fall apart when faced with real world data, usability issues, or a variety of responsive design issues when handling multiple device sizes and orientations. On the other hand, sometimes the engineering implementation of a design can leave much to be desired, especially when it comes to user interactions and interactive elements.
Creating an engaging, delightful experience for users requires work.
In order to create aesthetically pleasing, clear, and useful interfaces for our users we need to focus on the areas that live between creating mockup images and code. There is much in between design mockups and the app a user sees, so let’s do some exploring.
Here at Fitbit, we utilize a feature team system, so each team has at least one designer embedded and working with developers on the features for that team. Feature teams also allow product owners to build features with input from developers and designers early on and throughout the whole process. This is a great place to start because it allows our team to work together to think of the design cases. For example, let’s discuss a recent feature the Weight and Nutrition team added around weight goals.
Working together early on before there are pixel perfect mockups can help reduce unnecessary work later in the development process. The more that design and engineering share about their respective edge cases, the more robust the initial attempts will be! In the case of weight goals, we had design constraints around the amount of vertical space we wanted the weight goal information area to take. We also had engineering constraints around what data we wanted to present as well as design considerations for low connectivity or when a user is offline. Also keep in mind the ever present threat of localization: other languages can cause longer strings, change character sets, or even affect the orientation of oriented text.
Working together to come up with visual rules for interface elements is very important – each platform has it’s own way of saying “don’t use absolute positioning” for good reasons. Take the time to discuss between design and engineering some of the rules when implementing an element. Are you going to make the top of a text element align with a vertical bar? That may not be a good decision if the size of your device changes drastically. Remember to always communicate in a common unit system as well. Just as a Mars orbiter was lost due to unit conversion, so too can your design! For example, on iOS one “point” is the equivalent of two pixels at retina resolution (retina resolution is the way that many designers prefer to work in).
Both Xcode and Android Studio have tools to help preview what views will look like on different devices and in different layouts. Be sure take advantage of these tools to explore the ruleset for the design layout. Sure, the design might look great on a 4″ screen, but what about when it needs to layout in landscape?
Prototyping and Iteration
As a team works to build out a feature, it can be a great idea to start iterating with rough designs to get something in front of others such as stakeholders, testers, or other designers. There is a fine line between code that is adaptable to future design iterations and code that is over engineered and may be scrapped after a change in direction. These quick, usable, builds can be the cornerstone of communicating between design, product, and engineering over the direction of a feature.
Make It Look Like This!
As the feature set and usability starts to come together for the design, it is time to start getting picky. Remember, it can be just as important to review a design as it is implemented as it is to review feature code as it is implemented. Let’s take a look at a few techniques that can used using xScope, a toolset for measuring and inspecting graphic layouts, to make sure the end result is exactly as intended.
We start by having our design team give us access to the design Sketch files or by rendering some layouts as a 1:1 pixel ratio PNG. We’ll use iOS as an example, but this should work for many platforms.
We then open the design mockup on the right and a simulator/browser/emulator of the current design implementation on the left.
Note all of the thin horizontal lines going across our screen – those are guides that we set up and positioned using xScope. Lining these up across critical points allows us to more easily spot size and alignment issues that are typically more difficult to notice just by comparing the two screens next to each other.
If we want something a little bit more ad hoc to measure sizing then we use the xScope dimensions tool. xScope’s dimensions tool will measure solid blocks of colors and show the dimensions in pixels.
The guide and dimensions tools are one good approach for checking size and alignment, but the overlay tool in xScope is another good approach. It can allow us to quickly see overall differences that might be hard to spot just by checking measurements.
Real World Design
The key to a great design is in iteration and using a critical eye. After the first designs and implementation, I would encourage you to take another look. While the design was likely reviewed early on for it’s design merits, the code reviewed for weaknesses, and everything QA’d for bugs, now everyone has the perspective of the issue at hand to take a second look. Often you will find when actually *using* the feature that some things are off. Are press areas too small? Text illegible? Many times design features that look great on a computer monitor have unforeseen consequences on a smaller, touch device.
This is the point where changes start happening that get left out of the document trail. In our team, we work to ensure that our design documents stay in line with the current product. One helpful tool we’ve found for this stage is utilizing automated UI testing to help illustrate design changes. In the iOS app, we use KIF for automated integration and UI tests. These tests have the capability of rendering views to images and comparing the results.
Let’s say that we’ve decided to change the color of our button and decrease the font size. After making these changes, I can run our automated KIF tests and get a new image for our weight goal view. An image diff tool such as Kaleidoscope makes it simple to illustrate what the changes look like in each commit. Next time your designer asks what it used to look like before, show them this!
The key element to a good user experience is communication – avoid “tossing designs over the wall” by iterating as a team on an experience. Make sure that designs are reviewed by design after they are implemented, and also make sure that all elements are critiqued, refined, and polished. Filling the space between design and engineering takes work, but the end product and your user’s experience is worth it.
About the Author
Stephen is an engineer, an artist, and many things in between. He has been working at Fitbit since 2014 and is currently a Senior iOS Developer at their Boston Office. Previously, he has worked on a number of projects such as 3D, real-time training simulations, babysitting apps, retail apps, 84″ touchscreen Mac apps, and more. Along the way he has enjoyed writing shaders in GLSL for an OpenSceneGraph based graphics engine and building useful libraries such as RZTransitions for custom iOS view controller transitions. When he isn’t working on mobile apps, he enjoys digital art, West Coast Swing dancing, and cheesy sci-fi books.