As UX designers, we're all familiar with the ideal process of UX design. In a perfect world we would have the time and resources to follow this procedure for every project, large and small, within reason.
In my experience, at any size company there may be constraints at every step of the process, and it's necessary to think creatively in order to deliver the right solution without over relying on assumptions, anecdotes or inadequate substitutions for good
In end to end design of a new product, the classic discovery process is followed pretty closely. After the team has brainstormed a great idea, the next step is to leverage any and all UX processes to ensure that the product is set up for success and scalability.
For fairly complex new or added features, this process would ideally be followed as well.
What about designing new or better features to improve the experience of an established product?
It may be as minor as adding a button or improving a small interaction, and in these cases, updates or fixes may be required with constraints on time, resources, tech, or budget. It's tempting to turn around "quick fixes" immediately but we shouldn't take it for granted we have the right solution just because it can be tweaked in Figma in an hour or two.
The tasks marked mandatory here are based on the fact that they can be performed by a lone designer. It all depends on the circumstances of course and in many cases it would be preferable to base design decisions primarily on some quick A/B testing or other user research.
Once the initial discovery work is done for a new product or major feature, the next task is gleaning all this information you've collected to create a clear problem statement to solve for. This should always be a collaborative process involving all relevant stakeholders. It makes life easier for the designer by providing clarity, focus and a clear direction for ideating with. Customer journey mapping and service blueprints may be refined during this phase based on new information gathered at this stage.
For small fixes to a product or feature that's already built, most likely the problem statement will be included by a PM or designer in the user story.
This diagram shows the typical process (in order) I prefer when designing end to end products, new features, or visual makeovers.
I like to thoroughly review the discovery work, even if I helped collect it, and have a kickoff meeting with the PM. They can communicate the scope, deadline, and the extent of user testing I will have access to. I would then love to have a kickoff meeting with the dev/team who would be implementing, with the goal of double checking the capabilities of the design system components, go over any custom ideas I may already have, and check the policy on contributing new patterns to the design system in case it comes up later.
Designing a user flow always saves time in the long run, and I can use artifacts from the definition phase to ensure that I'm basing the flow on user and business goals. I would consider storyboarding a "great to have" if time permits.
Low fidelity simple wireframes are the quickest way to produce iteration 1, without getting in the weeds re color and microinteractions, and is also great for sorting out information architecture if for some reason it wasn't done in the definition phase.
Feedback is one of my favorite parts of the process, as it gives me an opportunity to validate or defend my design choices or get valuable insight into factors I may not have been aware of, or different ways of approaching a given problem.
It's great to know in advance which kinds of test methods and how many rounds of testing so I can base my prototypes and questions on what makes the most sense. If I'm doing my own testing I like clickthrough prototypes that are as interactive as possible.
In my experience, the deliver and implementation phase are the trickiest to pull off. Adequate communication and updates with your developer at every stage is crucial so there are no surprises or last minute blockers.
Documentation every step of the way by leveraging version control in the design tool are crucial. It's important for the next designer or any team member to understand the why behind design decisions, and highlight any aspects that were controversial or untested due to time constraints. Presenting a final iteration to stakeholders is a great idea, just to keep everyone in the loop and field any final concerns or to document any ideas that come up for the next iteration of the product or feature.
B Blakesley ©2024
