The Solution
DESIGN THE SOLUTION
Having aligned on the overall goals and identified expectations, requirements and constraints, we can now head into defining the solution. Depending on the type of initiative, it may be conceptual or quite concrete. It may be defined in terms of concrete features and functions, actions for change, or defined as ‘experiments’ to explore and validate. Ultimately, we’re seeking to define the concrete things we need to do to achieve the given goals in the most reliable way.
Dependent on initiative, the different types of areas, business architecture, product and user experience, technology and infrastructure will differ in focus.
If time allows, user research and other prototyping / technical exploratory activities could be built in to de-risk and validate thinking at this early stage.
At the end of this phase, you will want to know what the solution would look like to users, but also what’s ‘under the hood’.
Why
In this phase we define the most appropriate solution option, taking into account desirability, feasibility and viability.
We lay the groundwork for the feature roadmap, delivery plan and subsequent delivery.
What good looks like
We want to devise a solution with sufficient detail so that we can demonstrate and assess its value (desirability) and feasibility, and conduct subsequent planning for implementation and viability assessment. This will often mean staying with Epics and indicative user experience or service design for the time being.
Activities
FEATURES
What features will the solution have?
We specify the overall shape of the solution (usually top-level features and functions) in light of the target user experience. At this early stage we keep this at Epic level, using mockups rather than detailed designs.
Recommended tools and techniques
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to structure epics, stories or features so that I can easily delivery an end to end solution
Story Maps are our default tool to elicit and visualise requirements at both an overview and detailed level. They are user-centric, goals-focused, end-to-end, and provide a means to align requirements with the business roadmap, objectives and scope.
They also help us slice and prioritise a large solution into manageable parts (see below).
I want to visualise what the solution will look like and how it will function
Screen mockups or wireframes (at various levels of fidelity) are great tools to illustrate a solution, be this to stimulate ideas, elicit or validate requirements or communicate a solution approach. Wireframes also allow us to get more accurate estimates, as they illustrate complexity. Keep in mind that at this stage we are only aiming to bring things to life, rather than providing a development-ready ‘specification’.
I want to analyse and define processes in more detail.
User Journeys are a detailed illustration of how users interact within a touchpoint, usually from screen to screen. Activity Diagrams are a formal expression of logical flow, usually used to illustrate user interaction or system activities. BPMN is a formalised visual modelling language to document business processes. Value Stream Mapping is a technique that helps to improve processes, following lean paradigms.
I want to understand my target audience, what they desire and how I can ultimately provide value to them
We have a wide range of research tools and techniques at our disposal to understand users and situations, validate assumptions and hypotheses prior to and during design, delivery and actual operation. Research is vital and informative, as long as we’re mindful of its constraints: early user research, especially focus groups and user testing with small sample sizes are indicative at best. Monitoring (e.g. web analytics) and testing (A/B testing) in live use are more reliable, but less exploratory.
I want to understand how my target audience (expects to) interact with the business and its products
User experience maps illustrate users’ interactions across the various touch points they may have with an organisation, and what capabilities are required to support the interaction. We can also map user sentiment and empathy against each touchpoint, which then allows us to link back to our value proposition.
Finally, we can use an experience map to indicate threats and opportunities, areas of risk and improvement on this map.
We use these to map the as-is or to-be state, and communicate areas of recommended focus to a business.
I want to understand how a business delivers services or what will be required to deliver a service
Similar to a user experience map, the service blueprint focuses on the internal workings of an organisation. The information inherent in a user experience map and blueprint can be combined into a single diagram in many cases.
We can use the service blueprint to model the as-is and/or the to-be state.
TOP LEVEL END-TO-END DESIGN
What the solution will look like and how it will be realised
We identify solution options and specify and ‘design’ the solution at top level, from user, business and technical perspectives (covering experience, service design, architecture and infrastructure).
At this stage we may refine wireframes, create visual designs, draft architecture, agree on the tech stack, define the infrastructure and the path to production, as well as define operational and support capabilities. It’s very important that we provide a design that works across the entire business and for all stakeholders.
‘Working for all stakeholders’ doesn’t mean there won’t be any changes on the part of stakeholders or their teams: but rather that we will work together to codesign the changes needed to work for the business as a whole.
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to structure epics, stories or features so that I can easily delivery end to end solution in line with business objectives
Story Maps are our default tool to elicit and visualise requirements at both an overview and detailed level. They are user-centric, focused end-to-end, and provide a means to align requirements with the business roadmap, objectives and scope.
They also help us slice and prioritise a large solution into manageable parts.
I want to visualise what the solution will look like and how it will function
Screen mockups or wireframes (at various levels of fidelity) are great tools to illustrate a solution, be this to stimulate ideas, elicit or validate requirements or communicate a solution approach. Wireframes also allow us to get more accurate estimates, as they illustrate complexity. Keep in mind that at this stage we are only aiming to bring things to life, rather than providing a development-ready ‘specification’.
I want to analyse and define processes in more detail.
User Journeys are a detailed illustration of how users interact within a touchpoint, usually from screen to screen. Activity Diagrams are a formal expression of logical flow, usually used to illustrate user interaction or system activities. BPMN is a formalised visual modelling language to document business processes. Value Stream Mapping is a technique that helps to improve processes, following lean paradigms.
I want to understand my target audience, what they desire and how I can ultimately provide value to them
We have a wide range of research tools and techniques at our disposal to understand users and situations, validate assumptions and hypotheses prior to and during design, delivery and actual operation. Research is vital and informative, as long as we’re mindful of its constraints: early user research, especially focus groups and user testing with small sample sizes are indicative at best. Monitoring (e.g. web analytics) and testing (A/B testing) in live use are more reliable, but less exploratory.
I want to explore the solution. Will this work?
Time allowing, we may decide to explore certain concepts or aspects by building more or less detailed / production-ready ‘things’. As a part of an inception, this is mostly for the purposes of de-risking and/or validation from a user experience or technical perspective. In some cases, the things we build will be thrown away; in others this will be a valid starting point for the productionised product.
Technology stack
I want to define the technologies we will be using
We explore and agree on technology stack quite early in the process. A good stack is based on solid criteria, so that during development a decision framework can be used to inform the best technology choices. A good stack recognises business needs, capabilities and solution-fit, and provides a balance of flexibility and consistency. A tech radar can be an effective way to represent this.
Architecture outline
I want to model how the various technical components of a system are related to each other.
We use lightweight, low-formality architecture diagrams to analyse, align on and communicate information about the technical domain.
Ultimately this allows us to explore and agree:
Architectural approach
Architectural patterns
Technology choices
It also feeds into team profile and shape, and informs scope, feature and solution design related decisions.
It’s important that we consider this in close conjunction with all other aspects of solution design (UX etc).
Infrastructure outline
I want to understand and define the infrastructure that will support my solution
An exploration and early agreement on top level infrastructure and related tooling. This will cover classic infrastructure concerns such as hosting, but must also address the path to production and related tooling (see below).
Path to production outline
I want to define how code is developed, deployed and released into production
We explore and agree on how code gets developed, tested, deployed and released in a controlled and repeatable manner. It’s important that we consider all relevant stakeholders, from the development team to system administration, operations and regulatory compliance, etc.
I want to analyse and define processes in more detail.
User Journeys are a detailed illustration of how users interact within a touchpoint, usually from screen to screen. Activity Diagrams are a formal expression of logical flow, usually used to illustrate user interaction or system activities. BPMN is a formalised visual modelling language to document business processes. Value Stream Mapping is a technique that helps to improve processes, following lean paradigms.
I want to make decisions in the most objective and consistent way
Decision-Making Frameworks are a way to formalise the criteria by which decisions are made, and ensure these are made with strategic goals and outcomes in mind.
We use them for all aspects of decisions, whether they relate to investment, feature design, prioritisation or technology choices.
Do note that such models do not take into account the nuanced contextual factors that are sometimes at play. We need to be careful not to make bad choices by applying inappropriate models.
I want to document the non-functional qualities and characteristics of the solution.
Contrary to functional requirements, non-functionals are often well understood and documented. The challenge is to tease out and agree on the specifics, (e.g. number of concurrent users, expected throughput, etc). Where no benchmark exists, in our experience it’s best to put a gut-feel based stake in the ground, and plan for evolutionary architecture and infrastructure to scale and evolve in the future where required, rather than build for scale from day one.
Technical requirements catalogue
I want to document implementation / technology specific requirements of the solution
Technical requirements are often based on existing capabilities, business constraints or preferences. Ultimately these should be workshopped in light of context, industry best practices and requirements. A good way to illustrate the overall scope is to visualise requirements in a tree structure, with themes at the top, and features, epics and stories coming further down the tree in increasing detail. This provides an easy-to-consume overview that allows us to track delivery progress.
I want to understand how my target audience (expects to) interact with the business and its products
User experience maps illustrate users’ interactions across the various touch points they may have with an organisation, and what capabilities are required to support the interaction. We can also map user sentiment and empathy against each touchpoint, which then allows us to link back to our value proposition.
Finally, we can use an experience map to indicate threats and opportunities, areas of risk and improvement on this map.
We use these to map the as-is or to-be state, and communicate areas of recommended focus to a business.
I want to understand how a business delivers services or what will be required to deliver a service
Similar to a user experience map, the service blueprint focuses on the internal workings of an organisation. The information inherent in a user experience map and blueprint can be combined into a single diagram in many cases.
We can use the service blueprint to model the as-is and/or the to-be state.
SOLUTION OPTION(S)
Which solution option will we go with?
Based on desirability (value), feasibility (context) and viability (constraints and business goals) we choose the most appropriate solution option.
Either the solution was defined before the inception, or defining the solution is a goal of the inception. In the former case we will want to validate the solution (and flush it out in more detail). For the latter, we need to determine the most appropriate solution design and how to deliver this. Note that a final decision may not be possible until much later, when we have an idea of not only value but also cost.
Factors impacting this decision include device (desktop vs mobile), hosting (AWS vs Azure) or delivery choices (build, lease, buy).
The choice is to be made in context of objectives, business capabilities, constraints and total cost of ownership.
Recommended tools and techniques
Build, lease or buy?
The Wardley Map is a strategic decision-making tool that identifies business capabilities as part of the overall value chain, and maps them against industry maturity. Generally speaking we want to build what is our competitive advantage; own (or possibly lease) what is mission critical; and outsource what is a commodity. Of course there may be other factors that may influence our approach (likely financial or political).
Which option fits best?
By defining a number of criteria or dimensions, weighting them and then ranking each option, we can compare options with each other and choose ‘best fit’.
Which option fits best?
By defining a number of criteria, possibly defining an ideal ‘target’ shape, and then scoring every option against these characteristics, we can use radar charts to help us find a best fit.
I want to make decisions in the most objective and consistent way
Decision-Making Frameworks are a way to formalise the criteria by which decisions are made, and ensure these are made with strategic goals and outcomes in mind.
We use them for all aspects of decisions, whether they relate to investment, feature design, prioritisation or technology choices.
Do note that such models do not take into account the nuanced contextual factors that are sometimes at play. We need to be careful not to make bad choices by applying inappropriate models.
Is this a good option?
Total Cost of Ownership looks at overall cost of a product or service from design through to implementation, use and decommissioning. It’s a valuable tool, not only for number crunching but also to identify the more subtle areas of cost and effort around elements in an organisational supply chain.
I want to understand how my target audience (expects to) interact with the business and its products
User experience maps illustrate users’ interactions across the various touch points they may have with an organisation, and what capabilities are required to support the interaction. We can also map user sentiment and empathy against each touchpoint, which then allows us to link back to our value proposition.
Finally, we can use an experience map to indicate threats and opportunities, areas of risk and improvement on this map.
We use these to map the as-is or to-be state, and communicate areas of recommended focus to a business.
I want to understand how a business delivers services or what will be required to deliver a service
Similar to a user experience map, the service blueprint focuses on the internal workings of an organisation. The information inherent in a user experience map and blueprint can be combined into a single diagram in many cases.
We can use the service blueprint to model the as-is and/or the to-be state.
SOLUTION SLICES AND FEATURE PRIORITISATION
What will we do first?
Based on business goals, milestones, roadmap and dependencies, we identify ‘release’ goals, and which features and capabilities are in each release.
Dependent on the type of initiative, we may have to break down an existing system into manageable parts, divide target scope in a meaningful way, or simply prioritise desirable features.
When doing so we need to recognise value, cost, constraints, ‘fit’ and risks. We may find that the subsequent estimation exercise will require us to revisit and refine our earlier prioritisation.
Recommended tools and technique
I want to articulate what am I doing and why, and know when I have been successful
Whether we design and build a totally new product and have to validate whether there is a market at all, deliver a sound value proposition but need to be sure it was done in the right way, or simply want to explore potential opportunities, we are always – often subconsciously – working to a hypothesis. Articulating and formalising this in terms of expected outcomes streamlines our subsequent design and planning and makes sure we’re always focusing on delivering value against strategic goals. Note that a hypothesis or related experiment can be in regards to the solution itself (value, usability) but also to delivery (to validate technical feasibility or an approach or process).
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to structure epics, stories or features so that I can easily delivery an end to end solution
Story Maps are our default tool to elicit and visualise requirements at both an overview and detailed level. They are user-centric, goals-focused, end-to-end, and provide a means to align requirements with the business roadmap, objectives and scope.
They also help us slice and prioritise a large solution into manageable parts.
Is this a good option?
Total Cost of Ownership looks at overall cost of a product or service from design through to implementation, use and decommissioning. It’s a valuable tool, not only for number crunching but also to identify the more subtle areas of cost and effort around elements in an organisational supply chain.
I need to break a big, complex ‘thing’ into manageable parts.
We apply solution slicing as a technique to slice an existing solution into parts, so that they can be decoupled and treated (analysed and or delivered) individually.
MVP / First iteration scope
What is the bare minimum I can get away with?
At this stage, we not only want to identify what we are doing (and the priority of items) in isolation, but also in the context of a related group of features that we can deliver as a release. This can focus on the very first release (also see Steel Thread below) and/or a larger, first market-ready release (MVP, together with future slices at less granularity). All of this can result nicely from Storymaps.
Which option fits best?
By defining a number of criteria, possibly defining an ideal ‘target’ shape, and then scoring every option against these characteristics, we can use radar charts to help us find a best fit.
I want to prioritise items so that I know that to focus on.
We use a range of prioritisation techniques, dependent on context, but generally find that simpler methods work at least as well as complex methods. Humans are good at comparison, but not great at absolute values. A range of biases also play into supposedly more “scientific” decision methods. As such, we advocate for being pragmatic: be data-informed, acknowledging your instinct and biases in parallel.
Pro tips
Keep solution design light. You are still not building the thing just yet. Use these activities to explore, clarify, illustrate and build trust.
Consider setting up decision-making framework(s) to help make decisions on matters related to scope and technology choices.
Avoid committing, keep options open: work towards a culture of making agreements based on what is known now, with the option to change at a later stage as further insights come to light or conditions change.
While collaboration and joint application design is the ideal, we may also consider diverging into specialist sub-groups before converging and aligning the whole team afterwards. This can allow us to focus efforts, keep cognitive effort to a minimum and run activities in parallel.
Continue to include users and a wide range of stakeholders in these activities. Ensure a balanced multi-disciplinary group. This prevents the business from estimating on behalf of technology, or technology prescribing features.
Last updated