Below is the process that I follow when possible in order to deliver the best and most valuable product possible. Every project and customer are unique based on each individual needs and timelines. This process varies based on if what I am working on is a small or large feature enhancement or a 0-1 new feature.

In every step I include the stakeholders and engineering leads to ensure collaboration and feasibility during the design and build phases…Let’s not do rework if we don’t have to.

Research & Discovery

Why are we building this?

This is my favorite and most important part of the design process. As a designer we work on designing the product daily, but we are not using it daily the same way our customers are. We have a good understanding to make a few well-educated assumptions, but in reality we need to involve our user base to validate those assumptions and by doing that, learn even more than we thought in the process.

When deciding what to build next and prioritizing a roadmap, there are a few very important questions we should ask ourselves. Why should we invest our time and resources into building this? How is it going to impact the customer? How is it going to impact our revenue? Who should we talk to? How many people should we interview? Working with multiple teams and stakeholders we first need to find the “why” so we can prioritize the “how” and “when” correctly.

Customer feedback interviews, NPS surveys, app store reviews, and a competitor analysis are all great places to source data to start being able to gauge if this will be valuable to the customers as well as the product…Let’s not build something just to build it.

For a new feature or product, I start out with interviews with the stakeholder to understand what problem they are looking to solve along with the demographic that they plan to target. I also set up user interviews for targeted users to really understand their pain points and why the feature or product should be built in the first place. We then begin creating a strategy which includes features for MVP, a roadmap, branding and visual aesthetic (if it doesn’t exist already), and also their long term goals so the product can be scalable. The stakeholders and I also create a plan on how to measure success which can be determined by a number of different metrics including downloads, active users, and conversions. At this research phase personas, journey maps, and empathy maps are also created to understand the user and their journey from end to end. After I get an idea of what the specific problem or problems are to be solved, I begin creating a competitor analysis including an in-depth look at what competitors are doing in same industry.  I can then evaluate what they’re doing well, what can be improved on, and what could be added or modified. 

If the feature or product is already existing, the first thing I do is figure out if the stakeholder would like to add features, enhance the existing features, or do a complete redesign. If there are analytics for the existing product, I complete a heuristic review to see what features or pages are viewed and utilized the most and where users tend to drop off or close the product. This information may indicate a need for a change in IA or user flows that could enhance the user experience. Reviews in app stores are also a good source for repeat reasons and struggles for giving the product a lower rating. I conduct user interviews to establish what main pain points the current users have, what problems they use this product to solve, and how they usually utilize the product to get from point A to point B. This is also a good opportunity to gain feedback on their preferences, their likes/dislikes, and what they visualize for the future. After gathering all of that data, I start to conduct user interviews. From the research I gather, I begin to gather requirements and start to phase the roadmap out.

This piece of the design process also includes creating user personas. After getting the targeted demographic it is possible to create these personas whether it be in specific industries, different age groups, or regional use cases. This helps get an idea of which people will be using the product and how to design it for multiple cases. 

Whiteboarding/ Sketching

Starting the design process.

At this point, FigJam, Post-It Notes and Dry Erase Markers are my best friend. This is where I go about brainstorming and incorporating requirements, IA, user flows and collaborating with a team if there is one. I also bring in engineering at this point for a high level overview in order to establish what is and what is not possible for either the sprint or the release before I get too far ahead of myself. At this point we can also begin to talk about phasing for a release strategy.

All of this allows me to embark on creating a site map and user flow. It also allows me to start phasing out the work for design as well as prioritizing what needs to be completed first based on dependencies. This stage is very collaborative and iterative and involves detailed communication with the stakeholders and engineering. After I have an idea of what user flow and IA will be used, I take everything and begin creating preliminary sketches of the elements on each screen, navigation, and I begin roughly laying out wires.

Wireframes

Refine the ideation.

After taking my preliminary wires and sketches from the white boarding phase, I begin to bring them into wires. I frequently meet with engineering during this stage as well, in order to ensure that what I am starting to create is feasible in the sprint or time constraint from a technical perspective.

I create low fidelity clickable prototypes in order to make it easier for the stakeholders to digest and envision the flow for the product. From these prototypes we are able to refine the requirements as a group and get a better understanding across the team of the direction design is headed in.

