Table of Contents
1. Discover Personas and Goals
A persona is a profile of an individual who may interact with the system uniquely or individually. To ensure that all the relevant requirements have been considered and understood, an early activity will need to be conducted to identify and discover user personas.
A user persona tends to be presented as a one-page card with information such as:
- Name (An example name to reflect that particular persona)
- Age (An indicative age reflective of people who exemplify that persona)
- Bio (A short description of this persona)
- Goals (The things that they mainly want to achieve in life)
- Needs (The things they need to achieve from the system being built)
- Pain Points / Frustrations (A list of things that annoy or slow this user down)
- Personality Types (Are they outgoing, shy, reserved, detail-oriented?)
By understanding the expectations, frustrations, and motivations of the users of the system, it becomes possible to design a product that will be more targeted toward the users’ needs and therefore be more successful.
If user personas are not written sufficiently, the danger is that the system is designed by product owners and stakeholders for themselves, based on personal biases about what they want and need, rather than on an objective view of who the target market will be. If such external viewpoints are ignored until later on in the system’s build, it can be very costly and time-consuming to add these in later.
The use of personas is a good way to ensure a complete view of requirements across all users because subject matter experts are much more likely to be able to identify missing individuals from a list of personas, rather than finding missing requirements from a long project requirements document.
2. Map the user journey
Once personas have been identified, they can each be reviewed in turn based on all of the things each person might want to achieve from the system. Once this full list of interactions with the product has been listed, they can be written down in a visual timeline known as a user journey map.
The user journey map is a visual representation of a customer’s interaction with your product from start to finish, showing how they achieve the things that they need to and what steps they need to go through to reach this destination.
The best products optimize their user journeys to ensure that objectives can be achieved by their customers in as few steps as possible. The reason for optimising the journey is that there are many competing products on the market and customers will naturally gravitate towards those that make their lives as easy as possible.
Journey maps require the following components:
- Actor. To which persona does this part of the journey map refer
- Scenario and expected results. What objective is the actor trying to achieve and what outcome do we expect
- Phases of the journey may include phases that are completed outside of the system. As an example – a user buying a wireless speaker from an e-commerce shop would first see the speaker advertised, then buy it, then take delivery, then try it, and finally may even return it.
- Actions, Mindset & Emotions
- Actions: The specific behaviors and steps taken by users
- Mindset: users’ thoughts, questions, and motivations at various stages throughout the journey
- Emotions – a line showing the highs and lows of the journey, so that these can be leveraged or improved as appropriate
- Opportunities. Armed with the above information, what do we need to do/change/improve and who owns which action? How will we measure whether a change has been made, what metrics will we use?
Once we have our identified journeys mapped out, and built on our user personas, we can then start to identify the solutions we are going to put in place to satisfy these requirements.
3. Explore solutions
When exploring solutions a good approach to use is “Design Thinking”. Design thinking advises that the best designs come from casting the net wide initially, then focusing in on defined solutions, before developing and testing a wide range of solutions, and finally, narrowing down to the winning experiments.
The above model was built on further by Plattner et al, and as can be seen below it is not a linear process with a defined beginning and end, but rather an iterative cycle of constant development and improvement. If we were starting with a brand new product, we may start at the ‘empathize’ phase, however, for pre-existing products we could start elsewhere such as ‘test’, ‘define’, or ideate.
So-called “winning experiments” then become the chosen and preferred solutions to the challenges and opportunities posed by the research in the user persona phase (also part of the “empathize” phase of the above diagram).
In this way, we can ensure that we have well-researched and tested solutions, rather than just solutions that people from the project team have proposed. These can then be translated into user stories or product backlog items for the team to turn into working software.
4. Prioritise
To prioritize is to focus on the most important things first. In software development, there are several different ways of prioritizing the work to be completed. Product owners or those focused more on the functional side of the project are likely to consider the things that generate value to be of the highest priority. However, developers and technical members of staff are likely to have a different view of priority, as they will focus more on the things that are likely to make the system robust, performant, and easy to develop.
One of the more popular development frameworks, “Scrum” advises that the product owner should order (prioritize) the backlog of work in a way that they find the most appropriate (in practice this tends to be by value), but that the development team may implement the work in the way that they choose. The development team is guided by the order of work, but not bound by it.
It is important that the development team can choose the order in which they implement the work because non-technical staff may not understand the things that need to be completed behind the scenes to make a fully functional product. Additionally, there may be a significant reduction in effort by delivering a high-priority item with a low-priority item, the so-called “whilst you’re under the hood” factor.
In true agile development, the most value is said to come from the work that is going to yield feedback the earliest. This means that there is value in even delivering a non-functioning button on a page if it allows for feedback to be received.
In practice, it depends heavily on what is being built, the culture of the organization and user group, and the appetite for experimentation as to the correct metric to use for prioritization.
5. Slice out development release/sprint
Once the personas have been identified, the journey has been mapped and the component deliverables have been ordered and prioritized suitably with feedback from across the team, it is then possible to begin identifying logical packages of functionality to release to the users, otherwise known as “release slices”.
The personas, journey map, and solutions can be translated into a set of deliverable items using user story mapping to create the lower-level tasks that the development team will turn into working software to build the product.
Release slices can also be utilized as the product goal in Scrum teams, with the individual sprint goals all working towards that release. This allows teams to begin to forecast forthcoming sprints, using a high-level sprint goal per sprint, until everything is completed to allow the release slice to be made available to end-users. It should of course be noted that such forecasts are not a binding plan, and should not be represented to stakeholders as such.
Whilst development teams working to best practice aim for continuous integration, delivery, and deployment to production as a way of ensuring good code quality, it may not always be suitable to make the latest functionality available to users immediately. This is because when building a new phase of a user journey it often does not make sense to release the functionality until the full phase of the journey has been completed.
Development teams can balance the need for continuous deployment as a good coding practice, with the requirement to only release chunks of functionality, by using feature flags. Feature flags allow code to be released to the production environment and tested but not visible to end users until the feature flag is enabled. When the flag is enabled this requires no release or coding, merely a flag to be toggled and then the functionality becomes available, which is how many “releases” are completed.
