Designing Nudges @Cuddle.ai — Part I
One of the first high impact projects I worked on as a product designer in Cuddle was designing a feature called Nudges. This was the project that helped me learn the most crucial and important principles as a designer — because it failed, miserably. And as they say, failure can be your biggest motivator and teacher.
In this 2 part article series, I have written my journey from the inception of this project, to its end and throughout the course of these articles I have highlighted the reasons because of which it failed — I believe these lessons will help you in avoiding the same mistakes we did, so that you can carefully design your next big project.
Part I, covers how we identified the problem and finalised a solution direction.
Part II, covers how we designed the solution and measured our success (or faliure?)
This article is part I in the series and it covers how we identified the problem and the right solution direction for our project.
Identifying the problem
Let me start by giving you a little context. One of the features we had in Cuddle was Diagnostics. Diagnostics are notifications that Cuddle sends to a user when it finds anomalies or patterns in the data. There are 4 types of diagnostic notifications that Cuddle generates.
Here lies the complexity, the way Cuddle used to send these notifications was — if you have tracked any data(think of it like adding any data in your dashboard) Cuddle will run diagnostics only on that data. So essentially, to get diagnostics notifications you would have to add your data to your trackboard (Cuddle’s dashboard). Well this was the problem, we wanted to make this experience seamless for a user and decouple it from the trackboards — comes Nudges.
So, we named this project as — Trigger Criteria — the criteria that would generate these diagnostics notifications for a user.
Well, this was a big change because diagnostics was one of the most sought out features by our clients and users and it had been this way since the inception of the company.
To change such a feature, it was important to get all the stakeholders, including the CEO, CTO, marketing people, product managers, designers, engineers, data scientists, sales people, together on the same page. What do you do when you want to achieve this? — comes in Design Sprint.
Conducting a day-long design sprint
To get all of the stakeholders on the same page and align them on the problem we were trying to solve and to come to a common solution direction we conducted a design sprint. Some of us had been a part of the design sprint before and for some, it was the first time. Because Amit Das, has conducted a few design sprints before and has been a part of Google design sprint workshop, he guided the sprint for us. If you want to know more about how to conduct a design sprint you can read about it here.
Because our team works remotely, some were in the US, some in Bangalore and others in Mumbai we used a combination of digital collaboration tools (Lifesize, Miro, etc) to conduct this sprint.
Here’s how our sprint process looked like.
Duration: 7 hours
Constraints: No mobile phones allowed
Step 1: Writing down big questions/ideas related to the project
Step 2: Voting and shortlisting one or two ideas/points that most people resonate with
Step 3: Making a flow chart of potential solution direction
Step 4: How might we — Individually listing down solutions for different touchpoints in the flow finalised above
Step 5: Voting and shortlisting the solutions
Step 6: Crazy 8s — drawing wireframes for the solution
Step 7: Crazy 8s II— drawing wireframes for the solution
Step 8: Forming ideas from the most voted solutions above
After doing this exercise we successfully reached a stage where we identified what we wanted to solve for and got all of the different stakeholders on the same page.
Deciding a solution direction
The solution we decided upon was to explicitly ask the user for his interest areas and then deliver him diagnostics notifications, rather than the implicit tracking approach we had before. This would make the experience explicit and in control of the user.
Now there were 2 approaches to design this solution. Either we can ask for the explicit user interest input when user logs in to the app for the first time or we can take his inputs at different touchpoints while he is using the app. Because we had 2 different potential approaches to the solution with different levels of impact on the product, we created 2 IA diagrams in whimsical and again took inputs from all the stakeholders mentioned above to finalise the solution direction.
I can understand you might not be able to comprehend what’s in the images above, but what the heck, IA’s are cool to show-off 😛
So after a lot of back and forth meetings and discussions with 10 people from different perspectives, we decided to go ahead with case B above — that we will take explicit inputs from the user on his interest areas at different touchpoints while he is using the app.
1st Reason for failure
Even though we had decided the solution direction after the design sprint, we kept all the stakeholders in the loop while deciding the final IA. This led to a lot of back and forth meetings for a span of about a week, since not all were available together and the decisions kept on changing due to multiple viewpoints.
Lesson learned: only involve people who are required to make the decision, this will lead to fewer viewpoints and lesser meetings, thus more productivity and saving of time. And also, be very specific about the kind of input you want from a particular stakeholder. For example, on deciding the IA we should not have got the data scientist in loop, it is a job of product managers, designers and engineers.
You can read how we designed the above solution in the next article.
Hope you learned something new!