What is the Design Process?
We want to see your design process.
— Said every interviewer, their voices echoing into the abyss.
A design process defines every designer’s journey to solve wicked problems. It’s a phrase that appears at talks, in job descriptions, and during job interviews.
But, what exactly is a design process? Each company interprets it differently. And, each designer interprets that interpretation differently too. And, when asked to clarify, they fear that we are being too prescriptive and the process should be unique to an individual.
We agree that no one can actually nor should formally define a design process. There are way too many contexts that get in the way of structure. However, within our class, we discovered that new designers struggle with higher-level conceptual models and jargon, all while trying to actually do product design.
As a result, this guide seeks to put faces to names of the several facets of the design process. Unlike having you uncover each step on your own, this guide is intended to be a benchmark that you can later morph into the process that ultimately works for you.
Drawbacks to a Simplified Design Process
The ‘simplified’ design process with which students are familiar is modeled after a typical/academic case study.
- Interview a bunch of people
- Brainstorm (only using Post-Its)
- Do a lot of low fidelity sketches
- Make some wireframes
- Do some user testing
- Create high fidelity mockups (.~*pixel perfect.~*)
- Iterate, iterate, iterate (if you screw things up)
Well, what is wrong with that? That sounds like the process to me.
You’re right. There is nothing wrong about this process.
However, jargon like ‘low fidelity’ and ‘medium-fidelity’ do not mean the same thing for more and less experienced designers. For less experienced designers, it is interpreted to be the deliverables whether it be sketches, post-its, or beautiful mockups. For more experienced designers, it abbreviates an entire phase of work that consists of the goals, expected outcomes, and methods of doing what they do best.
Demystifying the Design Process for Digital Products
When we think of the design process, we should think about three components that are characterized by three different guiding questions.
1. Elements · What is our expected outcome?
The Elements of User Experience defines checkpoints like the feature itself, the interaction, the content, and the visual styling that helps translate a users’ intentions towards their expected outcomes.
2. Stages · What is our approach?
The Double Diamond mixes divergent and convergent thinking, human-centered design, and iterative design to ensure quality.
3. Tools · What do we use?
These define the set of tools we use at one or more of the stages of the design process. They are optimized for specific goals of the process whether it is understanding the user or creating the right affordances for an interface.
These are the components of designing the experiences that solved problems in our lives, and they serve as a framework that uncovers solutions to complex problems. For each, we’ll take you through each part of the process.
Defining the Elements of Great Products
Elements of User Experience Framework by Jesse James Garrett
A products’ user experience isn’t about long drop shadows or fancy gradients. At its core, good user experience defines a problem for its users and a delightful solution. The elements:
- Set checkpoints that builds one after the element prior.
- Consider both task-oriented (reserving an Airbnb) and information-oriented components (organizing content in an Airbnb listing).
- Migrate from the abstract (ideas) to the concrete (visual styling).
Strategy — People Problem and Business Goal
The strategy is the intersection between solving their people problem and achieving their business goals. Solutions that accomodate both make up the solution space.
People Problem
Before Venmo, a people problem is that “Millennials wanted to lend and borrow money from their friends, but they cannot because as cash becomes more obsolete, wire transfers and debit cards make peer-to-peer transactions tedious.”
Business Goal
However, as Venmo, a business, addresses a people problem, they needed to sustain themselves. Their business model resulted in charging businesses 2.9% for every transaction. Therefore, a business goal was to make Venmo a desirable and accessible payment medium, and to do that, they had to secure a strong and consistent user base [1].
Scope — Feature Requirements and Content Requirements
The scope determines the set of features that are necessary for a feasible and impactful subset of the solution space.
Feature Requirements
Some (not all) features that both improve peer-to-peer transaction and improve user growth are:
- Make Transaction (Send or Request): How might we move money from one person’s account to another’s?
- Searching for Friends: How might we find people in the digital space?
- Connecting with Bank Account: How might we have all our money at the click of a button?
Content Requirements
Now, let’s dig deeper into Make Transaction and how that aligns with the strategy. As for content, we need to fit the mental model of how it’s done traditionally. We would need another person, money, and a reason. However, there are limitation in the digital realm. In real life you can tell if a person is actually your friend, but that is difficult on your phone. Therefore, content objects may need more content that are attributes to the parent: what they ook like (profile picture), what their name is (full name), and a unique identifier (username).
Structure — Interaction Design and Information Architecture
The interaction design defines steps needed to achieve a goal using the features, and the information architecture further defines more complex context groups and hierarchies using the content.
Interaction Design
Venmo mapped their user flow to how we exchange money already. For example, we rarely migrate $9.50 to a different pocket before meeting the person we owe. Nonetheless, the traditional flow has limitations on your behavior (referred to as channel factors [2] in social psychology). Examples of channel factors could be physically finding your friend, having enough money, or having the courage to tell your friend what they owe you.
Luckily, Venmo abstracted all those barriers into the screen of a smartphone which results in a much stronger, seamless interaction.
Information Architecture
Information architecture, at its core, is a set of relationships between all types of data that better demonstrate what is being represented on an interface.
- Some relationships build up more complex objects like how names, profile pictures, and usernames make up a ‘user’.
- Some relationships show ownership like a transaction requiring an amount, description and timestamp.
- Some show importance like how Make Transaction takes less clicks to access than Search.
Skeleton — User Interface (UI) Design and Navigation Design
From the set interaction, the User Interface translates the types of elements (buttons, labels, inputs) that drives the user from one step to the next step. And, Navigation Design uses the information architecture to visually organize these elements not only from screen to screen, but from element to element.
User Interface Design
When making a transaction, at Find Friend, a User Interface audit would contain elements to accomodate certain use cases:
- Finding a person you frequently exchange money with (Suggested Table View)
- Find a person you don’t really know (Search Bar)
- Seeing if the person is the right person (Profile Button, username)
Navigation Design
If you found your friend, you will navigate to a new space to determine the amount. Navigation Design is not only picking a tab bar vs. hamburger menu or pushing new screens upon click. Navigation Design is customarily how you move through content. In the Fig. 7, it could be organizing your suggested friends by alphabetical order or by location.
In Fig. 8, navigation design can organize elements to insert amount, add a description, and requesting transaction to be arranged from top down. Moreover, it can also decide that they live on the same screen so that users can securely double-check all the details of their transaction before confirming.
Surface — Visual Design and Motion Design:
Visual Design helps the interface afford certain actions. Light text in an input can afford that it is empty, and a colored rectangle can afford a click or a tap. Motion Design indicates temporal states of objects (loading, ephemerality, etc.) or shows spatially where we are within the product.
Aesthetics that are less utilitarian or have little to no utility, though, convey tone and brand personality, or they make visuals digestible by keeping them simple and consistent.
Visual Design
At the feed (the end of a transaction), Venmo uses circle profile pictures that are, by convention, used to indicate people, green to indicate gains, and red to indicate losses. It draws divider lines to group transaction information, positions actors of a transaction above to show ownership — and, most interestingly, emphasizes the description to possibly create a more social tone to talk about money.
Linguistically, it probably thought “requested money from” was consistent yet wordier than “charged”, and felt that the heart and comment icons were ubiquitous enough to justify removing the label.
However, what keeps it all together is the unsaturated blue, that is both neutral and utilitarian that we all (all, as in, technology-fluent-Millennials) come to recognize as Venmo’s.
On a side note, motion design can provide feedback over time. In the figure above, the blue bar slides across the screen to show that the transaction is completing. Then, the screen pulls down which first signifies that you are exiting the transaction instance and returning to the core application. Had the transitions been more stark you would find yourself subtly lost and confused.
Why Do We Need the Elements of Good UX?
Many new designers dive directly into visual details: how a drop-down animates, the color of the navigation bar, etc. However, they usually miss the components that lie below the cosmetic.
Strategically, we use these components as checkpoints that start from divergent features to differences in typesetting. That way, we reduce the overhead of over-exploring interactions of infeasible features, UI’s for dead-end interactions, or visual treatment of UI elements that cannot exist. Therefore, we substantiate our progress — our euphoria — at 5 different points in the design process: strategy, scope, structure, skeleton, and surface. As a result, we build the foundation step by step so that “going back to the drawing board” is never as hard as it sounds.
More importantly, we do this to frame our work when presented to a wider team. We see this becoming more and more necessary when students are learning product design through Dribbble [5], through mentorship, and even through academia. That’s when visual design ends up meaning both “long drop shadows” and “affordances”.
If we standardize the language, it will be easier for new designers to identify expectations. We can use these elements to better set timelines and to focus conversations to specific components. Moreover, it can help diagnose weaknesses of any existing product in a way that the feedback can be constructive and clear.
There is a theory that the language you speak determines how you think, how you see everything. — Arrival (2016)
The movie Arrival, speaks a lot to this concept of having language affecting how you see the world. The same exists for the small lexicon for designers and how it can help us evaluate and communicate designs. At it’s core, the Elements of User Experience allow us to see any and all work, as layers of intentionality instead of just pixels on a screen.
Defining the Stages of the Design Process
So, how do we build up the elements of a great user experience? It’s not as easy as mowing through product’s Strategy, Scope, Structure, Skeleton and Surface. because there is no guarantee that each element works.
What if we are actually solving a problem that rarely exists?
What if we are picking features that don’t properly address the problem?
What if the interaction makes a feature inaccessible?
What if the UI makes an interaction frustrating to use?
What if the visual design makes the UI invisible?
The Double Diamond Framework[6] by the British Design Council allows us to make intentional design decisions by exploring various options (divergent thinking), while validating stronger ones and weeding out the weaker ones (convergent thinking).
We use this same approach to address two things:
- Is this the right problem to solve?
- Is this the right solution to execute?
The process is designed to leave no stone unturned to ensure that the intended direction is more likely to create the desired impact.
Designing the Right Thing
First, we’ll look at designing the right thing. As we said in the first lecture, we use the Clay Christensen Jobs Framework to better communicate what a people problem actually is using an end-user, the context, the need, and the expected outcome.
For example, before Uber, a people problem was:
When pressed for time, I want to go to my next destination reliably, so that I can focus on what I have to do. But I can’t do that well because: public transport is less flexible and taxis are expensive.
Uber didn’t fix the SF transportation infrastructure nor did they provide tools for users to better plan in advance. They removed the overhead of establishing trust between a person who can provide transportation and a person who needed it.
Existing people problems surface frustration, workarounds, or an inabilities to accomplish a certain goal. However, we can’t solve every single problem — because not all problems are created equal. In reality, some affect more people, some are more profitable, and some can’t be solved at all.
To better understand what problems need solving, we take an investigative approach using our users and our business goals.
Step 1: Discover
Our goal is to discover as much data as possible based off of an initial insight. We do this by conducting user research and looking at competitor products. With user and market research, we understand — on a human level — the unfulfilled needs from our users and a competitive analysis of our market space. We audit the constraints of our business and our developers and our timeline. We look at this information as our raw data, our resources, to further decide what problem to tackle.
Step 2: Define
From the raw data, we find trends and insights that span across different users and scenarios. We shelf problems that are expensive or too ambitious, and select problems that can create a large impact. From there, we select the best problem to solve and move to developing solutions to solve it.
Designing the Thing Right
With the problem from the first diamond, now you can focus on how to solve it. And similar to how we treat problems, there are also many solutions that can solve a single problem.
Step 3: Develop
We begin to ideate any solution that can solve our determined People Problem. We reserve any judgement and think big, wild, and crazy. We surface our information from our research, and create ‘How Might We’s’ or tactical solutions that could work. Overall, this stage is characteristic of ideation, brainstorming, sketches, collaboration, etc. Near the end, you will find trends in these explorations that you will treat as candidates for implementation as long as they fit your constraints like feasibility and impact.
Step 4: Deliver
With a set of promising features or feature, you will explore how they actually interface with people. You will start developing the Structure, Skeleton, and Surface through smaller iterative loops. At each loop you will execute, test, and understand what works. Evaluation could look like presenting your work at critique, running an AB Test, or showing users a prototype. From here, you learn what implementations work and which one’s don’t, all leading to one solution.
Most of this section was expanded on Dan Nessler and his thoughts on applying creative processes. This is a very in depth and more expansive view on the double diamond, and we highly suggest you read it.
Why Do We Need the Double Diamond?
It is one thing to know what can go into a product, but its another thing to know what ought to go into a product. New designers have a tendency of picking solutions that void business goals (‘Let’s have Venmo disable itself if you spend too much money’), that are too complex to build (‘Let’s have Venmo auto-invest your money into stocks that will be successful’), or don’t solve relevant problems (‘Let’s have direct messaging in Venmo!’).
The Double Diamond keeps us grounded. It allows us to put our ideas in front of samples of the target audience before it is built, get feedback from stakeholders, and uncover other solutions that are better than the one you just thought of. It allows us to context switch from exploring possibilities to pitting them all against each other. That way, the best idea will always be in the mix, and, they will always rise above the rest.
“I’ve found that I need to develop these two personas separately. . . . be a much more ruthless editor and be a much more careless artist.”
— Christopher Niemann (Abstract)
Defining the Tools that Optimize Our Workflow
These tools are emergent in the history of design. They outline best practices, protocols, and rules that improve how we approach specific stages. For example, when discovering (in Stages), to achieve the people problem (in Elements), we may need to conduct user research and market research. These tools in itself have baked in philosophies and protocols that guarantee an expectation.
Tools
Research (User/Market): The overall goal is to understand the context of a given People Problem. This may include exercises like guerrilla testing, focus groups, interviews, surveys, competitive analysis, or traditional googling.
Low Fidelity: Characterized as low effort and detail. This constraint allows us to be generative. Messy Sketches or list of steps that a user takes helps us put our ideas onto paper without any restraint.
Medium Fidelity: Characterized as medium effort and detail. This constraint allows us to make higher-level decisions. We can focus on the interaction and UI without talking about visual treatment.
High Fidelity: Characterized as high effort and detail. This constraint allows us to focus on color, clarity, and content. This type of work is more time-consuming, but the end-goal is to really evaluate how a product will most accurately perform in a real-life setting.
User Testing: This allows us to preemptively test whether or not a product will fulfill their People Problem. This can involve prototypes, research protocols, and users.
Critique: While many decisions can be constantly tested, testing is time consuming. Designers are hired with some level of intuition, and getting feedback from other designers pulls in perspectives from other similar problems.
Why Do We Need the Tools?
Humans are easily distracted. We, designers at all levels, sometimes stress about the border radius of a button, when we know we need to focus on the user flow. We fall in love with our work, when we know we should be open-minded and willing to take feedback. Therefore, practices like ‘fidelities’ and ‘critique’ emerged in these creative roles. It defined rules: “Don’t focus on color in medium fidelity work.” “ Don’t bias the interview by asking a leading question.” “Take feedback like champ.” As a result, they help subdue our flaws of human nature (because you can never get rid of them) and generate better work.
“Can we define the process as low, medium, high fidelity?”
- It’s less explicit. When checkpoints are sketches, grayscale wireframes, and polished work, beginners are more willing to show the artifacts instead of actually doing the mental work to actually identify the right content, flows, etc.
- Tools aren’t constrained to any stage. High fidelity work can drive the vision early on in the design process as a north star [7], and low fidelity work can be used to quickly ideate visual detailing of a component.
- Different interpretations. Depending on the team, sketch work and wireframes may not exist. Some teams can be just as generative while maintaining a pixel-perfection with their work.
Putting it Together — The Design Process is Like Baking a Cake
To bake a cake — a fairly complex one — you have instructions, ingredients, and a set of tools. The Elements represent different components of the cake: fruit and cake layers, frosting, details (I clearly don’t bake). However, there is a natural order: first make the base, then you add the frosting, etc. The instructions are the Stages that teaches you how to properly make each part. Lastly, we use a set of Tools, measuring cup, whisk, and oven, to make components at any step of the way.
Process is King, but Context is God
Understand, identify, execute. Define, explore, refine, build, learn [BuzzFeed, 8]. Discover, Define, Develop, Deliver.
New designers (especially in a school setting), when taught the design process, treat it like law. They force the process, slow down development, and have little empathy for the people they work with.
However, the design process is somewhat unrealistic. Any ‘step-by-step’ process, even this one, fits perfectly when the variables are ideal. And, in many cases, things aren’t: tight deadlines, no resources for research, stubborn managers, etc. And, in some cases, the process may not be the best fit for the task (designing a login screen).
At the end of the day, a true design process is not a set of Silicon Valley buzz words (extra points for alliteration). It is the ability to know when to apply parts of it and when not to. It is the ability to know how a process fits with scenarios like adjusting to a developer’s skillset, compromising a shorter timeline, or accommodating the goals of another team.
A designer exists to solve problems, but problems never come in a nice packaging.
__
This post is a summarized transcript from Intro to Digital Product Design course hosted by CUAppDev at Cornell University.
