The Product Design Process
Intro
As an organisation delivering a product we want to focus on what will bring the most value to our business. This means being clear about the problems we are trying to solve and where our solutions fit in with our overall product and business strategy.
Below is an outline of my product process. There are two key phases, the problem space and the solution space. Separating these is vital to delivering valuable software that solves a customer problem.
Phase 1 – The Problem Space
In the problem space we gain an understanding of the ‘why’ behind the idea. - What is the problem that we are trying to solve?
This may involve any or all of the following activities:
Recognition of an issue.
The very first thing to do is to pay attention to what we need to do. This can come from many different directions.
Usually, product direction comes from two main sources.
Root-cause Analysis
What is the core of the problem that we are trying to solve? Conducting root-cause analysis allows us to really get to the bottom of the problem and to avoid starting with a solution.
This is where we ask ‘why?’ a lot. Common practice is to come forward with a cool solution and think we need to have it. The more we ask why, the more we get to the root of the real problem we’re trying to solve. Sometimes we determine that no problem exists.
At this point we are actively avoiding solution ideas. This keeps our minds open and focused on the problem – What is wrong, and why. What can we do better, and why.
Competitive Analysis
Who or what are our main competitors? Are these direct or indirect competition? Direct competition is the easy one – who is offering a similar product in a similar market. The indirect competitor is more difficult to spot. In the case of betting products with Avid gaming, an indirect competitor could be any other way a customer decides to spend their leisure time.
Our Competitors for Sports Interaction
Why do we do this?
To understand market standards and identify opportunities for innovation.
How do we do it?
We analyse competitor products focusing on their design, features, and content strategy. We pay close attention to the context of a feature to gain an understanding of what our customers may already know.
We can find implied standards. This means common UI patterns amongst similar products. If a user already understands these then there is less thinking needed to explore our version.
We can learn from the mistakes of others. If we see an apparent feature overload or a user journey with unnecessary friction then we can stand back, re-think and take it another direction from the competition.
What we gain
We get an insight into industry best practice, common failures, and potential areas for differentiation. We gain time based on the testing ground of others.
What we learned from this competitor analysis
User experience showed more friction than we would count acceptable in a new feature. We should emphasise this to avoid alienating or annoying customers.
Competitors are emphasising flexibility – bet your way. We can either build on this or take it in another direction but not copy directly.
Standards to adopt: ‘SGP’ is commonly used. While this is useful in its brevity it requires insider knowledge. We differed from competitors where we wanted to be seen as the most welcoming to new players. For this reason we will only use ‘SGP’ where the full name, ‘Same Game Parlay’ or ‘Same Game’ Betting has already been used in the context.
Persona creation / use
Why we use personas.
To empathise with the target audience and tailor the solution to their needs.
To better understand the problems that we are trying to solve and ensure these are real problems for real users.
To remove the false consensus effect in our team; more commonly known on our teams as ‘We are not the user’.
How we create personas
These should represent typical users including demographics, behaviours, and goals. We can derive these based on behaviour analysis – a combination of qualitative and quantitative research. This may be different each time as we look at different aspects of the product. For one update, past user behaviour or friction may be important and for another, aspirational features may carry more weight.
Ideally, we stick to 4 or fewer personas.
We round out the persona and create an image for it to make it more real in the heads of those creating a solution. We give the persona’s names so that they are a person, and not just a list of attributes. We want to reach a point where the team feel like they know this persona. Say we call one ‘Greyson Green’ we want the designer to think ‘what would Greyson Green do or think or feel in this situation?’
The Aspirational Persona
This persona is not based on current customers but represents a target customer group that is not yet in our grasp. This is most useful for marketing messages.
Who we Involve in Persona Creation
At Avid Gaming, personas were created by the product team in close collaboration with marketing. While other team leads were not directly involved in their creation, we made sure to bring them along the journey starting out with why we were creating personas.
Personas in Use
To make personas work. To make them most useful we need to have them as a constant presence in the workplace (physical or virtual). When talking about problems or creating solutions, we frequently ask which persona we’re targeting, which one we’re helping, where the cross-over is, whether helping one will hinder the other. We speak about them by name to make them real. This keeps us laser-focused on who we are designing and building a product for.
Personas we used at Avid Gaming:
Greyson Greene
Been-around Ben
Casual Clyde
Try-it-out Taylor (aspirational)
Brand Alignment
Brand is every experience a user or potential user has with our product, personality, or reputation.
When we work out the problem, we think about whether it is damaging the brand. Will solving the problem help to push our brand experience in a positive direction? Will neglecting to solve the problem cause negative effects for our brand in the future?
To determine this, it is helpful to have a clear outline of what our brand aspires to be. This acts as a focus when we are making decisions for the product and prioritising fixes and enhancements.
Here is what the Sports Interaction Brand Outline looked like
Business Strategy Alignment
The business strategy allows us to focus as an organisation on certain goals.
Here we determine whether we are defining a problem that affects our overall business strategy or not. This is one more factor that will help us to refine what the problem is that what its effect will be on the business strategy.
In essence here we translate a user problem into a business problem or de-prioritise it if solving it is not in line with our overall goals.
Lean UX Canvas
The lean canvas allows us to state in a single page what the problem is, some suggested solutions, some hypotheses, some restrictions, and an initial idea about what we can do first to learn more about the problem.
The lean canvas allows us to describe all product updates in a similar manner so that it then becomes easier to compare the value of one against the other.
In the case of ‘Same Game Parlays’ we began by noticing a weighting towards a certain type of error message. Through quantative and qualatitive analysis we learned that at the core of this issue was a customer need or desire for combining selections for a single game in one bet.
Through personas we hypothesized that for one persona group – Greyson Greene, users were attempting to combine selections for the same event because they didn’t know there was anything different about this bet type.
We hypothesized for the other group ‘Been-around Ben’ that this user type was expecting this functionality because he had seen it in other sportsbooks that he has used.
How we made sure we were staying on track.
Our tool of choice for in-team and across-team communication was KanbanTool. This did what it said on the tin. It was a Kanban board. We customised the cards on the Kanban tool to contain the sections from the Lean UX canvas. This strongly encouraged people to fully fill out the rationale behind product proposals. One proposal versus another proposal was therefore easier to compare.
Roadmap
We use this to make a provisional plan for our next few weeks and months. It is open to change but today this is our plan.
The roadmap allows us to compare one task or project with another and determine which one has a higher priority.
The roadmap also gives us an idea of where resources can be used most effectively and when. In our case we were mostly concerned with design and developer time.
All of the above tools and methods allow us to clearly define what the problem is that we are trying to solve and to prioritise that against everything else we are trying to do.
Phase 2 – The Solution Space
Once the problem is defined, then, depending on the nature of the problem, we can use an appropriate selection of the tools and processes below. Essentially, we are looking for good ideas to solve the problem and good ways of executing those ideas.
We can start by exploring lots of solution variations at a shallow level, then, armed with more knowledge about customers and technical feasibility we can narrow our solutions down. The tools below should not necessarily be used in this order or as distinct stages from one another. Technical feasibility and ideation could happen in the same conversation between developers and designers. MVP selection may arise from usability testing etc.
The toolkit that we draw upon in the solution space consists of the following:
Ideation and Concept Development
We generate creative solutions, starting at a shallow and broad approach. Involving designers, business owners and developers early means that technical challenges will be outlined and there will be a feeling of co-creation, giving stability to later project stages.
This stage usually includes wireframes or sketches that allow good communication while changing direction and exploring a lot of different ideas.
Wireframes do not look like the finished product. This means that a person will not get tied into the solution. It doesn’t look real, therefore it is easy to change or challenge. When the design detail is removed it allows the group to focus first on the user journey.
Wireframes are frequently accompanied by user journey maps. We liked to use FigJam (an offshoot of Figma) for this because it allowed anyone to comment or change the diagram during our conversations.
We create scenarios in which our personas would interact with our product or product feature. We identify the challenges for each persona or other user segment. We challenge one another with ‘what-if?’ scenarios to ensure we have no surprises later.
Technical feasibility
Here we determine what might be involved with building a proposed solution. We look at all the other parts of the product that it interacts with or shares components with. While we are focused on the user experience, the effort to build a product feature or change must be appropriate for the advantage we gain from it.
In the case of same-game combinations, a big technical challenge we faced was the speed at which we could pull in prices for the combination bets. This heavily influenced the choices we made for the user experience. We would either simplify the number of prices we were pulling in or we would make the waiting time more pleasant. We didn’t count on the patience of our customers so we went for the former.
Minimum Viable Product (MVP)
We decide what is the least thing we need to do to learn the most about our customers. This thing could be a stationary prototype, an interactive prototype, a live A/B test or a customer test group discussion. The last one was used rarely at Avid. We generally preferred to go on what a person did rather than what they said.
Test driven development ensures we stay on the solution track always. When we are building the MVP we always have a goal of what success looks like. Success may mean a change in user behaviour, a higher satisfaction rating, reduced friction, or fewer bugs.
For the same-game betting task, we really wanted to know if customers would want to use the functionality of being able to combine bets on a single game. Before we built out a fully functioning product for this, we presented what we called ‘Pre-made Parlays’ for a game. These were combinations put together by our sportsbook team that they thought would be popular with our audience. The price was already presented, and the user could add this combined selection to their betcard as a single entry. While this would not function exactly like the ideal solution, it would teach us a lot about what appealed to the customers. If they used it to an ok level then we would proceed to build the more complex solution. If they didn’t then we had learned and we had saved time and effort.
Build and test
We have decided on our MVP. It is built, tested, (improved if necessary) and launched. Then we observe.
For the same-game MVP solution, we were looking for 10% of customers to use the pre-made feature. If it was 10% or above we would proceed, assuming greater uptake in the fully functional version. If it was used by less than 10% of customers then we would decide to keep it as is or we would roll back.
Launch
When we have a reasonable level of confidence we launch the update. Customer service at this point have a clear understanding of the change and are ready to work with customers on any problems that may arise or to alert the development team if a rollback is needed. This will happen if there are critical issues or recurring smaller issues.
Review and Plan the next Improvement
Testing will involve various methods depending on what we have just launched and depending on what we are trying to learn. If we are looking to increase lifetime customer value then it’s a longer game, maybe a few months to determine frequency of user visits etc. If it’s a simple fix then we can look at the update over a shorter period – say a week, to see if any user errors have occurred. When we have learned the most valuable things about this update or about our customers using it, then we can circle back and determine what is the next most important thing to do or to learn.
For the Same-Game solution we saw a good level of interaction with our MVP solution (over 15%) giving us a green light to proceed with the next stage – offering certain bet types to be combined.
Conclusion
For every business or user problem there are different challenges. We can go down many different routes trying to solve the problem for the user but these tools will ensure that we go down a route that will give us the best outcome – an opportunity to get something useful in front of the customer, to iterate and learn.