Articulating Your Design Process

As a designer, your process is both an art and a science.

You combine artistic sensibility, product thinking or business sense, and user empathy and psychology. Demonstrating that you can integrate these competencies in a methodical way is key when interviewing with tech companies.

It's unlikely (but possible) that you'll be directly asked "what is your design process?" However, every portfolio project you select, every question you answer, should align with your personal process, which should in turn align with who you are as a designer.

It's important to clarify your process as you prep your portfolio and practice interviewing.

What Interviewers Are Looking For

Every design project you work on is going to be different in some way, but if you’re able to articulate a process that's worked reliably for you, it'll go a long way towards convincing interviewers you can handle the ever-changing world of tech -- and exemplify your strengths as a designer.

It's important to express your process as a series of key milestones that take you from idea to reality. Here are some guiding questions that can help inform how you should approach process-related questions:

How do you make sure what you’re designing is serving user needs?

As a designer, it isn’t enough to say that your designs serve the user; you’ll need to prove it. Highlight what you did to make sure the user’s voice is represented in your designs. When talking about serving user needs, think of the times you were able to directly access their feedback or how you validated your designs with users.

Tell me of a time when you had to make a difficult design trade off.

Said another way, interviewers are looking for the inputs and considerations you made when making design trade-offs. Showing that you made the “right” decision is less important (in interviews!) than showing that you made an informed decision based on the user. Make sure to emphasize how following your design process resulted in enough context to confidently make design decisions.

When you think of your last project, what exactly did you do? How exactly did you work with others?

The purpose of this question is to see if you’re able to summarize how you work via a clear, logical, self-aware narrative.

One tip that we find helpful is to prepare your project reflections as a chronological list of decision points. Once you've got your list, articulate what you learned from each, and how you applied these learnings to your next set of decisions.

If you're struggling to get started, user-centricity is always a good strategy. Highlight user research first. Then show how you iterated and increased fidelity for your design solution collaboratively, with continual reference to customer and business goals.

Are there any design rituals or work that you enjoy or are strong in?

This is a great opportunity to really articulate why you’re a strong designer! Help the interviewer learn about you -- and how you're a fit for the greater organization. If you are a strong visual designer, talk about how you like to sweat the details. Or maybe you love people, and user-centric design -- talk about interesting research opportunities you've participated in.

Is there something unique about the way you approach problems?

