Referrals are an excellent source for scaling products and gaining a new user base. If designed correctly, it can provide a much-needed thrust to product adoption. At Gartner Peer Insight, we had a referral program that was working to an extent but marred with few issues like lack of transparency, missed referral tracking, a lesser percentage in overall review growth, etc. Based on the quantitative data around user engagement, we decided to improve our users' referral experience. The task was to increase active referrers by 50% and increase the share of reviews from referrals by 50%.
Think of a time when you were making your first smartphone purchase. You probably compared screen size, battery performance, budget, OS features, color, etc., reading through all possible online reviews about the product. In the end, you probably wanted to make sure that you are making the right decision and getting value for your money.
Now imagine a situation where you are responsible for purchasing a multi-million dollar enterprise software product. You would try to gather all the possible information through your closed network or the research you could do in general. Gartner Peer Insights solves this problem by invoking the technology professionals' experience for a particular product or vendor in the form of reviews and ratings. This platform's strength lies in a strong community of enterprise professionals who contribute with their experience and unbiased opinions, which helps thousands of similar professionals decide on software purchases with confidence.
Since Peer Insights is a network of like-minded people sharing their experience about vendor products, it is imperative to grow this community to leverage the network effect, which is a phenomenon where an increased number of people or participants improve service value. Through referrals, we wanted to tap into our user's professional network and allow them to bring in another set of expertise through the source they trust.
A solid design strategy acts as your guiding pillar when so many parts are moving altogether. As a lead designer, I had to frame a design strategy that could allow geographically distributed teams (based in North America, India) to simultaneously participate in problem-solving sessions. Going with the design sprint model was an obvious choice. However, I tweaked the design sprint model slightly to accommodate the time overlap. Instead of facilitating a long 8-hour session for five straight days, I facilitated a 2-hour session daily three days a week.
Splitting our time in a daily 2-hour window allowed teams to tackle one challenge and create a window to retrospect the previous day's contributions.
Once we decided on our focus area, "Referral Journey, " we started defining the work scope to be done to deliver this experience in production. Overall, splitting the product development effort into three parts - Design Sprint Phase, Development Sprint Phase, and Quality Assurance + Iteration Phase.
I published a design sprint calendar for my stakeholders so that they have a chance to get involved or raise a flag if the timelines seem a little off. Publishing a sprint calendar or timeline helps you establish trust with your stakeholders early in the process and provides an opportunity to make them aware of design thinking process.
To gain a better perspective on the user pain points, we identified 20+ users who referred others in last 1 month and scheduled 1-1 interview sessions with them. Its always better to have some buffer when you are scheduling user interviews. At last, we ended up having ~10 one-to-one discussions.
Qualitative research is just one aspect of your entire user research process. You also need to observe patterns of user enaggemnets through site analytics (Heap, Google Analytics, etc).
A successful design sprint depends upon the equal enthusiastic participation from all the relevant stakeholders. I observed that not everyone is on the same page when it comes to understanding of the design sprint framework or the step by step process involved in problem solvin phase. There, I decided to conduct a formal 45min - 1hr light training session that talks about the details of design sprint framework.
Due to this sprint's remote nature, I managed to get stakeholders time in parts spread over the entire week for a problem-solving session. I facilitated the following activities during the problem-solving phase:
The good thing about the design sprint framework is that it provides equal opportunity in every solution identification phase. As part of this phase, I conducted sessions for Crazy 8, Lightning Talk, Ideation. We validated designs with 3-4 users to get first-hand feedback on areas to improve during the sprint's last stage.
Design handoff to developers is an essential step in the product development process. The design assets you will deliver to your development team will become their real source for front end implementation. Any further iteration on design or change in the message should reflect in those design assets.
I use a combination of tools for the design handoff process - UI Styleguide on Zeplin, Assets + Prototype on Invision.
After all the hard work of over two months, we released this feature to or 10% user base. Once we ensure proper user adoption, we decided to roll it off to the entire user base. In some geographies, we managed to achieve 130% MoM rise in referrals.
When it comes to a design sprint, there is a possibility that things will not happen by the book. You have to account for the constraints and variability that comes with time schedules. If bringing everyone together is impossible, try to mix and match offline/online activities together. Identify the right stakeholder using the RACI framework. Test and learn from user groups and get feedback early in the process.