6.0 Case Study
Chapter 6 of Remote Design Thinking
This section explores Hanno’s work practice and presents a case study used to test and validate my research questions.
6.1 Hanno
The company
The company examined in this report is Hanno, a remote UX design agency registered in the UK and operating worldwide. Hanno was founded in 2012 by Jon Lay, a former law student who began doing freelance web design jobs while still at university. As he started receiving more client projects, he began sharing his workload with Sergei, a web designer based in Russia whom he met online. This was the beginning of a remote collaboration which gradually grew over the past three years.
Team
Hanno consists of 7 team members based in Malaysia, Indonesia, UK, Russia, Hungary and Spain. Hanno’s team describes itself as being “flat and open” (Hanno, 2015). There are no assigned leaders nor project managers and each team member has full autonomy over their time management. The team is split into two roles: designer or coach. Coaches are “responsible for supporting the rest of their teams and helping them to do great work” (Hanno’s Playbook, 2015) whereas designers handle programming, visual design and strategy in client projects. All team members contribute to developing the company internally either by blogging, networking, pitching to clients or building its company culture.
Clients
Hanno’s clients are primarily startup companies located around the world. Unlike other agencies which offer their services on a mid to long-term basis, Hanno’s team can be ‘hired’ weekly to work together with its clients in its design process (Hanno, 2015). It becomes a remote extension of the client’s team and trains the client how to run parts of the design process on its own in order to empower them. Jon describes this process as “a gift that keeps on giving.”
Vision
When I joined the team, Jon explained that the agency was aspiring to create the best possible design culture that would allow it to build great products for clients with user experience design. Currently Hanno is repositioning itself as a social business that will solve global problems using design to maximise its social good impact.
Culture
Hanno has created a culture that enables and facilitates its team to maintain a flexible lifestyle while working with clients, regardless of where they are geographically located. From Jon’s perspective, offering the freedom to work from anywhere shapes a great culture that makes it easier to hire new talent. The team recently created its own manifesto which defines the company’s values. Also known as the ‘Hannifesto’, the team’s philosophy is to use “the power of great design to make a difference in the world” and help people to break the status quo by taking actions that will have a positive impact (Hanno’s Culture, 2014).
Transparency and doing social good are at the core of Hanno’s identity (Hanno, 2015). Following the example of other remote companies, it has made its entire structure open to the public in its online Playbook. It also reveals its financial details, roadmaps and salaries within the team. By doing so, it builds trust and understanding with its clients and the team.
Another major aspect of Hanno’s culture is self-improvement. Each team member creates Objectives and Key Results (OKRs). These include personal and professional goals that will help the team members to continuously grow and push themselves out of their comfort zone. Hanno’s culture aims to create a supportive network. Jon believes that “it’s about trying to build people up and make them be the best they can be.”
Process
Hanno’s working process is based around agile project management rather than top-down, or ‘waterfall’ management. Agile practices are organised by self-managed teams that decide how to coordinate their own work (Moe, Dingsøyr, Dybå, 2010). Hanno uses a workflow based on the Scrum framework which is aimed at involving clients and other stakeholders in the development process and is capable of adapting quickly to changes that may occur during the life-cycle of a project (Bright Hub PM, 2012). Scrum is typically used with a small team and is comprised of a series of short development phases or iterations known as sprints (Moe, Dingsøyr, Dybå, 2010). An important part of the Scrum process is the daily Scrum meeting which allows a team to iterate on users’ feedback in order to improve the deliverable before the final version is launched.
Tools
Hanno has no project managers to force team members to achieve their tasks. Instead, it has a structure and an array of online tools that support the team when running a project collaboratively. The team uses about 30 online and cloud-based tools for the various phases of the project. Some of these tools, such as Slack, Skype, Google Hangouts and Sqwiggle, are used solely for communicating on a day-to-day basis. Others, like Google Drive, are used to create, store and share files with clients and amongst the team.
The most extensive project management tool used at Hanno is Asana, a web application that allows teams to communicate and operate on projects without using email. Asana lets team members assign tasks to each other, making it easier to prioritise tasks and inform the team on the progress of a client project.
Communication
Hanno has created a ‘Communication’ folder in its shared Google Drive that contains information on how to communicate effectively. This includes practical guides on how to deal with different time zones and how to use tools such as Slack and Sqwiggle with the team. For example, Hanno’s team uses Slack to check-in and check-out when they arrive at their working space, but they also use it to communicate about other topics related to client or internal work, and to share fun-related subjects which make the team bond in a more sociable way.
Environments
Hanno’s team is free to work from any location and workspace. Some choose to work from home while others prefer working from coworking spaces or alternate between the two.
Challenges
Although Hanno has built a detailed and efficient structure to collaborate, it still faces some challenges due to the nature of its work and external factors that are beyond its control:
- Discipline and motivations
According to Jon, freedom can be a double-edged sword. Too little of it will make people feel like they have no control over their life but too much of it can make people feel lost. Jon maintains that a strong framework, especially in remote teams, is important to make sure everybody gets the right amount of support and knows what to expect instead of falling apart. - Technology issues
Unreliable internet connections can negatively affect the quality of videoconference calls and online collaboration. - Isolation
For team members who live in more isolated places, it may be harder to network with people to find new clients, exchange ideas or socialise.
Hanno is a relatively new company yet it has managed to create a strong reputation for itself in the creative industry as a successful remote company. Consequently, it represents a best practice example of a remote company, which will be analysed in this research for the benefit of other location independent teams.
6.2 Workshop
In February 2015, I joined a team retreat in Buenos Aires in which Hanno’s team learnt about design thinking with the assistance of Hiong, our design thinking coach.
Hiong prepared a 4-day workshop which I described in detail in my blog. The first two days were focused on understanding the design thinking process and testing it as a team in the same location, and the second two days were used to test the process remotely using online tools.
Understanding design thinking
Prior to the team retreat, Hanno’s team read about the topic but they needed to transition from theory to practice to become more familiar with it. Hiong introduced design thinking as a way to solve problems by understanding the real needs of the people who are affected by the problem. He showed us that this problem-solving approach is a non-linear process that can be simplified in 6 steps:
- Understand the context of the problem
- Observe and interview the people who are affected by the problem
- Analyse and synthesise the information obtained, to outline the main challenge
- Generate ideas by thinking broadly before converging into detailed solutions
- Build prototypes for the chosen solutions
- Test the prototypes with users to get feedback
Steps 4, 5 and 6 are repeated again and again until the best solution is found.
During the first two days, Hiong split us into two teams and gave us paper, sticky notes and pens to help us solve some hypothetical problems. On the first day, the teams spent time framing these problems by using a variety of tools, such as the 5 Whys to get to the root of the problem as well as Empathy Maps and Journey Maps to understand the pain points that users may encounter while interacting with a product or service.
We learnt how to ask users open questions and explored the three main ways of embracing empathy (the ability to understand and share the feelings of another) to understand their needs. This helped us to formulate “How might we” questions and opportunity statements to define the main challenge to solve in each team.
On the second day, Hiong taught us some brainstorming tools to generate ideas and explained that it was important to support each other by building onto each other’s ideas. The aim was to come up with as many ideas as possible (divergent thinking). Once each team had many ideas, they selected the ones which seemed to have the biggest positive impact on the problem and developed them further (convergent thinking).
Each team then created simple prototypes for the ideas they had to test their functions, usability and their underlying concepts. For example, we created prototypes to help guide blind people in an Airbnb house they had just rented and tested these prototypes on ourselves using blindfolds (immersion), watching how other team members coped with our prototypes (observation) and discussing how it felt and what could be improved after the test (conversation).
Applying design thinking remotely
The last two days of the workshop were focused on getting the teams to work from different places, either within the Airbnb house or from MURAL’s office which is located in the same area in Buenos Aires. The aim was to use the same techniques, but this time, to rely upon online tools to solve a problem. Our brief was to “Redesign the remote working experience for teams in a world where people feel isolated and/or disconnected from each other.”
Each team member found a place to work from with their laptop away from the others to recreate a remote environment. We started out by setting up a Slack channel to chat with our team and holding a Skype call to discuss how the team was going to tackle the problem in the time available. Just as we had done on paper and walls the previous two days, we used the same methods to frame the problem on MURAL using virtual post-its.
However, the transition from doing the design process offline to online was slow and complicated. This was mainly due to a slow internet connection and our inexperience with MURAL. The turning point came gradually after both teams learned how to coordinate their verbal communication on Skype calls while also using MURAL to understand what the other team members were doing. It also helped to have an onboarding session facilitated by Emilia, MURAL’s remote collaboration expert, who showed us useful features on the platform, such as adding images and links to a mural, clustering sticky notes and using a built-in voting system to choose ideas to develop further.
After our idea generation phase, each team selected one idea to prototype. The prototypes were tested with users online (using Skype and Slack to share information) or face-to-face with a person in the same physical space as one of the team members. Feedback was shared among the teams online during Skype calls and visualised on virtual empathy maps on MURAL.
Workshop learnings
Although the design thinking process was relatively new to the team and the remote experiment only lasted two days, the workshop gave Hanno a general idea of what it could expect from the process and what it would need to improve before using it in client projects. The main takeaways were:
- Use video and audio applications to communicate as often as possible
- Use text chat to share links and files with the rest of the team
- Explain what you’re doing on MURAL so others can understand
- Give a verbal sign when someone on the team asks for consent: say “yes” or “no” instead of nodding or shaking your head
- Work from a quiet environment to ensure that people on a call can hear you
- Make space for others to contribute during calls
- Embrace time pressure to come up with creative ideas
6.3 Testing
This case study presents a 5-day sprint in which Hanno applied design thinking remotely. It focuses on the process rather than the details or the outcome of the brief.
My role was to document the sprint and help facilitate the team during the design process. The findings are based upon participatory action research, which seeks to improve remote design thinking by producing guidelines for best practice.
The client
Transcense is a startup company based in San Francisco. It developed a mobile app that allows people who are deaf and hard of hearing to follow group conversations in real-time using speech recognition systems that caption speech into text.
The Team
The Hanno team collaborated closely with the CEO (Thibault) and COO (Pieter) of the startup across five different time zones:
- Jon (Kuala Lumpur, GMT +8)
- Matt (London, GMT +1)
- Marcel (Valencia, GMT +2)
- Laïla (Rio de Janeiro, GMT -3)
- Thibault (San Francisco, PDT/GMT -7)
- Pieter (San Francisco, PDT/GMT -7)
The Brief
Transcense needed to improve the way new users interacted with the app. The brief was to rethink the onboarding experience to be as strong as possible. We needed to help the user:
- discover how the app works and clearly understand its purpose
- understand the right way to use the app with others
Pre-sprint preparation
Before the sprint started, Hanno’s team opened a new project on Basecamp to prepare the sprint with the client, created a new folder in Google Drive to share documents with the client, and initiated a new project in Asana to track the project’s progress and assign each other’s tasks related to the sprint. Jon held a pre-sprint Skype call with Thibault to review the app’s biggest design challenges and discuss the sprint’s goals. In the week leading up to the sprint, the brief was discussed in further detail and Transcense shared user research, personas, user journey maps, and UI mockups related to the brief. Meanwhile, Hanno explained how it planned to structure the design thinking sprint and how the team was planning to coordinate its workflow on a day-to-day basis:
- Jon would work primarily alone with only a little time to overlap with the others.
- Matt and Marcel would begin working together in the morning.
- I would join Matt and Marcel online a few hours later and work with them for about 4 hours. We would overlap with the client in San Francisco to have a daily stand-up call, after which I would continue to work alone or together with the client.
Sprint tools and process
During the sprint, the team was continually using Skype, Slack and Google Drive to communicate, share links and understand each others’ ideas. Tools and methods related to design thinking were found on Hanno’s internal design thinking wiki which it has been building over the course of the last few months. Unless stated otherwise, the team used MURAL for all visual thinking and online collaboration.
A daily stand-up call was made with the client at 9am (PDT) to discuss our progress in more detail and ask questions about the project. At the end of each day, a PPP (Plans, Progress and Problems) report was shared with the client to show what the team had achieved so far, what it was planning to achieve the next day and what challenges it had encountered.
Our design thinking process was based on the 6 steps we learnt during our workshop:
Day 1: Understand & Observe
The main aim of the first day was to understand the current context of the app, its purpose and its users. Jon launched the sprint by rewriting the brief and synthesising other research that the client had provided. This information helped us to understand the users’ needs, and we created user scenarios and stakeholder maps to identify how the different types of users would interact with the app.
The team downloaded a beta version of the Transcense app, went through the onboarding experience and tested the app’s functionalities. We mapped out the existing onboarding experience on MURAL and used charetting — a tool used to identify the issues, causes and solutions of our assumptions — to have a better overview of the user journey. We then tried to think more broadly about how the onboarding experience might be like by doing a brainstorming session and discussing our ideas, which was useful to unlock some basic improvements we wanted to implement in the app.
Day 2: Observe & Define
We continued to review the onboarding process and researched other onboarding experiences in similar apps to compare various ways of engaging users. We also continued to create journey maps based on the different scenarios and types of users (deaf/hard of hearing/hearing) that the client had given.
The insights collected over the first two days helped us build an opportunity statement:
“We need to guide the user (whether deaf, hearing, or hard of hearing) through fearlessly holding their first conversation, and scaling up to talking to a group.” We realised that the app’s success would depend on whether users felt confident enough to use it, so we needed to make it as easy as possible to have a great first experience with the app.
Days 3–5: Ideate, Prototype, Test
Once the scope of the problem was redefined, the team began to ideate on specific solutions it could deliver. The solutions were prototyped as mobile app mockups on Google Slides. This enabled us to work quickly and collaboratively, and made it easy to share the prototypes online with users. We wanted users to focus on the user experience (UX) of the mockup rather than the user interface (UI), so we made the UI as simple as possible. This would also allow users to understand that our proposal was still at the conceptual phase and therefore help them feel more comfortable when giving feedback.
Prior to testing, Pieter planned a schedule to test our prototypes with some of the app’s potential users. Our first prototype was tested with a class of deaf and hard of hearing students from the National Technical Institute for the Deaf (NTID) using a group call on Skype. The teacher of the class projected the video conference call on a wall in order to make the screen visible to the entire class. Pieter explained the Transcense app to the teacher who in turn re-explained it to the class using a mixture of speech and sign language. The students were first shown the current app on Pieter’s phone via his webcam and then shown our prototype on Google Slides using Skype’s screen sharing feature. With the teacher’s permission, the team recorded the video call using Ecamm Call Recorder and took notes of the students’ feedback on a Google Doc. Matt was also able to make instant iterations on the prototypes based on what the students said. The students’ feedback was later synthesised in a feedback grid on MURAL.
This user testing process was repeated during 1-on-1 interviews for the remainder of the sprint with both deaf and hard of hearing users. Each interview was conducted by Pieter, who communicated with the users while I recorded the calls and took notes on their feedback after asking for the user’s permission. Although the participants were usually hard of hearing, most of them could hear us with the help of hearing aids. We used a combination of Skype, Transcense and basic sign language (which Pieter and some of the users knew) to communicate during our interviews. After each call, the user’s feedback was collected on MURAL to share with the rest of the team. A few hours later, Jon, Marcel and Matt would iterate on the prototypes while I was away and would share them with me when I came online again. Then Pieter and I tested the new versions with other users.
By the final day, the team had tested 10 prototypes with the help of the client. In our final PPP report, we delivered the links to our prototypes, feedback murals and journey map for a better onboarding experience. Additionally, we listed the next steps that Transcense could take to develop the app further and the features that it still needed to be validate.
6.4 Retrospective
Hanno’s team tracked the difficulties they encountered during the sprint in a Retrospective document. The aim of a retrospective is to understand the challenges involved during a project in order to learn from mistakes and improve the workflow in future projects (Pope-Ruark, 2014). Below are some of the main topics that we discussed:
- Schedule
Since the team did not create a precise schedule before the sprint, it was hard to know when exactly the team was supposed to overlap and what had to be achieved. By the second day, the team started creating a daily schedule each morning to assign tasks and make time for activities necessary for design thinking, such as research, brainstorming and journey mapping. This made the entire process easier to manage and ensured that everyone on the team used their time efficiently, despite the tight schedule. However, it was difficult to plan the day in detail without knowing how people in different time zones would advance on the project when they worked alone. In future, the schedules should provide general outlines to enable people to go into more detail about the tools they plan to use. - Check-ins and check-outs
Check-ins and check-outs are used to let everyone on the team share how they’re feeling when they arrive at or leave work. But this was often forgotten or repeated too frequently due to the various time zones. - Working alone
When people had to work alone, they sometimes felt like they were developing ideas too far without the approval from the rest of the team. - Internet connection
Some people on the team had constant problems with the internet which affected the quality of the calls. Everyone on the team should have ran a speed test before the sprint to check the quality of their connection and made sure they had alternative locations to work from nearby. - Mastering the tools
Although the team had done a 4-day workshop using the tools before the sprint, they still felt insecure about which tools to use in the different stages of the process and were sometimes confused while using the tools. - Online collaboration and communication
Working collaboratively while talking at the same time on Skype for long periods of time could drain the team’s energy. We realised that taking breaks after 20 minutes, or working individually before coming together again, created more momentum and helped to relieve stress in group conversations. - Documentation
I struggled to switch between the multiple links and applications the team was using, perhaps because I was still new to working this way. Bookmarking or having all the links available in a shared document would have helped me to work more quickly. - Stand-up calls
Calls with the client were often too long and inefficient. Ideally, we would have liked to keep calls shorter than 20 minutes and not have more than three people on a call, to make them as short and relevant as possible. Questions for the client could have been added to the PPP and shared with the client before the call to save time. - Working overtime
The user interviews were long, resulting in the team working more hours than planned. The client should be able to hold the interview alone and share the information with the team if a team member’s work day is finished.
6.5 Feedback
After the sprint, I also interviewed the client and the team to discover how they felt about the process.
Transcense
The client was satisfied with the structure and the outcomes of the sprint. Thibault and Pieter enjoyed working with the team and were grateful for being introduced to the design thinking mindset. They found MURAL and Slack useful for collaboration and claimed they would continue to use these tools internally. The daily stand-up calls and the documentation we produced provided an easy way for them to keep track on the progress we made, even though they felt the quantity of documents could have been reduced, and also organised more efficiently in the Google Drive. On the other hand, they would have liked to see more prototypes and variations. Overall they learnt more about their users by using rapid prototyping and testing than they would have done using previous, less rapid approaches. They suggested doing a final wrap-up call with a reflection about the project at end of the sprint. The client did not refer to the complexities of the process, perhaps because they were mainly collaborating with the team in the final stages of the process.
Hanno
The entire team agreed that the transition from their usual linear workflow to a non-linear process had been frustrating at first, especially when they experimented with it during their 4-day workshop in Buenos Aires. They claimed this was due to their unfamiliarity with the tools and the technical issues caused by a poor internet connection. During the sprint, the most challenging part for Matt and Marcel was delivering the first prototype in a short amount of time and testing it even though they felt it was unfinished. However, their stress was overcome as soon as they saw how users engaged with it and the kind of positive impact that Transcense could have in the lives of their users.
All team members stated that they would like to improve the sprint’s structure with a schedule that gives an overview of which tools to use in the different phases of the design thinking process in order to make them work more efficiently. They also agreed that the most frustrating problem was not the process itself but finding a reliable internet connection.
Overall, the team felt motivated and inspired by the design thinking approach because it allowed them to try new things beyond their usual skills and made them understand problems better by connecting with users’ needs and emotions. Jon noted that the process made them think about problems in more detail and the team came up with more developed solutions than they had ever done in their previous projects, so they will continue to use it in future sprints.
References
Bright Hub PM (2012) Project Management Methodologies Comparison: Pros And Cons Of Various PM Methods. [Online] Available at: http://www.brighthubpm.com/methods-strategies/67087-project-management-methodologies-how-do-they-compare/ [Accessed: 24 January, 2015]
Moe N.B., Dingsøyr T., Dybå T. (2010) A Teamwork Model For Understanding An Agile Team: A Case Study Of A Scrum Project. Information and Software Technology, 52(5) pp. 480–491
Murphy C. (2004) Agile, Multidisciplinary Teamwork. Methods & Tools, 12(4), pp. 10–22
Pope-Ruark R. (2014) Introducing Agile Project Management Strategies In Technical And Professional Communication Courses. Journal of Business and Technical Communication, 29(1), pp. 112–133
Interviews
Doevendans P. (2015) COO. Transcense. [2 April, 2015]
Duchemin T. (2015) CEO. Transcense. [1 April, 2015]
Lay J. (2015) Founder. Hanno. [19 January, 2015; 1 April, 2015]
Lenzi M. (2015) Designer. Hanno. [3 April, 2015]
Kalveram M. (2015) Designer. Hanno. [1 April, 2015]