Similar to the above, how does your unique self -- your experiences, and choices throughout your life -- contribute to your strengths as a designer? Maybe you’ve noticed a particular internal framework for making UI choices, or you have a strong stance on how you best collaborate (taking others' needs into account, of course!) Continuous self-reflection and improvement will set you apart -- not just in interviews, but in your on-the-job skills and processes, which are reflected in your designs.

Practice describing your process and articulating what a successful process is. It's one of the most important pieces of information they're setting out to understand when speaking with you.

The two biggest opportunities to do this are typically:

1. At the beginning of your portfolio presentation when you introduce yourself. This is a great way to show what kind of designer you are.
2. Whenever you have the chance to talk about any design experience you have (i.e. during the portfolio presentation or behavioral questions).

We can't stress this enough -- the way you talk about your process through projects is key to successful interviews.

Design Thinking

If going through the questions above was difficult for you, don’t worry! A key framework that many use to articulate their design process is ‘design thinking.’

According to the Nielsen Norman Group, design thinking, “asserts that a hands-on, user-centric approach to problem-solving can lead to innovation, and innovation leads to differentiation and competitive advantage. This hands-on, user-centric approach is defined by the design thinking process and comprises 6 distinct phases…” (source)

Here is a quick rundown of the design thinking process:

Empathize

Before going into defining solutions, it is important to understand the problem space you’re solving for by learning about who you’re designing for. This usually takes the form of user research. The goal at this stage is to develop an intimate understanding of users. What are your users saying about your product? How do they feel in their day-to-day lives? What do they feel is important to them? Developing empathy for your users helps keep in mind that you aren’t designing for yourself, but for someone else. User research and data will help inform every decision you make after this step.

Define

Gather your research into clear deliverables that pinpoint user needs, like personas, user journeys, or user stories. Without synthesizing your research into something actionable, that research only represents possible directions. Based on what you’ve observed about your users, what are their biggest pain points? Are there opportunities you could address based on what your users are saying?

Ideate

With a clear idea of what you’re solving for, time to iterate different solutions. This is usually done at lower fidelity, like wireframes or rough user flows. Even with a clear understanding of user pain points and a user goal in mind, there are still many ways to design a solution. Generally, a good strategy is continually refinine and validate ideas until you reach the one that best meets your users’ needs. Reaching this stage of the process is where you finally put pen to paper and explore all kinds of different ideas. Keep an open mind; the more variety the better.

Prototype

Once you’ve decided on a direction, it’s time to illustrate what the final solution should look like. This might take the form of high-fidelity mock-ups, but ideally it's a working prototype. If ideating was defining the general experience, prototyping is focusing on interaction and visual details. What details would your developer need to build the solution? What features does your product manager need to know to finalize requirements?

Test

A working prototype that you can bring to users for real feedback is invaluable. Validating in this way makes sure your team builds the right thing to solve the right problem! Depending on the project, you may not have talked to your users since your initial research. Testing out your solution before implementing provides you the feedback you need to validate as well as finalize other details before moving forward.

Implement

Now you have a detailed, user-validated design, you can work on getting your product solution out into the wild. As a designer, this step usually involves tight collaboration with your team (i.e. development) to translate your designs into a working product.

It’s good to have a general sense of this framework so that you can highlight your design successes through the lens of a process. Does every designer follow this process? No. Should every designer follow this process? Not necessarily. Again, what’s important isn’t being able to recite a process verbatim. What’s important is how you can prove your decision-making is guided by some sort of process.

Let’s use the example, “Tell me of a time when you had to make a difficult design trade-off.”

At my previous company, we had identified an opportunity to improve our new-user onboarding flow to be simpler. My task was to redesign the entire user flow to increase completion rates. I started by looking at existing metrics around flow drop-off points as well as qualitative feedback we were receiving from app reviews. Based on this data, I found there were a lot of questions that we were asking during sign-up that felt unnecessary & drew out the sign-up process longer than they wanted. After consulting with the team on what questions we absolutely had to keep, I worked on updating the sign-up flow to only have those required questions. As I was iterating, we got some pushback from our brand team because I was designing with our updated product UI which hadn’t been fully integrated with our brand language. I was pretty bullish on using our new UI because it would be easier to scale as we iterate on the flow. We ended up testing the new flow with users and got signals that they liked the existing design language that was more aligned with our brand. Though it made sense for the org, reflecting back on our original goal of simplifying the flow we decided to defer updating the UI until it had better alignment with our overall brand.

However, not every project is the same or fits into a process description so easily.

We’ve talked about how it’s important to to understand how your process has changed over time as you've grown, but what if you're not yet a seasoned designer? No worries. Let’s go through some different scenarios and how to talk through them:

What if I don’t have any projects or experience to talk about my process?

If you don’t have any design experience, we highly recommend taking the time to work through some sort of personal project to exemplify your skills as a designer. Some examples of this are an existing app redesign or a new app concept.

If you don’t have the time to work on a personal project, think of how you can highlight relevant skills in any of your previous experiences. For example, if you are a recent grad, you could talk about how you collaborated with other students in a group project or conducted research for a paper that you wrote. Another example could be if you’re transitioning from a different career (let’s say product management), you could talk about experiences where you had to consider your users or improve work processes.

Whether you’re talking about a personal project or different working experiences, there are still opportunities to call out your decision-making frameworks. Spend some time reflecting on these moments and consider how they led you to approach design now.

What if a project’s context led to a rushed or barely-existent design process?

If your process is difficult to talk about because of certain project contexts, this is a great opportunity to highlight how you were successful in the face of adversity. When things weren't going according to plan, what pivots did you have to make to drive a project forward? How did you maintain user-focus?

Another angle is emphasizing how this was a learning moment for you. Even without a process, you can reflect on what you'd have done differently with more resources or support. Were there any points of the project you wished you could’ve focused on more (i.e. more user research or time to explore different options)? Were there any takeaways from this project that strengthened your design process?

The main thing to remember is designing products is a series of informed decisions.

Tips

• Don’t explain your entire process. The point of learning to articulate your process isn't to recite it from memory, it's to apply it thoughtfully to your work, and to questions about your experience in interview. You may have a chance to use your process as a way to introduce yourself as a designer, but that’s it - interviewers want to understand how you've worked through actual examples. . Especially considering not every project will follow the same process or context, saying you go through the same process every time is just wrong.
• Don’t be afraid to call out process divergences. Sometimes situations call for a different approach. Don't be afraid to highlight times when you couldn't follow conventional processes, especially if you were successful. Be bold in calling out how your project was unique and highlight how you were still able to make good design decisions (and outcomes) because of it.
• Define your process within your design principles. How does your process represent your point of view of what design is? Or, said another way, what does your process look like as an elevator pitch? Interviewers will appreciate that you aren’t just following the motions, but really thinking about the type of designer you want to be.