Double diamond

Recently I was asked about process in an interview, and at first I drew a blank, because I've never experienced the same process twice. As UX designers, we're all familiar with the ideal process of UX design, and in a perfect world we would have the time and resources to follow the double diamond every time for new features or products.

Imperfect diamonds

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 research practices.

Discovery

(Image 1)

At the two major tech companies I've worked for, I was lucky enough to get to follow the classic discovery process either on my own or with a team. Ideally In end to end design of a new product, the ideal discovery phase process is followed pretty closely. After the team and/or business 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.

Discovery for minor features or changes

(Image 2)

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.

Define

(Image 3)

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.

Develop

(image 4)

This diagram shows the typical process (in order) I prefer when designing end to end products, new features, or visual makeovers.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Deliver

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.

‍

‍

‍

‍