Prolog
Scenario 1 – The Swiss Army Knife
Monday morning, 08:30, a meeting room somewhere on the third floor of an office complex. At the table: several developers, project managers, marketing representatives, and two UX specialists. Their budget for the next three months is secured. The goal of the workshop is to define the first work packages of a long-term plan to revise their entire software and make it more user-friendly. During the workshop, it turns out that there are four work packages in total, with each attending project manager assuming that his or her package has priority. The result is a long dispute which ends in the decision to tackle all packages simultaneously. After burning through the first budgets, the big disappointment sets in – nothing has been finished, no noticable progress compared to the status quo has been achieved. The project is therefore stopped and postponed to an uncertain date.
Scenario 2 – The Top Secret Project
Tuesday afternoon, 14:30, the CEO’s office. In addition to three close confidants of the management, the head of the development team and two representatives of an external UX agency are present. They are planning to develop a new software in the next two years. The project team is confident that the software will be a resounding success, which is why the budget for the entire development has already been assured. The software is developed in-house and after two years, a creatively sophisticated software that has been extensively tested and approved by internal staff is launched. The potential customers did not know about the new development so far, because the management did not want anybody to know something about the innovative product before release.
One year later: The software has been available for 12 months, but only sold once – to a subsidiary. Two years of development have been in vain. The UX agency gets removed from the project, as it has apparently not provided an exciting enough experience for potential users.
—
Projects like those two exaggerated scenarios are common. A motivated start, a great team – but a frustrating result nobody can figure out. But why is that? What can be done to avoid such situations of frustration and, above all, money sinks?
Finding the cause of the problem
Looking back at the scenarios, problems that occurred could actually have been avoided. Let’ go over both examples again and find the causes of their respective frustrations:
Scenario 1
Many threads have been picked up, but no one has been followed to the end. There was a rough idea of a solution for each problem, but nobody could REALLY solve one of the problems in practive, because behind the tempting façade of the solution sketch was just an empty room with a large “To Do” sign.
Scenario 2
Basically, everything was done right: the software was designed, tested, designed, implemented, specified, … and all for nothing, because the product lacked a strong business case and could not be sold. A problem was solved that apparently did not exist.
—
Now, what do these projects have in common? Quite simple – in hindsight, their problems could have been avoided by clean preliminary work before the first work began.
The Project Scoping Workshop
The project preparation and definition seem to be the key. What is our project? What is it about, what problem does our product solve? Who is it for? Who do we sell to?
To answer these questions, we have established the “Project Scoping Workshop” as an effective start in our Continuous UX process. The goal of the workshop is to bring together all product-relevant perspectives and to jointly develop a project definition to which all present stakeholders can commit. For this goal, the following tasks have to be mastered:
- Assemble your workshop participants!
- Focus on problems, not solutions!
- Find a strong business case!
- Collect all stakeholders!
- Model a persona!
- Write a scenario!
- Formulate a product statement!
- Check your assumptions!
Sounds like a lot of work? Yes, but mostly it requires discipline. Every single point can be done in 1-2 hours. For comparison, think back to Scenario 2 with its two years of development – THAT was a lot of work, but without any outcome. A few hours are nothing in comparison. Let’s look at the points in detail.
1. Assemble your workshop participants!
Of course, you could make it easy for yourself and gather the people that have an understanding of the project similar to yours – but do they help to find new perspectives?
Therefore, try to assemble the widest possible group of participants. Frictions and conflicts are inevitable? Perfect, because you can get them out of the way now, before expensive project work starts.
Attempt to include the following roles when looking for participants
- (Managing) Director (for the business perspective)
- Product Manager or PO (for the customer perspective)
- Marketing or Sales Manager (for the sales perspective)
- 1st level Support or Training (for the user perspective)
- Software engineer (for the technical perspective)
Tip: In our experience 6–7 participants have turned out to be a good number. More participants usually lead to lengthy discussions, which are difficult to moderate due to the many different opinions. On the other hand, fewer participants lead to a “dilution” of the result, since individual opinions have too much weight.
2. Focus on problems, not solutions!
The most difficult task is the first: try to forget all the solutions for a while. Just focus on real-life issues with your team. There will always be team members that have a very accurate picture of their solution in mind. Get them to put these solutions aside for a while. Our one goal in the Project Scoping Workshop is to find out what needs we need to satisfy for the users of the upcoming product. The WHY is the goal, not the HOW.
Tip: Pay attention to phrases like: “The user wants to have feature XY”. This is a (usually unconscious) attempt to formulate a solution as a need. The underlying need is often real, but we can state it as a need. Make it clear to the workshop participants that any feature that does not fulfill user needs is not relevant for us!
3. Find a strong business case!
We saw it in Top Secret Project: A project may run smoothly in the implementation – if it does not sell, in case of doubt, all the work was in vain. Find out where current business issues or opportunities are and collectively define a goal laser-focused on those opportunities. Again, HOW you want to reach your goal is secondary, it’s all about WHAT you want to achieve.
Tip: Don’t only specify a goal, but also a measurable criterion to find out whether you were really successful when the project is finished. For example, in our second scenario, this might have been sales figures.
4. Collect all stakeholders!
The success of a product does not solely depend on the user – there are many more stakeholders involved in the product cycle. From the person who decides to buy your product to the service staff, gather all the stakeholders who might come into contact with your future product or have an interest in its success. After that, determine as a team which of these stakeholders you must primarily serve in order to achieve your previously set business goal.
Tip: Aligning with the business goal leads to supposedly important individual stakeholders suddenly losing priority. If you are going to present something at a trade show, it may be better to build a UI for the needs of a trade show visitor or decider and not to those of a future end user.
5. Model a persona!
With the business goal and the stakeholders done, things are getting more tangible. Take the most relevant stakeholder for the business case and model a persona for its role. In order to be able to put yourselves in the persona’s shoes later on in the design process, add as much detail as possible to awaken emotions and empathy.
Tip: From now on, always call your persona by her name, not “the persona” or “the operator”. You will notice that your team can put themselves into the position of the persona if everyone uses her name. Also, print out the persona and display it in the team offices to keep it alive and present throughout the project. By the way, we are developing Persona Template Tool “LeanScope”, a tool to create a printable Persona poster in minutes.
6. Write a scenario!
We are getting even more concrete now. Write a “Context of Use” scenario with your team that connects the persona and the previously defined business issues. Try to work as detailed as possible, to understand the problems and needs of your protagonist and empathize with her story. Again, you want to be emotional – but do not overdo it.
Tip: If You can also scribble the scenario. This often sets a good mood and helps to find details that you would never have come to otherwise.
7. Formulate a product statement!
You made it! You now know who, in which role and which context, you have to make happy in order to achieve what goal. If we think back to our Scenario 1 (The Swiss Army Knife), that’s exactly where the problem was. There was no persona, no key business objective, and certainly no usage scenario to describe the persona’s interaction with the current system. In fact, only headlines of possible scenarios were collected without once going into detail.
Summarize the quintessence of what you have achieved at the end of your workshop in a catchy phrase – the so-called “product statement”, so that all participants can commit themselves to that. Again, you should still exclude solutions. Just describe who you want to support in achieving what goal. An example could look like this:
With the completion of the pilot project in July 2019, Manfred the machine operator is supported by the HMI in being able to transfer the values ??of the data sheet into the system without making mistakes in order to avoid production errors.
Tip: The final statement is a summary of the previous steps. Never skip it for convenience or lack of time as it combines all the insights of your workshop into one final result. You have the unique opportunity here to commit all team members to a common goal formulated in a catchy sentence.
8. Verify your assumptions!
Hardly any scenario takes place exactly in the meeting room and with the people participating in the Project Scoping Workshop. So, together with your team, you’ll have to make decisions and assumptions about your persona and scenario that need to be verified afterwards. The best objective and modeling are useless when the reality is different- Check both:
- The business case in consultation with a representative of the business point of view, if no corresponding person was present at the workshop.
- Persona and scenario with the help of at least one user visit.
Tip: Do not wait with your research. Try to start your project only after the verification process is finished. Be prepared for changes to the project course.
Conclusion
Unforeseen difficulties, course changes or even project stops can happen and will happen Iover the course of the project..
However, with the clean preparation of a project scoping workshop, the risks of a total failure can be reduced to an absolute minimum because the project starts on stable ground.
Find the right participants!
- Getting cozy is not helping anybody!
- A project scoping workshop is expensive, but much cheaper than completing a whole project without a result. (See Swiss Army Knife and Top Secret Project)
Focus on problems!
- Solutions overwhelm you and block the emergence of new ideas.
- Only if you know the problems, you can design suitable solutions!
Find a strong business case!
- The greatest product will not help anyone if it does not rest on a solid business foundation. (See Top Secret Project)
Collect all stakeholders!
- By collecting ALL stakeholders who may be interested in your product, interesting new ideas arise.
Model a persona!
- Bring a fictional person to life!
- Personal information helps to empathize with the persona later on.
Write a scenario!
- People love stories!
- Enrich your story with many details so you find new knowledge, user needs and ideas.
Formulate a product statement
- Keep your result simple –an incomprehensible statement helps no one.
- Commit the team to a common goal!
Check your assumptions
- From the business case to the details of the scenario – check all assumptions to minimize the project risk (See Top Secret Project)
If you are interested, we will also provide you with detailed knowledge of the implementation, moderation and form of the project scoping workshop in our UX Academy module “Project Scoping”.
Our services related to the article:
