In a fast paced programme where rolling out features to eager customers is of utmost importance, the experience improvements that a design team want to make, might not be perceived to be significant enough to warrant time. Product management success is measured by the features PMs ship and not by the experience those features provide. That's the experience design team's job. Now, if only the team had the time...
In my previous programme, where I was designing experiences for smart homes, the design team realized, with much concern, that feature development was always top priority. For good reason too – the smart home market is very competitive and technology companies dish out features like coins falling out of a slot machine. To stay relevant, we kept designing new features that fulfilled customers' expectations of a smart home; but that meant that the experience debt that we had inherited along the way was only growing.
What are these experience gaps and why do they occur?
Every time a new product or feature was being designed, we were compelled to introduce new components and experience guidelines to the design system. Existing paradigms didn't serve well once the number of product types grew and tasks got more complicated. New icons, buttons and illustrations had to be crafted and new copy had to be written. What this led to was inconsistencies in visual elements such as icons, typography, spacing etc. There was also the issue of bloated code, which resulted in larger app size, slower performance and regrettably, app crashes on some older phones.
Although customers were not complaining too much about the experience (app ratings ranged between 3.8 to 4.1), the design team was always pressing our good product owners to carve out time for the changes they wanted to make in every release. If they were given an opportunity to rate the app experience, I fear the ratings would be much lower :)
Enter the development team's challenges. Developers were delivering code and testing new features so that the implemented solution would function, look and feel as specified in the design documentation to the best of their ability. Since smart home technology is still not completely predictable, what got built didn't always meet expectations. This led to iterations in design and code, which resulted in time slips and not to mention, frustration all around. In this scenario, it was difficult to convince developers to take up additional work, especially time consuming changes, as a part of their release.
How could we overcome these issues in our agile delivery process so that we could help the app experience become better?
Our inspiration was hackathons! We modified the hackathon format to suit our requirements and called them Hack sessions. They have proved to be an extremely useful instrument for better product delivery. Till my time in the programme, we had completed 5 Hack Sessions. With every new event, we worked to eradicate those much hated inconsistencies and experience bugs.
What is a Hack session?
The Hack session is a 2 day work mode where known issues in the app experience are taken up as a challenge and solved in the stipulated timeframe. These issues are small, achievable tasks (things like updating icons and copy, fixing alignment and spacing, cleaning of code, etc.) jointly agreed by the design, product and development teams. Depending on the effort, 2-3 devs and designers would concentrate their efforts to overcome these visual and experience issues over two days. The idea was to be hyper agile – identify the gaps, prepare the design assets, build solutions and test them within two days.
An anecdote about a Hack session
The challenge that was set for the first Hack session was a deep thorn in our flesh. We had replaced the font from Verdana to Noto Sans in the app without fully understanding the repercussions. The font scale that had been defined considering Verdana was not suited to Noto Sans and that had led to issues like truncated text, uneven spaces and unpleasant typography. So the task at hand was to define a new scale, apply it across the app and end the session with a visual check. On the first day, a visual designer and UI developer got together over a call to standardize the font sizes across the app. There was excitement and energy and the day ended with the team achieving one milestone in their challenge. The excitement lasted till the time we began VQA (Visual Quality Assurance) on the next day. Even though the standardisation had worked for the Roman script, we discovered that there was more to be done when other language scripts were considered. This could not be ignored since the system was being used in around 52 countries. The optimistic team attempted to solve this overlooked issue in the few hours left but we knew that there was no way the task could be completed in time.
Because we believed that the Hack session was still a good idea, we decided to take responsibility of the situation and report the roadblock. We also asked the leadership team and scrum master for additional time to complete the hack task. This was not an easy ask since there were stories already planned for the team in the sprint.
Placing trust in the team's capabilities, the scrum masters and PMs decided to let the team spare some time to complete their challenge along with their assigned stories in the next few days.
By deploying the changes in the sprint build in the next few days, the team accomplished their goal. At the end of the sprint, the results were presented to the larger team. There was applause all around because there was a noticeable difference in the visual experience of the app. Better type hierarchy and good spacing made the user experience feel more polished and premium.
The frequency of the hack sessions increased from one session in two months to one session per month once their efficacy became apparent. Product owners appreciated that the product experience was steadily getting more unified in a short period of time. The design team's wish of addressing the long overdue experience debt was coming true as there was noticeable change in the user experience after each hack session. This outcome not only encouraged us to continue doing such hack sessions, but also explore more opportunities to improve digital product delivery.
Since we were building the rails as we run the train with these Hack sessions, we did run into more problems in the following hack sessions too but we kept getting better over time. Here are some key learnings:
Plan the challenges well in advance. The tech and design leadership must take into account all the possible failure scenarios during the planning phase so that the implementation team won't suffer setbacks during the event. It might happen that the people who set the challenges might not be available to answer questions during the session, so the requirements and expected outcomes must be specified in a detailed, understandable manner.
Maintain the hype around the event. Make a ceremony out of it. Let participants showcase their achievements to everyone and be recognised for it. It helped us establish this practice and get buy in from the powers that be to do more.
Time box the event but keep in mind that it is not meant to be extremely competitive. There might be some scope creep and failures and that's ok. Participants enjoy the rush of working closely together towards a common goal in a race against time. Team optimism is more important here.
Be cautious to select participants who are not already stressed or load them with other work. Overworked participants don't perform well and will eventually bring down morale of the others involved in the event.
Design can be used to not only think about the end user experience, but also about how teams can be made to think and act in ways that assist a user-friendly outcome. To learn more about my experience with hack sessions and how to integrate them into your agile delivery process, feel free to reach out.