I have developed this process to solve problems often faced when working across departments with other influencers and stakeholders. It provides a flexible framework that can be used in multiple ways. Then, create solutions while considering multiple stakeholder needs, as well as the principles of agile and scrum. Thereby, accounting for a real-time day-to-day work environment. This process is broken up into three phases. Phase I is about framing and understanding the problem. Phase II establishes the user’s mindset, and scenarios leading to generating walkthroughs of the scenarios. Phase III presents accountability for the feedback given by those influencers and other stakeholders. This assists in generating the different templates needed for the M.V.P.
The Breakdown
Team
The ideal team formation is 1 lead or Senior Level UX Designer, 1 product owner, and 2 developers. However, the number of developers is dependent on the makeup of your development teams. A minimum of 1 back-end developer and 1 front-end developer to complete the team and handle any necessary consulting. I would also recommend a scrum master-type who facilitates and negotiates to maintain momentum, but this often depends on how large the company is and what roles are maintained.
Effort
The initiative is essentially a business effort that can be exceptionally large or small. Preferably, it is of high priority. Anyone can then determine what the effort is. Leadership could give the team a list of priorities from a road map and let the team decide, or the leadership can be in a position to dictate the effort. In either case, it should be prioritized with a roadmap.
Estimating
One may often come across teams where members are not sure what estimation is because this process revolves around new business efforts. This could happen for a few reasons, however, when this has occurred, I have a t-shirt sizes methodology, extra small (XS) - extra large (XL). If a metric is used for estimating, the metric can define the t-shirt sizes by using a range. It gives a generic perception of how long something should take to formulate. Examples of this practice have been provided within.
Kick-off
Once the team is formed, the effort is chosen and estimated. The team then proceeds with the kick-off. Squad members and influencers are invited to participate. Influencers will vary depending on which stakeholders are involved (See example below). Here you’ll want to define an overview of what your team will be doing for the duration of the timeline by creating a working agreement that accounts for your work culture. Remember not everyone has time to sit in long meetings, so be concise and explicit with direction.
Sprinting
Identifying the Problem
Identifying the Problem
After the kick-off, you will begin the sprint to vet out the problem and the solution. It’s purely up to the leadership of your team to decide what you want the M.V.P. to be. Consider the capacity of the teams and their day-to-day efforts. It will be a mix of leveraging a few sources to identify the problem. Not only do you want to leverage your squad member expertise, but you will also want to leverage those influencers who are subject-matter experts for their department. This can be done in a few ways in the form of flash talks, stakeholder interviews, etc. Also, leverage any user research that you have relating to the matter and the analytics.
Utilizing Data
The data in its different formats is critical. Each piece tells the user's story. Missing any of these pieces will make it difficult to identify the problem correctly. User research gives a lot of soft data that can be paired to a 5-10 point scale, to give more of a metric-driven outcome. Considering this can show us what the user prefers, and when, what they say versus what they are doing, conflicts. Analytics can confirm if existing features are successful and often serve as a backup to user testing when paired. The influencers give us a better perspective and understanding of their business side. It reveals different areas of the problem and why something may or may not be a problem.
Hypothesis
Once your team has absorbed and processed the data, you’ll want to generate a hypothesis of the problem; relating issues and where there may be overlap. This should also lead to generating assumptions. Just remember for every assumption you will want to identify the risk.
User Mindset
The mindset of the user is essential. You will start by leveraging the personas. if you don’t have them, leverage this part to create them. Also, utilize a researcher or user research. Creating a journey map helps to understand the user's basic choices throughout the entire exercise. It also highlights different parts of the exercise as the mindset shifts. Have user scenarios crafted so they can be simple stories of the product being utilized in different day-to-day user scenarios. All of these mechanisms will assist in your squad's understanding of the user mindset.
Conceptualizing
In my experience, conceptualizing is the most difficult step because it will include sketch sessions. Everyone is expected, regardless of their level of ability or creative background, to articulate the mindset, at a precise moment, in the company of one another during these sessions. As is human nature, people who are not from a creative background, time and time again, become self-conscious and may not be able to properly articulate the mindset. It is very important to be sensitive to this fact if you are the facilitator.
To help, after obtaining the mindset and the scenarios, generate a feature list. Start at a high level, then narrow it down to the system, or api. More than likely you will want a developer to consult with on this. Learn the strengths and limits of the current systems.
After you have constructed a feature list and design flows for the specific scenarios, everyone should begin a sketch session(s) that generate low-impact walkthroughs of each scenario. Sketch sessions should not go beyond 10-15 minutes for each scenario. Dot voting has proved to be an essential and my preferred mechanism to come to a consensus on one version, which is normally a combination of all versions presented. Repeating this process for the last phase focuses on generating all the templates for M.V.P.
To help, after obtaining the mindset and the scenarios, generate a feature list. Start at a high level, then narrow it down to the system, or api. More than likely you will want a developer to consult with on this. Learn the strengths and limits of the current systems.
After you have constructed a feature list and design flows for the specific scenarios, everyone should begin a sketch session(s) that generate low-impact walkthroughs of each scenario. Sketch sessions should not go beyond 10-15 minutes for each scenario. Dot voting has proved to be an essential and my preferred mechanism to come to a consensus on one version, which is normally a combination of all versions presented. Repeating this process for the last phase focuses on generating all the templates for M.V.P.
Artifacts Generated
Depending on what phase of the process you are experiencing, you may have different artifacts generated. You will want some type of concise documentation; a word document, pdf, etc., of your findings and next steps. A feature list that equals an M.V.P. plus future iterative work, paper, or digital prototype is an ideal way to go. This will also be dependent on your work culture and people's preferences. The iterative work should trickle down into your day-to-day work cadence.