My Design Process
Because design is a creative act, it's inherently fluid. As I’ve worked in the agile process, I’ve learned how to be flexible and adjust to the varying needs of every project. While definitely not set in stone, these 11 steps have proved to be a useful framework to tackle the design challenges I’ve faced.
The first phase is all about asking tactical questions, gathering knowledge, and defining constraints. I try to meet with all the stakeholders to understand what is possible. This requires working closely with my Product and Project Managers. What are the scheduling constraints; how much time do we have for this project? What resources do we have for design and development? What are the limits of our system’s capabilities? Most importantly, I create a list of what we don’t know about the problem we are setting out to solve.
Now, I begin figuring out how to answer some of the questions I’ve laid out. This can be a mixture of primary and secondary research. I usually start by immersing myself in any subject matter that could help me understand the issue at a higher level.
At Jawbone, this is usually a combination of medical studies, health best practices, and behavioral economics principles. I also do a quick competitive analysis to understand what’s out there, what users might expect from a similar experience, and what opportunities there are for my product to differentiate itself. I’ll also ask one of our Data Analysts for specific metrics on usage rates and screen views if the feature will integrate with a part of the app that already exists. While not always possible in a fast-paced environment, primary user research is even more important.
A great process that has worked for us has been to send a survey to a larger group of users. Once we know some basic quantitative measures, we can invite a subset of users with diverse answers for an interview. We develop an interview protocol and make video recordings of each one. This can later be transcribed, synthesized for patterns, and trawled for insights.
User Experience Frameworks
This is the phase that probably varies the most depending on the project. In a nutshell, I want to make sure there is some kind of guiding light the project can rest upon. In many instances, this means defining 3-5 guiding principles for the experience. In other cases, it involves diving deeper by working with my Product Manager to develop a product vision and roadmap document. Supported by our research, we can use insights to establish cross-functional alignment and drum up excitement for the project.
Information Architecture & Wireframes
Finally, it's time to get down to some hands-on design. If I’m working on a completely new feature, I’ll start with an information architecture map. I’ll write down all the potential imagery, content, or features on post-it notes and arrange them in various ways. I can quickly iterate and try different frameworks. I’ll snap a photo of my favorite arrangements, and recreate them digitally. (Ever use the Post-It app?)
I view wireframes as the natural extension of the IA map. I work from a pre-made wireframe template to quickly iterate on different ideas at a fairly high fidelity. I like to think about interactions and hierarchy of elements at this phase to get a better idea of how a user will perceive the experience. I constantly check my work against the principles I defined. Of the many ideas I come up with, I narrow my thinking down into 2-5 clear directions to carry forward.
I’ll review my designs with the rest of the design team. We’ll work together to rule out any design choices that seem obviously problematic. I’ll also involve Product Managers and Engineers as well. All the stakeholders provide valuable insights on scoping the experience I want but are also realistic given our time frames and capabilities.
Before heading into testing, I’ll sync up with a content strategist to draft some rough copy for the feature. Often, copy can play a big role in how well users understand the experience. If we’re going to invest in testing, it’s always good to have some experienced thought put into communication through copy, even at the wireframe level.
Once I feel comfortable with the design directions, I typically create quick prototypes in Principle to string together the flow. I’ll outline a protocol that highlights the questions we would like answered. From there, I can show the prototypes to coworkers, friends, or recruited users. At Jawbone we’ve also had success with testing wireframe flows using UserTesting.com. We usually gain completely fresh insight by gathering feedback from users who aren’t familiar with our product.
For hardware feature testing, the timeline can be a little longer. To test these experiences, I’ll work with an Engineer to develop base functionality to send to beta testers. We will run a diary study to see how the feature performs over time. From there, we can refine the design and collect real-world data our Engineering and Algorithms teams can use to improve the feature.
Once I have data from usability testing, I take a look and search for any patterns that stand out. Users’ reactions to the design determine the scope of the revisions I make. Many times we’ll just have to tweak some copy or change the hierarchy of a screen. Other times there can be an issue with the flow itself, so I’ll go back to the IA map stage and reconsider some decisions at a higher level. If the changes are fairly drastic, I will typically push for another round of testing and revisions.
Once we know we have an experience that works, I will move to creating the final visual design. There are several different vectors that have to be considered when approaching this phase.
First, brand: a collaborative process between my Creative Director and myself to make sure the look and feel stays consistent across the product. Recently, our team developed a new visual language and component library for our app. It has really helped to systematize visual design decisions. I could get more into that here, but it could turn into a whole other story.
Second, platform: I always consider how the design will live within the native environments across the web, iOS, Android, etc. The design decisions are always a play between what supports the brand best and what the platform’s design guidelines recommend as best practices. I generally view iOS and Material Design as suggestions and explore ways to push the limits (break the 'rules') a bit on both sides to find a happy medium that uniquely defines the product. In addition to software platform constraints, it's important to think about how the design will scale across devices with a myriad of screen sizes.
Third, copy and localization: Jawbone’s app is localized into 11 languages. Designing for multiple languages involves more than just working closely with content strategists. First, I partner with them to make the clearest UI content. In design, I make sure that each area, including text zones, are flexible so that the design will still work even in German (the longest words ever) and Chinese (totally different syntax).
These three considerations aren’t linear. It takes iteration, evaluation from stakeholders, and critiques from other members of the design team to find the best solutions. I work a little on each aspect and massage the design until I come to a final solution that’s visually pleasing, supports the brand, flexible across platforms, and delightful in every language.
Design Documentation & Making It Real
Once the visual design has been finalized, I open up a new document and begin transferring each screen, checking that each one is pixel perfect as I go. Once all the colors, spacing, and assets have been completed, I'll upload our designs into Zeplin. It's a great tool that takes all the work out of the redlining process.
The documentation work doesn’t end there, though. A final design is not just about delivering pixel dimensions and assets. It's about defining the whole experience. As a Product Designer, I am stringing together the visual elements, content, user data, edge/error cases, etc into a single story that the user flows through. I always make sure that I thoroughly document all the flows for each use case. This takes some collaboration with Engineering and my Product Manager to ‘sanity check’ the design and make sure we’ve fully covered all possible user scenarios.
Then, I create a reference document. My preferred method so far has been to create a UX keynote document that pulls in all the final visual elements, videos from prototypes to describe animations, and uses tables and charts to explain all the data and experience scenarios for each screen.
From there, I can hand off the document to Engineers to use as a reference as they build the feature. In addition, I continue to collaborate closely throughout the development process by reviewing their builds, providing any assets, or tweaking the design based on new issues that may come up.
Release to Users
These last three steps are where things get relatively easy to explain. Releasing to users is just like what it sounds like. When the design has been checked and finalized, the Engineers put it on the release train. When the app updates and the new design is in users' hands, we monitor the feature to make sure everything is going well. We collect data on usage and effectiveness for a significant period of time to validate the feature update.
While I don’t lead this aspect of the process, I think it's very important for designers to be involved in analyzing user engagement data. I work with a Data Analyst to review the findings from the feature’s data collection. This can often help inform what should be changed in the future. I also use these learnings as actionable principles to apply as I shape my next project, even if it is unrelated. By learning through data, I am able to empower myself and validate my design choices cross-functionally.
The agile process is quick. You work fast to release features into the hands of users, test their effectiveness, and iterate again. This means that designs don’t last. They’re constantly changing as we gain more understanding and as user preferences change. Everything we learn has the potential to evolve the next time around, and that’s the most exciting part about working on a product. The work is never done.