My UX Design Process

A framework I use to create digital products.

Going into college, I would have never imagined myself as a designer. I always thought the title “designer” meant some sort of artist, living in a studio either alone or with other artists, painting/sketching morning till night. That, or some sort of fashion designer, sketching images of clothing in an industrial-looking room with bits and pieces of garment all over the place. These are all without a doubt examples of designers, but I realized that design is so much more than sketching, painting, or pasting together pieces of clothing. It’s a process. 
 
Coming from a business background, I see design kind of like consulting. You’re given some sort of problem and you’re expected to come up with a solution. As a business major learning about design, I started understanding the role design played within business and the constraints that always need to be kept in mind when solving a solution. You’re not only solving the problem given, but also solving it within the context of the business. 
 
During my journey as a designer, here’s a process that I’ve built for creating the UX of digital product. It’s still a work in progress and I’m constantly refining it, but here’s a first stab at it:

Context is Key

When solving a problem, it’s crucial to understand the context. Without context, it’ll be difficult to make informed decisions and frame the problem. A few questions I like to ask myself when establishing context are:

  1. Who are the direct/indirect competitors? What are they doing differently from each other?
  2. Are there industry standards? Are there certain laws that inhibit certain solutions?
  3. What target demographic am I designing for? My design decisions are drastically different when designing for a 13–19 year old teenager from Brazil vs. a 22–30 year old working professional in San Francisco.
  4. What constraints am I dealing with? (timeline, branding, for mobile or website, ios or android, etc.)
  5. What are some metrics that can validate the success of my potential solution?

This is also the time to list out assumptions. I list them out and try to validate each one through research during this phase. Any assumptions that aren’t validated during this phase end up being great interview questions to ask later on.

Who’s the User?

Once I understand the context of the problem, it’s time to shift into the context of the user. Understanding who exactly is using the product is incredibly important because at the end of the day, they’ll be the people who judge if your product is worth using. If you’re not designing a solution to fit in the lifestyle of your user, then your product won’t have a high chance of succeeding. A few things I consider when I try to understand who I’m designing for are:

  1. Creating a user interview guide. I make a list of open-ended questions and like to break off my interview questions into sections starting broad and then going narrow. For example, say I was interviewing different people to uncover habits when drinking wine to understand the best way to present/sell wine on an e-commerce platform. I would start my questions broad by asking “How many bottles of wine do you drink a month?” Someone who says 1 or 2 bottles would probably be a light drinker, while someone who says 3–6 would be somewhat of a wine enthusiast. Depending on the answer, I would have a different set of questions lined up. This way I’ll be able get insights based on different market segments.
  2. Unravel what’s bothering your user with open-ended questions. When coming up with questions, make them open-ended and validate your assumptions and identify user needs, goals, and pain-points.
  3. Interview your target market and SMEs (Subject Matter Experts). It’s crucial to schedule interviews with your actual target market because they are the ones who will actually use the product. Each interview you do provides valuable insight, but if you’re in a time crunch, 5 is a good number to start with.
  4. Think qualitative vs. quantitative. I found that asking questions to gain qualitative information was a good way to then create a survey to quantify those answers. Asking open-ended questions for a survey generally doesn’t give great results. People just don’t have time.
  5. Card sorts if you need to rank certain items. Sometimes I run into situation where I need to understand how a target user prioritizes or groups certain elements. Card sorts are your best friend in these situations.
  6. User personas. A lot of designers have mixed feelings about user personas. Personally, I think they’re great if you’re working with a client because you can refer to the persona when validating your reasonings behind certain design decisions.

Bringing Everything Together

Once I interview my target users and SMEs I usually end up with a ton of information. I like to use post-its and start writing findings from each of the interviews and posting them on a wall. When I take a step back to see the big picture, certain themes start emerging from the findings. At this point, it should be somewhat clear problem(s) the target user and/or the business is facing. I keep those problems in mind and write out some key, overarching takeaways.

Framing the Problem

Problem Statement
Based on the findings/insights, I make a problem statement to act as my north star throughout the rest of the design process. A lot of people say that the problem statement is the UX version of pixel-pushing for UI, and to a certain extent I agree. This is the stage of constant tweaks and refinement to truly identify and frame a specific problem that needs to be solved.
 
Design Principles
Once I have my problem statement down, I think about the core values of the product itself and what principles I want to abide by. These ultimately boil down into three or four design principles that I refer back to during the idea generation/wireframing phase. 
 
This is a good list of design principles from great companies!
http://www.designprinciplesftw.com/

From Chaos into Structure

Let’s take a look at what I have so far. Up to this point, I’ve learned about the context of the digital product, identified who the user is, interviewed users in the target market, talked with SMEs, synthesized my findings into clear takeaways, framed a solid problem to solve, and created design principles to guide my design decisions moving forward. 
 
Looking at the takeaways, I align the needs, pain-points, and goals of the user with content/features I want to be present within the digital product. It’s also very important to make sure that the content/features you list out also align with the main problem that you’re solving. 
 
Creating Structure
Once the content/features are laid out, I group items that drive a specific priority into different pages. I take a step back and try to find out if there is some sort of order to the pages. Once an order is established, it’s important to validate it by mapping out different entry points and paths a user would take to arrive at an end point that clearly matches with the user’s goal. 
 
Crazy 8’s
At this point, features and screens to be designed are clear. I like to do a round of crazy 8’s, which is basically a way of sketching out 8 different concepts within a short time span, for each of the screens that need to be wireframed. 
 
Dot Voting
If I’m working alone, I choose which concepts I like the best and then start the wireframing process. If I’m with a team, I like to do something called dot voting, where each team member gets a set of dots they get to stick on concepts they like. The concepts with the most dots get pushed into the wireframing phase.

Prototype

Wireframes are good way to lay out priorities, goals, and requirements into a greyscale digital design. Based on the most popular concepts from the previous step, the team wireframes a personal rendition of the concept. After wireframing, we test on users that fit the target persona to identify positive/negative features and validate the flow of the product. After the first round of testing I iterate right away so I can get feedback that isn’t repetitive for the next round of testing. I generally do 5 user tests to uncover most of the faults within the designs. 
 
Convergence
After testing the designs, I look at the feedback of teams designs and converge on features that tested the best and work well together. After converging, I do another round of user testing to iterate and optimize the designs.

Done

After testing, iterating, and optimizing the wireframes, I usually have a solid wireframe that can move to the visual design phase where the skin gets put on to the skeleton. That’s it for my UX design process. I’m still working on refining it but let me know what you think!