Stage 2: Devise Solution to Determine Feasibility
This stage is all about generating ideas on HOW to solve the problem that has been identified in the first stage, rapidly prototyping to validate the solution direction and determining the feasibility of the solution in the user’s context.
Too often we commit the mistake of sticking to the idea that originally came to our minds when we first thought of the problem space. In fact, we don’t just think about the problem; most of the ideas are for a specific solution without regard to whether the solution is feasible in the context of the user. What ends up happening is that we polish our idea to a point where it takes the shape of a shiny object ready to be used by the user. However, when the user is first shown the solution, the reality hits us that for reasons unbeknownst to us, the user does not find the solution useful and is not enthused by it. The solution ends up being a shiny ornamental object on the shelf of our metaphoric living space.
To avoid falling into this trap, a methodical and iterative approach needs to be adopted which starts small, gets the user’s feedback on all aspects and adapts to the user’s needs. The number of iterations could be in the hundreds.
Before you continue the iterations, it is very important to ensure that you are not boxing your solution direction into a narrow direction. It may be helpful to think of your first idea, which you think is game-changing or world-altering or earth-shattering, as a narrow alley in a small town. What you need to do is to step back and stand up on the edge of a hill to have a full view of the landscape of ideas across the entire landscape of ideas. And then you can combine the various ideas into a solution concept that might be worth pursuing. To do just that, have the team do the following before generating ideas:
■ Review the design challenge/problem statement. This is about the target the user is looking to hit. (What is the job the user needs to finish? What is the goal the user is looking to accomplish? What is the vision the user is aspiring to realize?) See the value proposition section in stage 3 (5.2) for details.
■ Persona
■ Current journey
■ User’s perspectives (Figure 4.1).
Figure 4.1 Ideas.
Here is an example from a real-life ideation session (Figure 4.2).
Figure 4.2 Ideas example.
Create a large wall area to collect all ideas and review the following basic brainstorming rules:
1. Quantity over quality. During ideation, one must never think of how sophisticated or valuable the ideas are. The goal of ideation is to generate as many ideas as possible. Quantity matters more than the quality of the ideas during brainstorming.
2. Defer judgment. As mentioned earlier, we tend to judge not just others but our own ideas. We must not be judging any ideas during brainstorming.
3. Urge wild ideas. Another important aspect of brainstorming is that we must not just be content with commonplace ideas which comply with the norms of society, culture or technology. Instead, we must explore ideas which are outside the norms and may even seem somewhat wacky and nonconformist. Discussions with someone of a totally different context than your own would be helpful in bringing forth such ideas. For example, if your team comprises professionals from engineering, sciences or business, talk to people in arts, music, entertainment or sports. You’ll be surprised to see how differently these folks think and how unique a perspective they bring to solving your problem.
4. Focus on the problem. It’s good to think really in different domains, but to ensure you are not distracted, it is important to stick to the problem you are focused on solving.
5. Build on others’ ideas. Finally, do not just confine yourself to your own ideas. As you review the ideas from other team members, feel free to build on those ideas and connect different ideas together to come up with novel solution concepts. Remember that Apple neither invented the Graphical User Interface nor the mouse, which are so commonplace now. They built on the idea of the graphical user interface and the mouse from Xerox.
Once the team is briefed on these rules, start the following self-brainstorming sessions.
5-minute Self-brainstorm:
Each member of the team would already have many ideas to solve the problem for the user. Ask everyone to write all the ideas on sticky notes and place them on the whiteboard.
Ask them to have a quick look at other ideas and then be ready for the next round of ideation.
3-minute Self-brainstorm:
Give the following prompts to instill ideas from the team members. Have at least one round of three-minute self-brainstorming on these prompts.
Prompts around Value proposition.
■ How might the user hit the target in a better way?
■ How might the user hit the target in a faster way?
■ How might the user hit the target in a cheaper way?
■ How might the user hit the target in an easier way?
These prompts are likely to generate some usual and commonplace ideas. The following prompts will help you generate out-of-the-box and unusual ideas.
External Prompts.
■ Think of your favorite brand; how would that brand solve this problem? For example, how would Apple or Google or Amazon solve this problem?
■ Think of another industry; how would that industry leader solve this problem? For example, if your problem is in the consumer products space, prompt the team to think about the hotel industry, the airline industry, the banking industry or another industry.
■ Think of your biggest competitor, how would they solve it?
Prompts around Constraints.
Constraints are a great way to push you to think of novel ideas. Using constraints helps in generating unique ideas that no one could have deemed possible before. Introduce some constraints to see how the ideas evolve. Some examples of constraints are as follows:
■ What if we only had a quarter of the funds that we currently have – how would we solve the problem?
■ What if one of the team members left due to a family emergency – how would we solve the problem?
■ What if we didn’t have access to X – how would we solve the problem? (X could be any important asset or capability you are relying upon).
■ You may also think about the assumptions you have made. Focusing on the critical and major assumptions, consider how you would solve the problem if those assumptions were proven wrong. Review the assumptions section in stage 4 (6.1).
Contrarian Prompts.
Most of the novel business models are a result of teams thinking totally opposite to the conventional wisdom. For example, the conventional wisdom dictates that one should never let strangers come into one’s house, let alone spend the night inside. However, AirBNB challenges that exact assumption and built a business exploiting the contrarian approach of generating value from renting a portion of a house to strangers. Another famous example is around hitchhiking. The common cultural narrative is filled with horrific stories, including torture, kidnap and murder when someone hitchhiked with strangers. Parents continue to remind their young and older children to refrain from riding with strangers and avoid taking rides from strangers. However, Uber and Lyft pioneered the highly successful ride-sharing business model and exploited the completely contrarian view of the conventional wisdom.
■ Push your team to think about all the conventional wisdom related to your problem space that you are operating under. And now imagine you flipped the conventional wisdom upside down; how would you now solve the problem?
Team Brainstorm
Now that you have all the ideas on the whiteboard, have the team review them. You’ll see that several themes are emerging in these ideas.
Cluster the ideas according to these themes. You’ll be surprised to see the diversity of the ideas and themes. You can consider these themes as a collection of related ideas. Review the ideas individually and in your team. Discuss the merits and demerits of each idea and each theme.
After the session, the session lead should ask the team to write down all the assumptions made and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.
Creativity Requires Time:
Creativity isn’t something that you can force in one brainstorming session. One needs to let the ideas percolate into the subconscious in order to have deeper insights as well as “Aha!” moments. It is important that you don’t just consider this one session as the final session. This session should be repeated several times. A good rule of thumb is to have the session repeated every week for a couple of weeks. During these subsequent sessions, the quality of ideas improves, and you also have a chance to think about the existing ideas in further depth as well. In addition, do discuss promising ideas with the users whenever you get a chance, so that you can gain further insights and input on the suitability of the ideas in the users’ context.
Once you have generated these ideas, it is time to start prioritizing the ideas so that you can filter the ones you could quickly prototype and test with the users. Prioritization could be done in many ways.
■ Dot Voting. Give 3-5 voting dots to each member and ask them to place them on the top idea clusters/ideas. As teams place their votes, you’ll see an emerging theme on the top ideas or idea clusters.
■ 2 × 2 Matrix. One quick way of prioritization is a 2 × 2 matrix with value (to user) on the vertical axis and feasibility on the horizontal axis.
■ Evaluation Criteria. A more complex and sophisticated way is to identify evaluation criteria, which means identifying some variables which are important for the solution. These may include usability, desirability, technical feasibility, duration, simplicity, business value. Each of the selected variables are assigned weights and the weighted average is calculated to rank ideas.
To have agility in execution, we’ll use the 2 × 2 matrix method of prioritization.
Figure 4.3a,b shows how the ideas may look like on the wall as you prioritize using a 2 × 2 matrix.
Figure 4.3 (a) Idea prioritization.
Figure 4.3 (b) Idea prioritization.
Figure 4.3c is a snapshot from a real-life session I conducted that showcased idea clusters prioritized on a 2 × 2 matrix.
Figure 4.3 (c) Idea prioritization example.
Session Lead
Name each of the idea clusters to easily identify the ideas.
Write the idea-cluster names and selected top ideas on sticky notes.
Take each idea-name sticky note and bring it to the 2 × 2 matrix. Moving the sticky note in a vertical direction, ask the team to evaluate the value of this idea. The ideas which have the most superior value will be placed at the very top and those ideas which do not have any value will be at the very bottom. All the other ideas will lie somewhere in the middle.
Once the idea has been evaluated on the value axis, staying at the same level, move the idea from left to right on the feasibility scale and ask the team about their view of how feasible the idea is to implement. As you think about feasibility, consider all aspects of feasibility, namely, technical capability, access to expert knowledge, expected duration to implement and any other aspect that influences feasibility.
Based on team consensus, place the idea on the prioritization board.
Repeat the process with all the idea clusters and selected ideas.
Most Valued Ideas
As highlighted in Figure 4.3b, the ideas on the top quarter of the prioritization matrix are the most valued ideas from the perspective of the user based on your understanding. From the user’s perspective, realizing these ideas to create a solution would be a tremendous value to the user. However, not all ideas which add value to the users are feasible to implement or viable from a business perspective though.
Most Practical Ideas
The ideas which are both desirable by the user as well as feasible are the ones in the top right corner of the prioritization matrix, as highlighted in Figure 4.3b.
The team should focus on these ideas to move forward.
Note that value to user is based on your understanding, which may or may not be viewed in the same manner by the user. So, it will be important to validate your understanding with the user.
After the session, the session lead should ask the team to write down all the assumptions that you are making and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.
4.3 Step 8: End-to-end Experience Vision
A storyboard is used to convey the future vision of how the user will experience the solution. For each of the boxes below, draw a scene and then write an explanation just below the box, like a comic strip. A best practice in creating a storyboard is to convey the story as follows:
1. Introduce the persona with:
a. pain points
b. goals
c. motivations
2. Convey the user context, including:
a. triggers in the environment to cause this experience
b. tools used by the user
3. Show user’s experience as they use your new solution.
4. Depict emotions where you see necessary.
5. End with a successful completion of the job.
Show your storyboard to your users/customers and get feedback. Identify opportunities for realizing the solutions using technology in the storyboard.
Don’t get hung up on the quality of your drawing. Just using simple stick figures with text in callouts and smileys should be sufficient. The main idea is to show the future journey of the user and get feedback.
For each scene of the experience vision, think about the systems, tools and stakeholders the target user will rely upon. Pay close attention to all the elements that you are expecting the target user to rely upon in the future experience and ask yourself whether this new experience is plausible in the target user’s context?
Session Lead
Figure 4.4 (a) End-to-end experience vision template.
Figure 4.4 (b) End-to-end experience vision example.
Collecting the most practical ideas from the prioritization matrix, your goal will be to stitch these ideas together to craft a future experience vision.
Open Collaboration
Once the team understands the various most practical ideas, the team should discuss how these ideas could be brought to bear to create a future that would help solve the user’s problem in a manner that would delight the user. You should perform this step with a mind-set which keeps the user as the key protagonist trying to overcome obstacles while performing a job, achieving a goal and realizes the vision. You should be next to a whiteboard with markers to jot down your thoughts and concepts for clarity of understanding and tangibility of concepts. You may leverage the following ways of capturing the essence of the future experience vision:
■ Freehand drawing
■ Use case modeling
■ Flow charting
■ Describing in words
■ Mind mapping
■ Using block diagram
This is a collaborative team exercise. Following the sequence of the storyboard of the future end-to-end experience vision as depicted in Figure 4.3, describe each scene on a sticky note and place on the wall. Continue from the beginning to the various scenes in the middle and conclude with the successful completion of the job.
Don’t worry about the quality of the experience vision in the first few iterations. This will require multiple iterations before you are comfortable with the experience vision. As you review and improve the experience vision several times, you’ll see remarkable improvements in each iteration. You’ll also get an idea whether the experience vision that you are creating makes sense in general and for the user, in particular. Once you and your team are comfortable with the experience vision, use the template and craft the storyboard. Each scene of the storyboard includes an image or diagram depicting the scene as well as a description of the scene in words. Again, do not worry about the quality of the image; just use stick figures and callouts to convey the happenings in the scene.
Once you have the future experience vision storyboard completed, stand back and review it and see if it makes sense. Expect to adjust it as many times as you deem necessary. You may be moving the scenes back and forth, adding or deleting scenes, updating beginning and ending several times before you have a version that you are comfortable with.
Point to Note
Up to this point you have not invested any time and resources in building the actual solution. You have used no technology, no software, no hardware or any other devices. What you have been able to do so far is write down the future vision in the form of a story that conveys the essence of the solution. Doing that also helped you place yourself into your user’s shoes to see whether the future experience vision would help solve the user’s problem in a manner that is desirable and usable. It is important to highlight that this approach helps you have a view into the future without too much investment. In the next step, we’ll explore other forms of prototyping to help you move toward your vision in an agile manner.
After the session, the session lead should ask the team to write down all the assumptions made and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.
4.4 Steps 9 and 10: Prototype and Test
I have already used the word prototype several times in this book. In this step I’ll describe in more detail the essence of prototyping, why it is not just important, but critical, and how to go about prototyping your ideas and solutions.
So what is a prototype?
Prototyping is a first preliminary model of a new concept made to test other people’s reactions, and to help gain insights into what your idea means to your users. Prototype makes things tangible to improve understanding of the applicability in user’s context and identify areas to improve upon. Creating a prototype is a quick way to show how something looks, feels or works. A prototype helps in developing and iterating ideas and can assist you in finding hidden issues with the concept. A prototype also creates a common understanding among stakeholders and aids in redefining the problem.
As the saying goes, “The best way to experience an experience is to experience it...”
In the most simplistic terms, a prototype is a way to convey a new concept and get feedback in solving a problem.
There are three aspects to a prototype.
1. A problem that is being solved
2. A concept to solve the problem
3. A way to get feedback
In the previous step, we created an experience-vision storyboard. This was an example of a prototype as well. As you created the storyboard, you highlighted the problem being solved, an approach to solve the problem to get feedback. This will help you have a better understanding of the aspects of the storyboard that makes sense for the user.
A prototype is not confined to specific forms, some of which are mentioned below.
1. Physical. If you create a model using cardboard boxes, paper, tape, plastic and other material, it is a physical prototype. You may also use newer mechanisms such as 3D printing to create physical prototypes. For example, to see how a new concept of a reception welcome desk might look and feel in a bank, you may use cardboard boxes to craft the new desk style and place it in the bank to get feedback.
2. Handwritten on paper. You may simply use various-sized papers and draw your concepts to create a prototype. In software applications, most often the first version of the prototype is the depiction of the screen using a pen on a piece of paper. These are called wireframes. For creating a prototype of a new mobile app, you may use 3x5-inch rectangular sticky notes and sketch how the screen might look and how the flow of the screens would be as the user interacts with the mobile app. You may place these sticky notes on a foam board and draw arrows to convey user interactions as well.
3. Slide show. You may use a slide-show software such as Microsoft PowerPoint or Apple Keynote and use the native features (such as shapes and lines). Use text and animations to convey your concept and get feedback.
4. Storyboards. As we saw in the previous step, storyboards are one of the most powerful ways to prototype. Humans are hard-wired for stories. Stories evoke emotions and leave a lasting impression. All cultures have sustained their traditions over the course of millennia through the use of stories which have transcended generations. That’s the main reason why storyboarding an experience-vision concept is one of the most effective ways of prototyping. One of the best storyboarding tools is called Scenes™ by SAP Design AppHaus, which is available at https://experience.sap.com/designservices/scenes.
5. Role-playing or acting. Most people don’t realize that prototypes do not have to be tangible. Depending on the situation, role-playing or acting could be an effective mechanism for prototyping. One of the most pertinent types of solutions where role-playing has a natural fit is experience design or interaction design. You may also record a video of the role-playing session using a simple smart phone camera to review it later on or show to users to get feedback.
6. Technical Prototypes. These days, most of the solutions involve technology, which is primarily software applications either on desktop computers or mobile devices. If your team has the technical skills, you can also create simple versions of software programs to validate your concepts. These software-based prototypes need not have all envisioned functionality or actual data. They can have a simple front-end user interface with non-functional logic. They may only use some dummy data to convey how the concept would work and get feedback. There are many online tools available to help you in prototyping your software concepts. Some of the most popular ones include Sketch, iRise, Axure, InVision and Flinto (Figure 4.5).
Figure 4.5 Prototype examples.
Figure 4.5 Prototype examples (continued).
Figure 4.5 Prototype examples (continued).
Whatever type of prototyping you adopt, it is extremely important to show the prototype to the user and obtain feedback in a structured manner. Before we talk about how to gather the user feedback, there are some critical guidelines for obtaining user feedback.
It is best if you could run the user feedback session in pairs. One team member should drive the feedback session as the session lead, and the other should act as a note taker. This is important because you need to have the feedback session run in a smooth manner without the possibility of key insights being forgotten after the session.
4.4.3 Do’s and Don’ts for Session Lead
Follow the guidelines for user research highlighted in the user research step in stage 1 (3.2 Research). In addition, here are some do’s and don’ts about the user feedback session.
■ Do plan ahead to meet with the user at a time that is convenient for the user and when the user is least distracted due to work or personal commitments.
■ Do inform the user about the purpose and duration of the session and highlight why it is important for the user to provide open and honest feedback. The way you position the session has a direct impact on the quality of the feedback. Reiterate that the reason for the session is to devise a solution to solve a particular problem for the user. Mention that this is an initial concept that you want to show to the user and obtain his/her open and candid feedback. Also convey that the input from the user will be used for improving upon the prototype. The duration of the session is dependent on the type and complexity of the solution as well as the available time with the user. Generally, one user feedback session lasts anywhere from 30 minutes to 90 minutes.
■ Do turn all your phones off and encourage the user to also avoid any potential distractions for the duration of the session.
■ Do make the user at ease at the beginning of the session and highlight that it is not a test of their abilities but a test to see the intuitiveness of the user experience, the relevance to the topic and the functional correctness.
■ Do explain the scenario in which the user is likely to be using the prototyped solution. However, do confirm whether they agree to the scenario in which they will be using the solution. Do ask if there are any other contexts in which the user will be using the solution.
■ Do ask the user to state their thoughts, feelings, needs and challenges during the session.
■ Do keep your words to a bare minimum during the session. You are interested in getting the user’s feedback.
■ Do observe intently where the user is facing difficulties or is pleased.
■ Do write down the user’s challenges.
■ Do write down the user’s moments of delight.
■ Do clarify any questions that the user asks; try to answer only in the form of open-ended questions.
■ Do note down all the questions the user asks. Questions from the user is an indicator of lack of clarity of the prototype.
■ Do act as a facilitator only; nothing more.
■ Do ask for suggestions for improvement at the end of the session. It is likely that the user will be giving you feedback and suggestions for improvement throughout the session, but it is important to give the user another opportunity to provide any further suggestions to improve the prototyped solution. You may go back to some of the issues highlighted during the session and ask the user for any suggestions for improvement. You have to be mindful of the tone in which you ask for ideas. Your tone must not convey any kind of sarcasm or insult.
■ Do ask if there will be other users who could give valuable feedback at the end of the session.
■ Don’t help the user in any way. We have a tendency to be emotionally attached to the amazing experience vision that we have prototyped. However, when the user actually reviews it, he/she inevitably finds some aspects challenging, out of place or totally unusable. At this point, we are naturally inclined to help the user get over the obstacle. This urge must be controlled. The purpose of the session is to intently observe the user as he/she is having these challenges so that you could improve upon the prototype, not to convince the user of its remarkableness.
■ Don’t lead the user in any way. Similar to the above point, do not lead the user in any way. We are naturally inclined toward helping others. However, this is not the time to help the user, even when the intensity of this urge increases. Observe intently and let the user figure the prototype out.
■ Don’t give any tips.
■ Don’t give your preference. Remember that it is not about you or your prototype; it is about the user, his/her problem and getting feedback on the prototype for the solution that you have created. So refrain from sharing any preferences.
■ Don’t judge or belittle the user. This is a grave sin which a lot of first-timers commit. If you do this, you’ll lose any opportunity to gain any valuable feedback from the user in this session or in the future. In fact, doing this will likely help you lose this user forever. It is likely that the user will stumble on several steps while going through the process and using the prototype. Remember, it is not the user’s fault or stupidity. It is the prototype that is not meeting the user’s needs.
■ Don’t give explanations. When your beloved prototype is being evaluated, you are likely to fall into the mind-set of defensiveness. We have to admit that we don’t like it when anyone calls our baby ugly. We fall into the habit of justifying the shortcomings of our prototype. This must be avoided at all costs. In fact, you must continue to thank the user for their valuable feedback.
■ Don’t interrupt. Do not think of this session as a regular conversation, even if the user is an acquaintance. So interrupting the user is never a good idea. However, there is an exception, which is when the user goes away from the task at hand and goes off on a tangent. If that should happen, politely remind the user of the purpose of the session and encourage him/her to continue working with the prototype and giving feedback.
■ Don’t laugh at the user. This is absolutely forbidden. It is in the same category as belittling and insulting the user. Remember that the user is doing you a favor by spending his/her valuable time helping you by reviewing and giving feedback to you on your prototype.
■ Don’t ask any questions during the session. Although some clarification questions are okay, you should refrain from asking questions during the session. If you feel the urge to ask a question, note the topic and ask that question at the end of the session.
■ Don’t offer approval or disapproval with words, facial expressions or body language. Remember that you are not judging the user at all. Your main goal is to observe the user and get the feedback on the prototype. Staying neutral is very important throughout the session for gaining effective feedback.
4.4.4 Do’s and Don’ts for Note Taker
As a note taker, your primary purpose is to write down all the observations and feedback from the user. These include the user’s thoughts, feelings, body language, quotes, needs, challenges, moments of delight, moments of difficulty and ideas. Here are some guidelines for the note taker.
■ Do keep quiet during the session. You’ll feel the urge to speak, suggest or ask questions during the session. Remind yourself of your role during the session and continue writing down the feedback and observations.
■ Do record the session, with user’s permission. You could do a video recording or an audio recording. These recordings can provide valuable feedback later on. If doing a video recording, bring a tripod stand for your video recorder or smart phone.
■ Do observe intently where the user is facing difficulties.
■ Do write down user challenges. Challenges may include the user getting confused on how to use the solution, the user finding it difficult to use the prototype or the user becoming uninterested.
■ Do write down the user’s moments of delight.
■ Do remind the session lead about his/her role if the lead does not adhere to the guidelines.
■ Do write down any further feedback, needs or comments that the user shares.
■ Do ask any key questions that were not answered during the session and were not asked by the session lead toward the end of the session.
■ Don’t help the user in any way.
■ Don’t lead the user in any way.
■ Don’t give any tips.
■ Don’t give your preferences.
■ Don’t judge or belittle the user.
■ Don’t give explanations.
■ Don’t interrupt the user.
■ Don’t laugh at the user.
■ Don’t ask any questions during the session.
■ Don’t offer approval or disapproval with words, facial expressions or body language.
Diversity of user feedback
It’s important to get feedback not from just one but from many users. Having feedback with many users reduces the bias from individual users and helps you see patterns across a wide range of users. This affords you a better chance of meeting the needs of more users.
As you get feedback from several users, it is helpful to alternate roles between session lead and note taker in your team.
4.4.5 User Feedback Template (Figure 4.6a)
During the user feedback session, the note taker should take the Use Feedback Template with him/her to record what the user liked, what the user didn’t like or faced challenges with, what are the questions that user asked or that emerged as part of the feedback session and if any new ideas were either shared by the user or emerged during the session.
Figure 4.6 (a) User feedback template. (b) User feedback example.
Please note that you may also take the templates for empathy map with you during these feedback sessions. However, I have noticed that having a complex template is not the most effective way to record feedback. You may update your empathy map as a result of the feedback session later on.
Here is an example from a user feedback session in Figure 4.6b.
Session Lead
Draw this template on a whiteboard and select sticky notes of different colors for each user. This will help you later in tracing specific feedback to specific users.
Select the first user and review the notes of the feedback session. As you go through the notes, write down key points on sticky notes and place them in the appropriate quadrant of the feedback template. It is very important to discuss key insights and not just get hung up on the mechanics of the process. Also, discuss how best to incorporate the feedback into the next iteration of the prototype.
Repeat this for all the other users.
Once you have all the feedback gathered on the template, start reviewing the combined feedback in each quadrant: Like, dislike, questions and ideas. You’ll see themes emerging in every quadrant. Cluster those insights and plan on incorporating those insights into the next iteration of the prototype.
After the session, the session lead should ask the team to write down all the assumptions made and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.
A use case explains how a user interacts with the solution for a perceived benefit. It is important to understand that the benefit may not be tangible and real – it could be emotional or psychological. Most teams fall into the trap of just focusing on the capabilities or features of the solution and do not put an effort into understanding how that particular capability benefits the user. To be able to do that, you must have empathy with the user. By now you should have spent enough time with the user and have understood his/her thoughts and feelings well enough at a deeper level to be able to understand the kind of benefit the user is likely to derive and perceive.
To be able to understand how your solution capabilities benefit the user, think about whether your solution is able to help the user hit the target Better for Quality advantage, Faster for Efficiency advantage, Cheaper for Cost advantage or Easier for Experience advantage.
Hitting the target could be helping the user Finish a job, Accomplish a goal and Realize a vision.
Review the value proposition section in stage 3 to gain deeper understanding of these concepts (Section 5.2).
Use this template to document use cases that are enabled by your solution for your user.
Figure 4.7 User case template.
Here is an example of how the use case template could be filled out.
Figure 4.8 User case example.
Session Lead
Draw the table on the whiteboard, and collaboratively in your team, capture the key capabilities in the form of statements reflecting benefit to the user. Think deeply on the actions the user will take while using your solution and the beneficial result that he/she will derive.
For each of the use cases, mark whether the result is a better, faster, cheaper or easier way of hitting the target – completing a job, achieving a goal or realizing a vision.
After the session, the session lead should ask the team to write down all the assumptions made and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.
4.6 Step 12: Experience Implications
Before you continue to build a productive solution or consider business value aspects, it is important to look at the implications of your future experience vision. These implications could be both dependencies and influences on other entities that may improve or diminish the overall value of the solution.
Implications should be considered from the following three angles:
1. People. All connected or influenced stakeholders who are likely to be impacted by the solution.
2. Process. If the solution is part of a larger process, then which internal and related processes are likely to be impacted by the solution or will impact the implementation of the solution? This is primarily relevant for solutions that are suited for enterprises. However, it may also be relevant for personal/consumer solutions. For example, if your solution helps consumers with low credit get loans to buy used cars, your solution will be part of a larger car-buying process which includes searching for cars, checking credit worthiness, affordability calculations, car inspections, car valuation, warranty, delivery, service, maintenance cost estimate and so on. Thinking of all these related processes will help you have a better idea of the value proposition and business model of your solution.
3. Technology. Finally, your solution is likely going to be leveraging technology. Thinking about various technology elements will help you have a better way to build and position your solution. As you think about the technology, think about the various systems, social and professional networks, data, algorithms and other tools that either you’ll be leveraging for your solution or must be thought about for implementation of your solution.
This template is used to identify people, processes and technology implications for building a solution. It highlights obvious and latent needs and considerations early on.
Figure 4.9 Experience implication template.
Based on the future experience that you have envisioned and depicted in the storyboard, think about other dependencies in terms of expectations from other stakeholders. Also consider the impact on internal and external processes and the system and data dependencies.
An example of how experience implication template could be filled is shown in Figure 4.10.
Figure 4.10 Experience Implication Example.
Session Lead
Draw the Experience Implications Template on the whiteboard and paste the scenes from the future experience vision on the top row. If you have three team members, assign each member to focus on specific implications – people, process and technology. It will be helpful to have the team members with capabilities in each area to be assigned those areas. For example, the member focused on technology (a Chief Technology Officer in a start-up) should be focused on technology implications.
5-minute Self-brainstorm
Point out the first scene and ask each member to think about implications in their area and write the implications on sticky notes.
Team Brainstorm
Once the self-brainstorming session completes, each team member should paste their sticky notes at the appropriate swim lane/row and explain their ideas. Have immersive discussion to ensure the whole team has a comprehensive understanding of the implications in all dimensions.
Move to the second scene and repeat the process. Continue moving through your experience vision and complete the entire Experience Implications Template.
After the session, the session lead should ask the team to write down all the assumptions made and record those assumptions in assumptions template in Chapter 6.
Review the prior steps and adjust as needed with the consensus of the team.