This is a little look into our journey of helping to build sustainable cities and communities in Southeast Asia...
The first image that comes to your mind when you read "Design Thinking" is probably a team gathered in a room actively ideating while sticking post-its on the board. That's not too far from the truth - well, before 2020 at least.
In our previous Learning in Public post, I covered how we went about our User Discovery process over a few weeks amidst the pandemic. So what happens after the interviews are done and broad insights are drawn?
Jump into ideation? Nope. We're not done with understanding our users.
Interviewing =/= Empathising
The interviewing process provides an invaluable direct touchpoint with the users and helps draw out common themes. However, interviewing only kickstarts the empathy process.
It can be deceiving to take the next step in ideating thinking we have done the legwork of speaking. More often than not, doing so can lead to:
Having too broad a problem area to work on
Team members having different interpretations of the same problem area
Ideating on a general problem statement
Having little hypothesis-driven metrics to test and make decisions
Instead of skipping to ideation, we used the persona that we generated previously. We focused on ensuring that our entire team was aligned on the pain points and the user narrative. A helpful tool that enabled this was Storyboarding.
Conventionally, this process is done in person. However, since our team was working remotely amidst the COVID-19 restrictions, we faced the added challenge of bringing the working environment online.
The solution to that was much more straightforward than I anticipated. We used Google Slides. And it was pretty effective.
Persona Statements
Here's how we dug deeper into the empathising process.
First, we gathered the team online and presented (in detail) the persona profile and our key insights from them.
The team members each took a slide with a persona statement template assigned to them to map out their own individual understanding of the persona.
Our developers also made the process really fun. Don't take my word for it. See it for yourself.
Once we were done, we went through each individual's slide and the team upvoted the statements they resonated with using the green arrows on the page. This was tremendously helpful in 4 aspects:
The arrows visually represented the elements that the team resonated with
Specific statements allowed for clarification and greater alignment
The specificity enabled the team to test certain assumptions more directly
It was engaging since everyone could participate despite it being online
User Epics
Once we have gone through each person's interpretation of the persona pain points, we consolidated the statements into the main themes (funding, incubation, community, knowledge).
We then started storyboarding. Storyboarding is very common in the arts and film community as it helps visualise the narrative flow of a sequence of events. Many software product teams have also adopted the tool to storyboard the user journey.
Storyboarding at the persona discovery stage allows us to:
Put ourselves in the shoes of the user - creating a greater sense of connection
Better map the user journey
Understand the envisioned change that our product can bring
Once again, Google Slides came in really handy to facilitate this process online. Here's the template that we used in our team! The overarching narrative (also known as the User Epic) takes a specific persona statement from above and describes the Current Scenario in a [Trigger, Action, Outcome] format and the Proposed Scenario with the same trigger but a different outcome.
In our case, the High Priority Narratives were used to outline a story of some features that will help achieve the desired outcome in the proposed scenario. The Low Priority Narratives are stories with features that would be good to have.
Here were some cool things that came in handy:
The text boxes acted as "post-its" and could be moved very easily
We were able to leave our comments directly on the post-its for future reference
Multiple people could work on their individual narrative and then contribute to the work of others seamlessly
There are some online tools like Storyboard That, which allow you to do more detailed storyboarding involving people. I chose to go ahead with Google Slides for the flexibility, and the comments feature for future reference.
Consolidation
After storyboarding, we took a few days to "digest" what we have learnt and to really let the narratives and persona statements sink in. The team came back with clarifying questions for the next meeting, which improved the collective understanding of the pain points we were tackling. There was also a familiar sense of comfort when we returned to the storyboards.
This was when we knew we were ready to move on to ideation and prototyping. Having broken down the user profile into specific persona statements and creating user narratives to understand their current challenges and how our product could help overcome these challenges, the team had plenty of opportunities to get into and clarify the specifics.
Converting User Epics to Sprints
These same narratives and associated features were eventually shifted to our Trello board we use for DevOps sprints. We have a User Epics backlog. Each core feature is associated with achieving a specific user narrative (which is why the user epic card is always on the top of each in-progress feature). Here's a peek into how we organise our board:
This process turned out to be a great investment of time. Having the entire team buy into the problem paid off well into the future. Our developers actively ask whether certain features are essential to achieve a particular narrative or if certain features are lacking.
I wish we involved more than the product team in this process as it would have helped everyone, including those working on resources and content, understand the core needs and user narratives that we are building towards.
Now, whenever we have new team members joining us, I'm making it a point to go through this part of the process with them to allow them to understand the user first and underline the purpose behind our work. It's heartening to see the product team take ownership of the pain points and not lose sight of why we are building our community platform.
It turns out that we don't need a board with post-its to achieve team and empathy alignment with the user after all!
P.S. Here is an excellent online course on Digital Product Management that I have personally taken and the related course materials (open access) which can help those interested in the design thinking process!
Hope this helps you get attached to the problems of your users and not your solutions. Let's help build the sustainable society of our dreams!
Want to be a part of a sustainability community for founders and talents? Check out our platform for founders and talents!