A co-design workshop for UX awareness
Summary
From March to August 2020 I was a UX Design Intern at an online mental health platform. My role was to provide interface designs for the development team, a task in which I noticed some usability issues and found it difficult to understand the strategy driving the design decisions.
In a search for more information, I decided to investigate the product development process. While it started as a way to improve my own work, I ended up discovering a few challenges related to the absence of an iterative process, communication, testing, and end-user involvement.
To try and solve those findings, the Design Sprint Pilot was used to improve communication, spot usability issues, and increase UX awareness. Together with the project manager, we defined the sprint goals, squad, and framework adjustments within a tight deadline of 3 business-day planning.
Discovery
The business was building from scratch a second version of its original product to achieve higher customer satisfaction rates. The product release faced delay issues and operated without the support of a UX team since April 2020.
The business had some UX awareness, but not enough to adopt its process entirely. Practices such as user research and usability testing were performed without a clear strategy, which created three main challenges:
- Inconsistent (user) research, validation and documentation
- Large UX debt
- Product strategy & scope understood differently by each team
There was a common aspiration to involve end-users more often, but the UX Design process wasn't applied mostly due to:
- Budget (“it’s too expensive, we need to prioritize developer hours”)
- Time (“it takes too long, we can’t miss another deadline”)
- Relevance (“we have enough information to go ahead”)
A lot of companies struggle to incorporate design methods because the methodology doesn’t always consider organizational culture. With that in mind, I did a Listening Tour, an Empathy Map and a Development Process Blueprint to understand their way of working and causes for limitation.
With the Listening Tour and Empathy Map I learned that while there was a determination to improve usability and be more human-centered, there was a difficulty in understanding the different roles under the UX umbrella. The iterative & user-centered methods seemed too complex, and their benefits too abstract. In the absence of an experienced UX team, any project or changes to the process were too risky to take. Each team was very knowledgeable, but the interaction between those teams was limited.
Mapping the product development process
The development team worked in 3-week sprints, prioritizing tasks based on product owners requests, while stakeholders were the final approvers of the product. However, stakeholders' feedback was given at the end of the sprints, when the solutions were already coded. End-users were rarely part of the process, and although their feedback was collected regularly there wasn't a strategy to investigate them.
The process had well-defined roles and steps, but it didn’t involve end-users and didn’t take into account validation steps. This resulted in a mixed understanding of the product scope, as well as mismatched expectations — which created additional re-work hours on the development side.
How might we speed up the development process while increasing usability?
It was common to discover in the feedback sessions that the final result was different from the product vision, along with usability issues. These findings would either be left unaddressed (increasing UX Debt) or become unplanned refactoring tasks to the next sprint (increasing the project delay).
A first step to break this cycle would be to present prototypes in feedback sessions before heading off to coding. By critiquing a prototype, any identified issues could be fixed in the designs before the start of a new development sprint. With this in mind, a Design Sprint seemed to be a good option for rapidly prototyping.
The Design Sprint also made it possible to shape a collective product vision— enabling the collaboration between teams that are involved in the project but don't typically work together, such as the help center and IT.
The Design Sprint Pilot Strategy
In mid-May an opportunity window opened up for a pilot session: a target-team was being formed to develop a new product, which was a good scenario to do the Design Sprint and present a prototype in the stakeholder feedback session scheduled for the next week. On the other hand, this gave the challenging preparation time of three working days.
Sprint Goals
Although having studied the method and joined sessions in the past as a participant, it would be my first time facilitating a Design Sprint. Luckily, it was also the first time the company was considering hosting one, so we could all learn from it together. The three main goals were:
- Present the prototype of this new product at the next feedback session
- Learn from an experimental process
- Increase UX awareness
The Team
The Project Manager arranged the logistics and other approvals (inviting people, getting the go-ahead from management, planning the upcoming feedback session, setting up meeting links) in order for me to be able to handle the strategy and facilitation, focusing on tailoring the agenda to meet the business needs and resources.
It was crucial to have the perspective of both users' needs and business goals, as well as technical feasibility. We also wanted to focus on collaboration, knowledge sharing, and internal alignment. With that in mind, the Design Sprint Team consisted of:
- Account Management, Help Desk & Content (direct contact with of end-users)
- Innovation & Sales (business goals and market strategy)
- Development (tech capacity and feasibility)
Challenges & Adjustments
1. Going fully remote:
Meeting in person was not possible due to the pandemic, so all sessions were done remotely. We used Google Meets for video and a Miro whiteboard (we planned 10 minutes of the kick-off session to let attendees learn how to use it). We used, with our own adjustments, the Virtual 4-Day Design Sprint Template from Just Mad.
2. Using proto-personas:
User research wasn't readily available, so we took the most recent insights (from internal and external sources) to create proto-personas, and used them as a reference and contextualization tool during the week.
3. User interviews after the Design Sprint
Not only was the recruitment of end-users a complex process that required about 2 weeks of planning (primary end-users were health care workers), the fact that this was a pilot made unclear how much they would actually benefit from joining.
The business was also concerned about how their customers' perception of the company would be impacted if they participated in something we were doing for the first time. So it was decided not to invite end-users, and instead use the customer-facing team members to represent their needs as much as possible.
4. Usability tests after prototype approval
As mentioned earlier in the article, one of the company's challenges was having different expectations of the product, leading up to delays and re-work. To avoid iteration redundancies, we opted to get prototype approval before arranging usability tests with end-users.
4. Fitting the agenda to a regular workweek:
Removing staff from their tasks for four full days wasn’t financially sustainable at that point. We also assumed that the team would be more willing to participate if they didn’t have to do “extra” work such as sketching and presenting.
For those reasons, the regular day-long sessions were broken down into half-day activities, scheduled in between a regular work week. We also removed some exercises from the team's agenda and turned them into "designer tasks" assigned only to me.
The outcome of the adjustments
Although not as accurate as a typical persona, the proto-personas helped the team broaden their understanding of people who use the platform and the complexity of their needs. It made it possible to identify secondary end-users and how each of them influenced the other. We went from considering only the main end-users’ perspectives to including the peripheral end-users (the end-users clients, managers, and assistants).
We noticed how much we could have learned from having end-users during the sprint, so we suggested to have invited them next time. Also, their perspective was missed by the whole squad, so discussions about testing and interviewing them began to happen more often.
By presenting an untested prototype, it was possible to visualize major information gaps that needed to be filled before heading off to coding — and how this would be a timesaver for development. It quantified the risks of not validating assumptions with the people who use the product and the cost-saving impact of investing in cross-team alignment.
Having the sessions split through a regular week impacted the momentum of the group, and we ended the Design Sprint week feeling that full-day sessions would actually be better. By contrast, it became clear to all involved that the outcomes of this first try were good, and with more preparation and time, it could be even better. It was a key element to gain further support for UX.
Results
At the end of the week, we presented a low-fidelity prototype of the product, which covered a complete ideal flow of two different end-users. It was possible to capture some of the non-digital elements of the users' experience in the solution, a significant change from the usual product discussions.
Due to time, staff, and financial constraints, research, usability testing, and end-users participation didn’t become a part of the process (but would eventually be addressed by the UX team who joined in August). On the other hand, we were able to adopt the habit of designing user flows before designing the UI — which improved the understanding of the product behavior and the definition of users’ interaction with it.
The target team and I were able to work along regularly after the Design Sprint. This allowed us to check issues and questions more quickly, easily identifying what problems could be solved within the team, and what should be checked with the product owner — ultimately adding speed to the project and increasing the frequency of internal feedback on the product itself.
Business Impact
In the following weeks, I noticed developers being more active in raising usability concerns, as well as other teams asking user-centered questions more often:
“Will this work in a tablet? Our end-users use tablets when working from home. Do we have a solution for when they lose connection?”
Instilling empathy, getting buy-in for new experiments, and UX being seen as valuable expertise were important building blocks to a human-centered mindset.
Conclusion
Understanding a business and the people behind it was essential to be able to advocate for the users' best interest realistically. In the same way, people have different needs, companies do too — and what might work well for one place might not be the best approach to another.
UX Design is a collective and consistent effort, and so it is important to share expertise between areas. I found that actively seeking to co-create with colleagues helped me, personally, to learn how to use limitations to think creatively and prioritize efforts.
