We are constantly striving to improve CLINQ. For us it’s not just about resolving bugs or improving user experience. We first and foremost want to be innovative, creative, and we want to spark excitement like intelligent voice assistants and artificial intelligence.
The underlying question we ask ourselves is, which problems can we solve with CLINQ to help improve the work day? Everyone in the team has their own ideas and approaches for how we can solve telephony problems. We wanted to channel these ideas and potentially create a first prototype, so we decided to make use of Google’s Design Sprint method.
- What we did: We carried out a (slightly modified) Google Design Sprint.
- Why we did it: We wanted to solve a problem that we had defined before the sprint. We planned to have a testable prototype by the end of the sprint.
- How long it took:
2 days preparation with an external moderator who helped us define the problem and who prepared the sprint
1 day preparation on our side (empathy map, organisation)
5 days for the design sprint
2 days post-processing (documentation, finding further testers, putting finishing touches on the prototype)
- Who took part:
1 external moderator
2 UX designers (focus on design and concept)
2 developers (focus on backend and frontend)
1 decision maker – in our case our Product Lead Stefan, who was also one of our experts
- A total of 5 experts to define the problem within interviews
- 6 testers for the user tests at the end of the sprint
Day 1 – Understanding the Problem
Presenting the Empathy Map
The week leading up to the design sprint we created an empathy map. If you aren’t familiar with an empathy map, you can kind of think of it as a simplified persona. It is essentially a person or target audience with certain needs and problems who observes and has experience in their surroundings.
The categories are: what does this person think and feel? What does this person hear in their workplace as well as throughout a normal day? The same question goes for what this person sees, says, and does. Aside from that, we also considered which needs, wants, and problems drive them. Each of these categories helped us to solve the problem we defined for the sprint.
Normally, an empathy map can be created with just the team as the team is rich with individual ideas of who this person is. We were lucky enough to also have additional input and create our empathy map with experts from the company outside of our team: colleagues from the sales and customer service teams.
And so we began by presenting our empathy map to all participants of the design sprint.
Interviews with the Experts
The morning continued with the expert interviews. These interviews were intended to take a closer look at the problem and hone our understanding of it.
The first person we interviewed was Stefan. Stefan is CLINQ’s Product Lead and is responsible for establishing the scope of the problem and the direction we as a team want to move in. Afterwards we interviewed Steffi, a member of the customer service team. She described her standard workday as well as provided insights into challenges she faces with telephony. Lastly we interviewed Dima, who is a member of the sales team. He described the guidelines he sets for himself, what he wants to achieve, and which tools he uses. An important insight for us: he needs efficient tools which support or relieve him in telephony without being a distraction.
The Sprint Questions
During the interview, the interviewees wrote down relevant “How might we -” questions down, essentially questions that describe problems that the experts face on a daily basis. Some questions were, “How might we reduce manual work or tasks during a phone call?” or “How might we reduce or even eliminate post-phone call processing or editing?”.
A number of other questions and aspects were then gathered and voted on based on priority. Here we’d like to note that the decision maker, our Product Lead Stefan, had a vote worth twice as much as the others’. As the questions reveal, the focus of the topics and questions was processing after a phone call.
The Long Term Goal
The question of “What is this about?” is somewhat synonymous with the long term goal. Based on our findings from the empathy map, the expert interviews, and most importantly the sprint questions, the team then took the next step and formed the goal.
In two years every CLINQ user should only need to concentrate on their conversation and no longer worry about post-phone call processing.the long term goal for our sprint
It’s not the most precise statement you can form, but it still helped us tremendously to all be on the same page and have the same understanding of our one common goal. This was especially significant considering the entire design sprint was working toward this goal.
The team then shared different, inspiring tools and designs with each other. The emphasis of the presentations was on what made the tools well done and why. From that the team was able to build a mood board. The mood board would then stand in the room throughout the sprint and act as inspiration. Or not. That was up to the progression of the sprint.
The Design Studio
The Design Studio, during which the team develops multiple iterations of concepts and solutions, usually takes around 4 hours. In our case the design sprint was four hours of scribbles and wireframes. At first everyone scribbled for themselves and then pitched their ideas to the rest of the team. Then, after each presentation and (constructive) critique, we entered the second step where everyone could implement ideas of the others in their own concept.
Some tossed their original ideas completely and others adapted their ideas based on the critique they had previously received. Another round of presentations, critiques, and teamwork later and we eventually came up with a sturdy foundation to work with. This was a particularly long day, which is why the last decision was set to be made on day 2.
Day 2 – Decide on a Solution
Design Studio Part II
To get back into the day, the team decided to do another round of “Design – Pitch – Critique” followed by drawing intricate sketches for the art gallery – the place where, in the end, the decision of which solution to build would be made.
All wireframes as well as a heatmap were put on display to assist Stefan in his voting. These were then voted on by the team with colorful dots, just like the sprint questions were the day before. Stefan then had the possibility to vote on his favorite solution as well as a second feature.
User Flow Test
At this point it was time for the team to consider the prototype’s extensiveness and what the matching user tests could look like. This also meant defining which questions the user test should answer as well as which steps the user should go through during the test. These were then visualised on a storyboard.
The storyboard serves to assist the team in agreeing on the number of and handling of the tested screens. For example: how many interface elements should be in a single screen? How many total screens should there be per test? These decisions played a large role in the number of designs and the code we required for the prototype.
Day 3 – Building the Prototype
The name says it all: on the third day the team designed and coded the prototype. This, as usual, was done by pairing: everyone on the team worked in groups of two.
The first designs were drafted quickly, which freed up the UX designers to assist and consult the developers in creating the prototype. The long day was definitely worth – the team had successfully created a testable prototype.
Day 4 – Testing
A total of 6 people volunteered to participate in testing the prototype. The 6 volunteers consisted of 2 colleagues from sipgate’s sales team and 4 external participants who spend a large majority of their work lives on the telephone. Divided by a partition, the test was set up with the moderator on one side and the rest of the team on the other. The team took notes during the tests and these were used to devise questions that played a large role in planning the last day of the design sprint.
Day 5 – Planning
User Story Mapping
Story mapping is a tool for creating your first backlog by creating stories, otherwise known as tasks, with a user focus. While story mapping, the team illustrates as detailed as possible the expectations required for the product. A detailed example can be found here: User Story Mapping
The moment we’d all been waiting for! The design sprint team finally got to present the prototype to the rest of the CLINQ team. This presentation took place in the form of a final user test and each individual feature was ran through for the viewers. And guess what? The prototype aced the test! The design sprint’s triumph deserved some celebration and perhaps a beer or two. 😀
Conclusion of the “Design Sprint” Method
Don’t be fooled: a design sprint is incredibly arduous for both the team and the moderator, regardless of the length of the sprint. It’s truly a lot of work, even with regular breaks. But this can also be an advantage. The team can get in the zone, fully concentrated, and stay focused. How often does that happen on a normal work day, let al0one for days on end? And: the exceptional result, with which the entire team was happy, shows that the effort was worth it.
Whoever doesn’t want to dive directly into a complete design sprint can start slowly and try out individual methods that a design sprint has to offer. The Design Studio, for example. It lends itself well as an individual method to, together with a team, conceptualize creative ideas. Give it a try!
By the way: the ideas from our prototype haven’t just disappeared into some black hole of a backlog, but are instead continuing to be developed by the entire CLINQ team. It’s ongoing, so no spoilers, but we can say: it will be grandiose!