What we learned in just 5 days -(How we ran a design sprint at a university)
This is an experience report about a five day GV Design Sprint in a university setting. We split the report into five chapters, one per day, and share some of the lessons learned.
Who are ‘we’? We are a group of Usability Engineering students at the HSRW (Rhine-Waal University of Applied Sciences). The ‘advanced research project’ ARP-A for the first semester and ARP-B for the second or as the usability engineering students call it ‘semester project’ is part of the curriculum. This time around, things were a little different. First, let’s have a look at what the usual semester project felt like for many students:
Now the sprint week:
Differences between us and the sprint book
Afew words upfront.. If you’re reading this, we assume you are familiar with the basic sprint process. This is not a documentation on how to run a sprint. We followed the standard GV process which you can read about on their site. The only apparent differences derive from the fact that we did it in a university setting. As we are 12 students in our class, our sprint included of more than 7 people, which is the ‘magic number’, according to the book. 12+1 Facilitator and Decider (Our Professor) makes 13. Including the vice president, whose sole appearance was on Wednesday, this adds up to 14 of which at least 12 — namely us students — did not know about the topic in advance. There was a kick off event about two weeks before the actual sprint, which is when we were introduced to the ‘sprint’. We also learned about the ground rules: No cellphones, laptop devices except when needed for the sprint, take calls outside and so on. It’s all in the sprint book, just look it up ;-)
Nevertheless, we were left with no clue to the topic of sprint, so no prior research would be done. A benefit for us, the soon-to-be sprint team, was that our facilitator took care of recruiting and making sure the experts were available on Monday and test participants would show up on Friday. It’s nice that we didn’t have to worry about that during the week. For communication purposes we set up a slack team. This was specially useful on prototyping day.
We won’t go into anymore detail here about how to run a Sprint as plenty of people have already done that. Instead, you can find some resource links at the end of this post.
So. We, the sprint team.
Our motivation was to create a working, high fidelity prototype within a 5 day human-centred design approach called ‘SprintWeek’.
Unless further specified, the line to left shall indicate the facilitators’ notes.
We all learn. All the time. How do we learn? By research, trial and error. Quite often by reproducing/ imitating. We copy and ‘paste’.
People rebuild, remake, rework
Most of the quotes will also stem from the facilitator.
We want to create a platform — the best open access self-study knowledge platform for any kind of project or topic!
MONDAY
Setting Goals and Listing Problems
Monday started with an introduction about the topic and the sprint approach, which we were going to use for the week, from our facilitator. We talked about the general idea of creating a platform for realising shared ideas. Then we collected the individual thoughts to form the general, but more specified, idea of our platform, which can provide functions for easily building, documenting and sharing projects.
In order to have a common understanding of the long term goals of our platform, we set up a list of success- and failure-factors (sprint-questions).
With the long-term goal in mind, we created a map, consisting of the stakeholders, their activities and the core functions of our platform. The map illustrates the relation between these aspects and represents the core concept of our sprint project.
To make sure that our project abides by a human centred design approach, we conducted four interviews with experts, who represented the needs of business stakeholders and typical users. We presented our map with the success- and failure factors to the experts and got some valuable information on how to improve our concept and which aspects to focus on.
Based on our long-term goals and the experts’ responses, we set up How-Might-We Questions to address the most important challenges to keep in mind. We collected the questions on post-its, gathered and sorted them into categories. After that, we voted on the most relevant categories and localised them on our map.
Worked surprisingly well. Someone shouted out a ‘cluster’s topic’ and all people started collecting notes.
We identified three core aspects: sharing an idea, documenting and remaking projects. Each participant chose one of those to work on the next day. After we left, the facilitator had a look at each category of HMW notes and picked the ‘most important’ ones. He made a list and sent shared it to the students as a reminder about the problems encountered.
Monday’s Lessons Learned
- we realised how important user involvement and feedback is at an early stage of a project, because the users mentioned aspects, we did not think of beforehand.
- For the users (interviewees) it was difficult to unterstand our idea based on the map. It took the most of the interview time to explain the users, what our idea is and what the map is describing. For the next time, we should prepare scenarios, which would help us to illustrate our idea.
- Our map might have been too complex. What should be improved? Less stakeholders? Less tasks? How do you know that you have selected the right tasks?
TUESDAY
Sketching Day
Tuesday started with the lightning demos. We had researched some existing solutions that might fit well into our project as homework and were asked to promote our ideas in 3-minute demos. The facilitator gathered useful ideas with a quick drawing on the whiteboard:
The result then was impressive! Nobody had expected that many nice ideas ☺
With a quick review, the facilitator demonstrated how nicely Monday’s HMW notes, long-term-goals and concept ideas of Lightning demos fit together.
Since our map was too complex, we thought it a good idea to circle back and simplify it. We made a simplified map. Only stakeholders relevant for the main workflow were kept in.
We mapped each idea from the lightning demos to topic areas on the map. Each of us picked an area of the map to perform the 4 step sketching on:
*1 — notes **2 — ideas ***3 — crazy 8’s ****4 — solution sketch
Your mind is different from mine. You may set your focus on different aspects than I do.
We took 20 minutes to revise the ideas from Monday and Tuesday morning and gather notes.
…another 20 minutes to privately jot down some rough ideas.
The idea here is that everyone thinks for himself first, because ‘group-brainstorming is broken’, as is explained in the Sprint book. Everybody kept their notes private. Then we circled the ideas we deemed most promising.
Eight minutes. Fold a sheet of paper to create eight frames. Hence crazy 8’s. Sketch a variation of one of your best ideas in each frame. Spend one minute per sketch. (p. 111), sprint manual
We each picked a favourite from our ideas sheet and asked ourselves ‘What could be another good way of doing this?’, scribbled any ideas in less than a minute and then went on to another favourite idea to iterate on. We used this to iterate on various types of ideas, including elements for interaction and navigation, wording, work flow diagrams. Just like the notes, the crazy 8’s were kept to ourselves.
On to the solution sketch!
The Rules
The Results
The solutions sketches were collected anonymously and we left for the day. Then something magical happened: Over night, our sketches were arranged in an art-gallery style…
Tuesday’s Lessons Learned
- Steal like an artist
- Crazy 8’s were really crazy
- It’s good to take some time for yourself to revise what happened after a bunch of discussions
- We learned to focus on only one thing even though there were many interesting ideas
- Don’t make things too complicated
- Once we decide to do something, there is no looking back
WEDNESDAY
Decisions, Decisions!
Day 3 started off with the display of an “Art Museum” for sketched Ideas from each team member for the platform. The sketched ideas and features for each ideas were reviewed by the whole team.
We voted, in heat map fashion, to determine the features to prototype. Everyone participated: team members, vice- and senior facilitator.
The speed critique involved a round of quick sessions — three minutes per sketch — including highlights and criticism regarding its’ compatibility with the long term goal.
“Lets find the million dollar idea”
Then a straw poll was conducted by team members for the ideas and super voting was performed by the facilitator for ideas with the most voted features by the team. This resulted in dividing ‘Winners’ from ‘Maybe Laters’.
It is important to have everybody understand the limits of the design space. Otherwise discussion might go on and on again.
Here, in our case, the ‘limitation’ or focus was set on ‘documenting your project while you are creating something’. We presented this as a key aspect of the design but the students did not pay a lot of attention on that. They always fell back to their way of thinking.
Don’t call it winners — it implicates that there are losers.
We decided to skip ‘Fake brand names’ and ‘Note and Vote’ and also decided not to ‘rumble’. Instead, we came up with two major concepts: Everybody can and Power of us.
Team A was assigned for sketching the “Everybody Can” prototype on whiteboard that focused on the workflow of the platform from the starting (homepage) to the project creation process. Sketching on the whiteboard made it easier for everyone to participate and present their views for the prototype as well as making quick changes.
Team B focused on the sketching the “The Power of Us” prototype. It was based on the project workflow and focused on the community aspects.
After finishing the two prototypes, they were combined with minor iterations to form one storyboard.
Day 3 ended with the voting for selection for the prototyping tools to be used for the next day. The voting resulted in choosing Adobe Photoshop for designing and InVision for the digital prototyping.
Wednesday’s Lessons Learned
This was one of the most exhausting days because people had different ideas in their minds and getting everyone to have one picture in mind was very challenging. We learned how to vote and choose the right features and ideas to work on for the project and then had hands-on experience on making the sketched prototype based on the selected ideas. The next phase was to bring the sketched prototype to life.
Here we faced huge difficulties.
Is there a good reference on how to introduce productive storyboarding?
How detailed does the story need to be? Do we need a login screen in the story board and/or prototype? I recommended to start with a list of steps (on sticky notes) to show the workflow. I also advised to stick to a strict time-limit.
They did not follow my recommendation about the time-limit. Instead, they got stuck in discussions about details. Maybe it was because of the team size. We split up into 2 teams — each dealt with a different aspect of the future system. One team consist of 7 members, the other team of 3. The bigger group split internally. Two started sketching, the other started discussing things unrelated to the sprint. They had difficulties to make use of the existing concepts and to put it in a sequence. I believe they wanted to reinvent everything ;)
To stop and to make them focus about a general workflow I created a game.
We used 2 tables and 2 chairs and put a whiteboard between the tables and persons so that they cannot see each other. As we were creating a platform for documenting projects (for reproduction by anyone) I asked one of the participants to create a paper plane. I asked “how would you like to document it”. The answer was — “by video”. So I gave him a mobile and set it to record. While he was creating the plane, the video records. He also was explaining each step (giving instructions). Then, I handed over the video and asked the second participant to recreate the paper plane. After that we discussed what media and information is needed (in terms of a workflow — or storyline) to make & document it.
By doing this, the group understood the level of detail for the process and the story needed. Then, they understood that the goal is important. I forced them to think about the goal. The Scribe also mentioned that it makes sense to agree on the final output first and then always ask yourself on how to achieve this. I set the timer onto 3 minutes. They came up with the basic high level structure of the workflow. They spent another 3 minutes to discuss what was missing.
THURSDAY
Prototyping and Test Preparations
On Thursday we split up, trying to best distribute our skills. The roles of makers, stitchers, writer, asset collector and interviewers were taken. Nine of us were responsible for creating the high-fidelity prototype based on the two storyboards written on Wednesday and the three interviewers got busy preparing the usability lab and the test script.
While some of the makers decided on the layout grid based on live information about the test setup, the asset collector and a maker decided on a UI kit that had most elements we needed and on a colour scheme. The stitchers had to go an extra mile and organised the ideas that were not so clear on the storyboards. We soon realised it was better if the storyboards were simplified and put together.
We took five minutes to vote on a name for the platform and the asset collector came up with a quick logo. The screens were made using various UI kits in Photoshop and Sketch, depending on the maker’s preference. InVision, the elected prototyping tool, was used to add hotspots to the mockup and set up our platform’s façade.
The writer worked on the copy and on an advertising piece. We placed the ad on a magazine and used it to introduce our platform to participants on following day.
Test Preparations
The Interviewers consisted of a team of three people and moved to the Usability Lab to prepare the test setup for Friday. The morning was spent on exploring the usability lab, what soft- and hardware is available and can be used. By noon the required soft- and hardware elements for conducting the test were tested and set up. The documents which needed to be created were defined and divided among the group members to prepare:
- Interview guideline consisting of agenda, introduction, storyline
- Technical lab setup
- Follow-up Questionnaire
- Signs “Quiet Please, Interview in Progress!”
Roles: 1 Interviewer, 9 Observers and 1 Moderator who performed as a link between the observers and the interviewer. Around late afternoon the prototype was ready for us to view and we could finish the story line for the test.
A long and exhausting day ended with a positive feeling of having a high-fidelity prototype ready and the test setup and roles prepared for Friday.
Here you can find the link to the prototype of Loops.
Thursday’s Lessons Learned
- Having two stitchers helped a lot on the communication as the team was spread in two rooms (the usability lab and the media lab)
- Photoshop and especially Sketch are fast and easy prototyping tools (because we had experienced Photoshop Users on our team)
- We did some great collaborative working on the design, even though we ran out of time to perfect it, or try alternatives
FRIDAY
Test Day
On the last day of the Design sprint week, we conducted a usability on our prototype. The test was designed to be simple and pragmatic. We planned to interview three neutral users in a two-room setup consisting of an Interview room and an Observation room. The sprint team could observe users from the mirror and follow the navigations on the video feed. We made a big grid on whiteboard to collect the team’s notes. We had one column for each participant and a row for each screen of the prototype.
Interviews
The chief interviewer welcomed the participant in a friendly manner to make her feel comfortable. Interviews started with some small talk and then contextual questions followed. Our fake magazine ad served as an introduction and then we presented the prototype. Users were encouraged to think out loud and be honest with the feedback.
Each interview went on for about 40 mins. The sprint team made notes and observations from the User interviews.
Analysis
After the interviews the grid board was full of notes from the user’s comments, quotes, observations and interpretations.
We made a quick round of re-sorting all the notes. It helped us in drawing conclusions and finding priorities. After a brief discussion we felt we had a better picture of the users’ needs. Then we voted for the best features in our prototype. And we recognised the parts worth improving.
Friday learnings & Wrap up
After recapping friday’s test sessions we gathered for a final wrap up. Everybody made a list of his personal top 3 most important aspects for the platform. The overall three core aspects were:
- Take the ‘PAIN OUT OF DOCUMENTATION’ — this really is the base of the problem and innovation
- Make RECREATION A BREEZE — with detailed requirements, instructions and supplier integration…
- Engagement by REWARDS — strong community, licensing…
We didn’t need Investors as stakeholders in our map, but after this week we ourselves might be looking for investors. — ¯\_(ツ)_/¯
Contact
If you like to get in contact with us, here is the list of people:
Karsten Nebe (karsten.nebe@hochschule-rhein-waal.de) [Facilitator]
Johnathan Yen (Johnathanyen@gmail.com) [Scribe, 2nd Facilitator on Wednesday]
Alexis César Avalos (alexis.avalos.aguilar@gmail.com)
Houssem Gueloui (houssemgueloui@gmail.com)
Heike Hörnschemeyer (heike.hoernschemeyer@gmail.com)
Dominic Kennedy (mail@dominickennedy.de)
Swati Mathur (mathurswati05@gmail.com)
Susanne Siebers (s_siebers@gmx.net)
T — aka — Pimchanok Sripraphan (pimchanok.cmu@gmail.com)
Jassim Talat (jassim.talat@gmail.com)
Viktor Wasilev (Viktor.wasilev@gmail.com)
Daniela Weinzettl (daniela.weinzettl@gmx.net)
Bianca Zanardi (bianca.zanardi@gmail.com)