Can Requirement Gathering Workshops yield an early UX solution?
July 2018 | 10 min read
The answer is YES! Sorry for the spoiler!!!
Before joining MediaAgility, the CEO of the company recommended a book called GV SPRINT. In this book, the authors, Jake Knapp and John Zeratsky discuss an innovative approach towards getting to an agreeable solution to the design problems in 5 days. They do this by short-circuiting the design phases idea and learn. This method involves the contribution from all the stakeholders, technology heads, Marketing people and designers to come up with an early solution to the core problem at hand
GV SPRINT focuses on a large spectrum of problems, whose solutions can be a complete robotic assembly line or a simple paper-based form. The 5 days approach is effective to test the initial solution with the target users so that the client starts trusting the solution. Eventually, this solution can attract investments as well.
When it comes to solutions in IT firms, the solution is inevitably an app. I am saying just an app! Until earlier this decade, the solution sets for desktop web, mobile apps, mobile web and desktop apps required different efforts on different levels. With the rise of responsive websites and progressive web apps, the solutions are also getting streamlined into one holistic solution that runs, in parts or complete, on all devices. So we decided to take the GV SPRINT and modify it for the IT industry, especially the service industry. This gave rise to the UXBolt workshop.
I am glad you asked!
GV SPRINT requires 5 days for its effective execution. This duration is justified by the sheer scope of the possible solutions. Intense discussions in the early stages are required to finalize the channel through which the solution will be pushed to customers. While restructuring the workshop for IT service industries, as discussed in the previous paragraph, the team already knows that the solution needs to be pushed as an app. It is just a matter of cancelling out the channels which are not applicable. For example, a 3D modelling software can't run on small mobile phones (yet!) while a few applications that require movement in physical space are of no use on a desktop (a game like Jurassic Alive or google live navigation for instance!) This, in turn, saves a lot of time for the workshop since the team focuses more on optimizing the channels instead of creating or inventing one!
The second major difference in GV Sprint vs UX Bolt is the process flow. Since the solution is going to be an app, there is no change in the physical state of data throughout the flow; meaning, the entire flow remains within the same medium and all the innovation happens right there. So there is no problem with the integration of the data flows.
The third important factor is the abundance of the reference material. The service industry is all about turnaround time. There is very little time to come up with the solution and test it. If it is only within the app environment, there are a lot of patterns already defined. It is just a matter of choosing the right components and stitching them together in an orderly fashion. The only problem that remains is the core part or USP of the app, which needs to be solved and that’s where this workshop plays a vital role.
This workshop relies heavily on uninterrupted dedication from all stakeholders. When I say all stakeholders, I mean everyone who is going to work on the development of this system or the representatives of the teams. It is also important to keep in mind that while making sure most of the stakeholders are in, there has to be a cap on the number of participants in the team. The team has to include people from technology to make sure that the outcome of the two-day workshop is technically feasible. The team also needs representation from the marketing team, since they can help identify the USP of the product. The team also needs representation from management, in the form of a decision-maker! A decision-maker is generally a person who is going to take all the decisions and has the responsibility of making the product a success.
In short, the team needs representation from Technology, Sales, Marketing, Business Analysis and Management. It is the job of the UX designer to Facilitate the entire workshop and make sure everyone does their part.
War Room is where all the magic happens within a short span of 2 days. (not 16 hours. Creative processes take their own sweet time!) The War room needs to be distraction-free, full of snacks and filled with whiteboards. The war rooms should also be equipped with blank A4 sheets and bold markers. The reason behind using bold markers is to make sure that the teammates sketch their ideas and don’t write on them! Last but not the least, the team needs Post - It notes and pens! A lot of them.
Another important aspect of the war room is clearing up the calendars. GV SPRINT asks people to clear their calendars for all 5 days. UX Bolt, on the other hand, takes only 2 days and only 1 day of the decision-maker.
The actual process starts in step 2. This is the zeroth hour on day 1, with the introduction. In this process, the Facilitator encourages everyone to introduce themselves and quote their areas of expertise. This helps in establishing the roles within the room. This helps in approaching the right person for the right task. Here the Decision-maker is also identified and the rules of the workshop are explained to him/her. S/he can’t influence any decision and hence, every time there is a vote, s/he has to step out of the room till the voting is done. This eliminates the authority bias and people provide their honest feedback. The decision-maker, after the voting, walks in again and casts his or her final vote.
The next step is to map all user journeys in the form of the user/task web. Here the entire list of all user types is listed on the left-hand side and then the journey of each user type throughout the app is mapped on the whiteboard. Field level details are included wherever possible. This entire exercise will allow the team to identify the task where the problem exists or the task which needs an innovative approach; or simply the task which is going to be the USP of the said product! For the sake of this article, I am going to call this the CPT or Core Performance Task. The core performance task is what makes or breaks the product in the market and hence, it is essential that all the teams, including the management team. The decision-maker might have to step in in case of conflict and s/he is the one who casts the final vote for the same.
Like discussed earlier, a lot of research has already been done and patterns have been defined to make the life of UX Designers easy. But care has to be taken to use those patterns and interactions wisely. In this step, with well defined CPT, All the members of the team go around and collect inspiration. These can come from any app or website they have visited, not necessarily from the same domain. The obvious inspiration for the ride-hailing app in question was Ola, Uber or something similar. But the CPT solution was inspired by an app to book your dog walker! They sketch it out in the simplest form, without any text on a small post-it note. This ensures that the team member captures the essence of the UI rather than detailing it out.
This concludes Day 1.
With the help of bold markers, each member of the team tries to sketch out the details of the interaction pattern that he or she feels fit for the job; and then tries to fit the CPT it that solution. Each team member has to come up with at least 8 of these. With this collaborative exercise, the facilitator already has (8 multiplied by the team size) concepts to evaluate adopt and enrich.
The diverse team does this part better since each member tries to sketch the pattern in the way s/he sees fit. The Business Analyst will make sure that s/he includes all the field level details, A technical person, on the other hand, will make sure the sketch fits into the limitations of the defined platform. An interaction designer will make sure that the task happens in minimum taps or clicks while the person from marketing will ensure that they include the best copy there is! This way, the entire team collaborates on the ideation process and the designer gets a lot more to play with.
With all the concepts stuck on a whiteboard, the decision-maker has to walk away and then, there would be zen voting. The silent version of voting makes sure the thoughts are not influenced by anyone else. Just to make sure that the voting leaves no trace on the work, the voting will be done with small stickers. If the voter has any questions, s/he can write them down on a post-it note and paste on the side of the concept. After all the team members are through with the voting, the decision-maker walks in. The questions posted next to each concept are then answered by the makers of the concept. The decision-maker takes into consideration all the concepts, all the votes and all the questions raised. The vote cast by the decision-maker on the concept carries the highest weight and that becomes the core concept for the solution set. Effectively, the workshop ends here at the end of two days. The rest of the tasks can be carried out by the design team and the prototype test results should be shared with the team for further road mapping.
The concept coming out of the discussion is one that has been seen by all team members, including technical folks. This makes the concept the most agreeable solution. It is safe for the designers to consider that and build on top of it.
The next step is making the prototype. It can be as simple as a paper prototype. With advanced tools, like sketch and invision studio, creating the concept and testing it has become a matter of hours than days. If the product under discussion is a mobile app, then lightweight tools like ‘pop by marvel’ can help to create a prototype right then and there.
For testing purposes, it is essential to recruit only 5, but more suitable users. The criteria for the same should be
The person who has never seen the concept. The person cannot be from the workshop team
The person should have adequate domain knowledge if we are doing it for any ERP / large scale system, it becomes more essential that we select the people with at least some knowledge of the system.
The recruited users should be diverse in terms of educational qualifications and tech-savviness.
The test conducted in this scenario is a combination of “Task scenario”, “Time to task” and “Think aloud”. Here the user is given the context beforehand and then the fidelity level of the prototype is explained to him/her. Then the prototype is shown to the user and then the task is explained. The user is encouraged to think out loud. The time from handing over the prototype to task completion is also measured.
All the errors and mistake made by the user are silently observed and recorded by the facilitator. These feed valuable information to the future iterations.
Since the prototype is made in less time, there have to be separate success criteria depending upon the fidelity level of the prototype. If the tests are done right after the workshop with a makeshift prototype created in the mobile-based light prototyping tools, the time to task constraint can be slightly lenient. Or if a form or a screen had to be broken down into multiple screen sketches, since the prototyping tools do not support the scrolling, then the three-click rule can be ignored. So the success criteria can be different for different scenarios and the most suitable one needs to be picked for the tests to be conclusive.
In short, the Bolt method condenses the entire design sprint workshop into 2 days and helps in getting to an agreeable first draft of the application under development. The salient features are:
Everyone becomes a part of the design team and can contribute to his or her expertise.
The design process involves people from all backgrounds making it completely transparent. Hence, there are no surprises when actual development starts.
The fail-fast philosophy can be practised effectively here. The process gets over in as low as 2 days, depending upon the type of prototype the team decides to construct and test. This makes getting to iteration 2 real quick if needed.
There is a minimum document exchange. Everything happens in front of everyone, with everyone's approval.
Query resolution is faster and effective, since the representative members of all domains are present in the same room, with a decider to resolve any forecasted issues.
At the beginning itself, field-level details start to pop up on the design. This helps in database design in later phases.
The sheer volume of ideas!!!
I have personally tested this method at MediaAgility and it has given me good results so far. I am still trying to fine-tune this methodology to make it perfect and hope that this will become a standard requirement gathering procedure in the IT service industry!