Low-Fi wires and prototypes are fast to assemble and easy to change on the fly when changes and iterations arise. They are all black and grey, basic fonts and avoid imagery and iconography to prevent distraction by the UI which enables the stakeholders to focus solely on the UX and content on each screen.

User Testing

Does it work?

This stage in the process is iterative and based on the user’s feedback. They indicate what they like, dislike and what aspects they may be stuck or confused about. Task based testing allows me to see if the user can get from point A to point B with minimal struggles. I write testing scripts and utilize low fidelity wireframes and clickable prototypes to make certain the users tested aren’t distracted by unnecessary UI or branding. I can also gather feedback if this workflow or feature is truly solving one of their pain-points and if it will be a valuable addition to the product. It’s good to know at this point if it’s a confusing user flow or not worth engineerings resources to build. Work smarter, not harder!

I also involve engineering and stakeholders in each iteration to ensure that the changes are still feasible and make sure everyone is on the same page with updated requirements if there are any.

There are a multiple different types of user tests I typically conduct based on the criteria being tested. This can vary from a user feedback survey with predetermined questions, a recorded testing session (I have discovered that when users are able to proceed at their own pace without a facilitator, they tend to feel more comfortable), moderated task based testing, or A/B testing which is more beneficial for new features or experimenting with ideas before launching to all users. I conduct as many rounds of user testing and iterations as possible within the given time constraint. It’s easier for design to iterate at this point in the process more than it is for engineering to have to rebuild.

UI Design

Make it friendly.

Next in the design process, I need to determine if there is a previously created style, brand guide, or frontend framework in use. If there is not, I work with the engineering team and stakeholders to weigh the pros and cons of using an existing frontend framework or designing a custom one.

If we choose to create a custom design system, I first assemble a color palette, logo set, iconography standards, and library of reusable components using atomic design. I create a mood board of colors, images, and examples from other apps and products as and take into consideration feedback from the stakeholders.

Once a brand or style is agreed upon, I will take my wires and create a visual aesthetic and follow the design system including colors, logos, typography and iconography - I create my own if there are not some already created. I involve stakeholders for feedback throughout the entire branding and UI stage and make as many changes or iterations as possible within the agreed upon deadline.

Production

High fidelity design finalized.

Finally, I hand my work off to engineering.

This incorporates UI screens in Figma or Zeplin for redlines, annotated wires to show engineering the flow and interactions on each screen, and a clickable prototype to allow them to walk through the user flow for larger features. If there are animations involved I compile After Effects videos, export animations in Lottie, or find a third party library for the language for which they are coding in.

Collaboration and communication is key at this point and I make certain that I am available to answer questions or clear up any confusion the engineering team has of the deliverables. 

Validation

Did we achieve our goal?

After everyone’s hard work, we are able to use data and metrics to validate what we just released is working and we built something that is valuable for the user and product. From that we can make the decision to leave it as is, deprecate it if it’s unnecessary and just another thing that we will need to maintain, or start growing out a roadmap for added features and enhancements.

The more channels we utilize for feedback, the more results and answers we get. Let’s face it, the majority of users don’t want to waste their time with surveys or interviews. The more we can do to target the users that do want to provide useful feedback, the more data we will have to work with.

Depending on what was released there’s quite a few ways to validate what we built is correct and works. For larger features I like to set up user interviews from heavy users so that I can get their direct feedback of what they like, what they don’t like or what they find confusing, and what they think is missing to help get input on how to create a roadmap and start phasing out future work. It’s also a great way to get a good idea how to design to allow for scaling in the future.

We can send in-app targeted surveys to a specific segment of users that we have identified as heavy, repeat users. Instead of sending a survey that is not necessarily relevant to all users, we are able to target the specific user segment we want to gather data from.

If it does make sense to send out a general feedback to survey we can send it out to a majority if not all of our users for feedback.

We are also able to set up UX metrics to collect and compile data. How many users are using this new feature or enhancement? How many clicks are we getting? How many are repeat users? Is there a drop-off point where most users are abandoning the page or workflow? From that can we start understanding if it is based off confusion or if the workflow just too long. These metrics should be shipped with every new feature or enhancement and before launch, the data and areas UX would like to focus on should be outlined in the epic or story.

Sometimes we miss the mark and thats ok. Lot’s of lessons and learnings come from failures, even though it’s rough to see that data and response from users. We just need to learn from our mistakes and take that knowledge into the next iteration or project.