Clients will ask how the process of understanding and defining their product will differ for their industry — FinTech, Scientific, eCommerce, Trucking, Customer Service, etc. Their concept might be unique to the market or tried and true. But the question usually arises, “How will you change your process to fit my idea?”. The answer is simple, but rarely what the audience is expecting.
The user experience process is a repeatable methodology that is adaptable to any industry. The process allows a UX professional to quickly understand the wants of the stakeholder and the needs of the users within whatever sector the product will reside in. The UXer doesn’t need to have experience within that niche industry as long as they can listen to the users, learn fast, and adapt quickly.
A Repeatable Process
The UX process helps us to define a problem, identify and empathize with users, and ideate and iterate through solutions. There are frameworks you can follow, like Double Diamond or Design Thinking to support your flow. The longer I work in the field, the more closely I align with the Triple Diamond framework, as defined by ZenDesk. Specifically, the first two diamonds representing Discovery. The user experience process will continue throughout Development to the end of the project, but starting a project with a firm understanding is crucial for building a successful product.
- Discovery: Research & Document
- Definition: Create, Vet, & Clarify Requirements
- Solutioning: Ideate & Iterate
- Validation: Test & Refine Solutions
The time needed for the UX process scales with the size of the product or feature. If the feature is small and the product is already defined, the user experience process can typically yield results in a sprint or two. If you are creating an entire product from an idea to launch, more time will be needed.
The process needs to be flexible in time, tooling, and deliverables. I have seen the desire to follow the same deliverable path in junior UX designers — A happens, then you do B, then you do C… For example, not every project requires both a journey map and a user flow. In fact, I would argue that most of the projects I have worked on have only needed a user flow to refine the product and create a build roadmap for developers. Especially in consulting, you need to be able to work through the process and fit it into a reasonable amount of time. The UX process should not be followed so strictly as to limit the ability to move quickly. This sometimes means moving forward with lower certainty, being comfortable with ambiguity, and identifying when you have just enough information.
This sometimes means moving forward with lower certainty, being comfortable with ambiguity, and identifying when you have just enough information.
The user experience process intends to:
- Clearly identify and articulate requirements
- Capture and refine documentation and concepts
- Validate the product through testing with real users, analyzing results, and applying user feedback
- Speed up development through understanding and solving problems early, saving time fixing or refactoring components, flow, and interaction problems later — resulting in cost savings in the build process
- Establish confidence in the product to give it its best chance in the market — lowering risk and providing a better return on investment
Finding New Solutions
Part of the problem with the statement “I want to build the next Uber/AirBnB/Facebook for [industry]” is that a stakeholder may covet something in that other product. Each product is different, and while one can leverage patterns that users are familiar with and utilize design systems to have similar aesthetics to the target product, the product will be built for your industry and should be a differentiator.
Your product should not just lift how Amazon’s cart system works verbatim. You shouldn’t use the same checkout flow as Target’s app just because you like that flow. It is important to know how we came to the decision for your product. As an outsider, you can’t know what restrictions led to the decisions that became the feature you like in another application. If you choose to simply copy someone else, you limit the potential for your solution to be something better. Every decision for your product needs to be made for your product and tested with your users to define its usability and adaptability. The UX process will help to identify solutions for your users in your market.
Process Purpose
The user experience process will help vet the concept, refine the product flow, and define the requirements that users desire for adoption. This protects your project in many ways. First, the UX process will test to see if the concept is feasible and if users need or find value in your product. If the users’ response is not favorable, perhaps the initial concept should be revisited.
The UX process also creates deliverables like journey maps and user flows. These deliverables start an ongoing conversation between your Product Manager, UX/Product Designer, and Lead Developer to refine how your product will flow and function as well as reduce emotional investment.
User flows, personas, requirements, user stories, etc., will help speed up development time. Developers should use these artifacts as roadmaps. User stories directly translate to epics and issues in project tracking programs. At this point, all of the work will have been vetted with an engineer, your stakeholders, and your users. With these deliverables, many of the problems a developer would encounter in coding have already been solved. This allows devs to focus on the build rather than finding solutions. The summary here is — the UX process helps protect from loss in the form of time and money.
Discovery
The most important part of a Discovery is that this is the time to define high-level requirements for a product or feature. This phase is filled with research, workshops, surveys, observations, interviews, and, most importantly, documentation. As you establish requirements for the product, you need to evaluate each requirement with your stakeholders, users, and engineers.
You want to make sure that:
- The product/feature concept aligns with your stakeholder
- The user base is defined, and that user finds value in the product/feature
- What the concept is can be built by a developer
The UX process aids in providing solutions based on research, observations, and qualitative and quantitative data. The process will help to define the requirements for your product — but your stakeholder needs to be willing to accept the feedback and pivot if and when needed.
Many clients will come to the table with a solution in mind, but the user experience process should not be used to prove preconceived solutions. People often express desires in the form of solutions because it can be difficult to articulate their thoughts in another way. When collecting information, it can be important to let others know that “we are trying to avoid solutioning at this point” and try to pull out as much of the reasoning behind someone’s suggestion. Ideally, the process will uncover and point to concepts and objectives that will eventually form into solutions not thought of prior, or be more straightforward than initially thought.
Definition
Once a base understanding and agreement on what the product/feature will be are reached, you can start explicitly defining the requirements — a view of what needs to be defined, understood, and where solutions need to be created. You will start with a 20,000-foot view, and the more that is understood about the product, detail will move towards a microscopic view of the requirements. The lines around deliverables start to get blurry here since we will be cycling back and forth between Definition and Solutioning (and eventually Validation) throughout the remainder of the process.
Documentation should continue to be updated to represent the current state of the understanding of the product. This is where you will start creating user flows, vetting with developers, wireframing concepts, etc. Keep versions of each deliverable — for example, as you learn more, or your understanding of your user flows changes, a new version should be created for the next exploration. Retaining prior versions of deliverables will help to tell the story of “how we got here” and will help to answer questions like “have you tried this?”. It is simpler to pull up an older version of a wireframe, prototype, flow, etc., and define why something was tried, and the direction of the product was changed, than to try to explain without visual support.
Retaining prior versions of deliverables will help to tell the story of “how we got here” and will help to answer questions like “have you tried this?”.
Solutioning
Obvious solutions will emerge from the research and methodology phases. During the Solutioning phase, we will use our understanding of the product to build prototypes, test with users, and iterate, test, iterate, test, and so on. The deliverables and understanding gained from stepping through the UX process will be informative and hopefully unbiased. It is up to the stakeholder to approve requirements and accept the direction of the product as understood through those results. Because the process is cyclical, you will find yourself returning to the research and refinement practices from earlier phases to capture more details.
As a client, it is important to find the ideal budget for Discovery. Not enough time for Discovery will lead to lower certainty and not fully defined requirements for your project. Too much time can lead to excessive information gathering and no clear deadlines to work towards. It is essential to find the Goldilocks Zone for the Discovery phase of your project. The “just right” perfect timeline allows for research, leading to higher certainty in recommendations, clear user stories, and includes all of the deliverables needed to move forward into a successful Development phase.
Validation
To know that you have arrived at a correct solution, you will need to test with users. This testing begins in the Solutioning phase and is completed when your qualitative and quantitative data have resolved to the results you are looking for. For example:
- Are all the tasks your users need to complete included within the product?
- Can your users complete all the tasks successfully for what you want to achieve in your MVP?
- Are all inputs, interactions, and patterns included that enable users to complete all tasks?
- Can users complete all tasks in a reasonable amount of time?
- Are you users able to complete all tasks without issue?
As each of these responses moves toward a higher positive correlation, the validation of the solution becomes increasingly clear. There is a threshold to how much validation is “enough” to begin the handoff process to developers to build the product. This threshold varies by project and is informed by things like timeline, budget, and intended release cycle. Your stakeholder will need to weigh the value of having higher confidence in the solution versus a lower budget, moving into development faster, and the risk of having issues that would need to be followed by additional releases to fix or refine.
Trust the Process
A common question in sales meetings is, “yes, but how will your process work for our product/industry?”. Everyone has a passion for their product and wants to see that passion reinforced by the team taking on their discovery and documentation. And every project benefits from the user experience process. The UX process can be tailored to fit the time allotted (within reason) and budget (within reason). The UX process itself doesn’t change much from industry to industry, product to product, and feature to feature.
User Experience practitioners use the UX process to learn and work fast. A team or individual with a successful track record of implementing the UX process can approach and add value to any concept from any market.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
