We Need it Yesterday!
Sometimes feature requests come in with a deadline of yesterday. At an early stage startup sometimes turns into often. As the sole designer, parsing these requests and moving them from ideation through research, planning, designing, testing, tweaking and deployment post-haste means cutting corners here and there. The tricky part is knowing when and how to trim the fat. While it may not have been ideal, here’s the process the Opus team went through to ship a small but important Refer-A-Friend feature in record time without throwing all process out the window.
The Ask:
“Create a feature that allows our users (professionally gigging musicians) to invite their friends and colleagues to create an account on our fledgling platform with as little effort as possible while maintaining a feeling of exclusivity (the functionality was to coincide with our move to a closed network growth strategy) and our semi casual brand voice. In a few days.”
Getting Started:
The first step in the process was to validate the need for the feature with a few of our early adopters and community managers before spending any time moving forward. We accomplished this by conducting a quick survey distributed through one of our mailing lists. After getting positive feedback the team decided to move forward.
Initial Research:
To kick off our actual research phase, the team looked to other products implementing referral functionality and/or closed networks to analyze what they were doing well and where we might be able to improve upon the experience. We supplemented this exploratory research by conducting in-depth interviews with a small group of early adopters. The interviews were focused on gaining insight into how our users would utilize the new referral functionality. Some of the most insightful discussion topics included which communication channels they would use to distribute invites, their selection process when sharing invites and how a referral bonus might affect their use of the feature.
Planning:
After organizing the results of our research we were able to compile a rough list of requirements for our new Refer-A-Friend feature. Here’s what the breakdown looked like:
- A process that took as little effort and interaction as possible to complete
- A way to easily keep track of remaining invites
- The ability to send invites via email or sms
- A way for users to request more invites from the Opus team once they ran out.
- A method for sending multiple invites at once
We also came up with two internal requirements focused on the ease of development and minimizing cost:
- Utilize existing componentry from our design system
- Apply existing functionality/infrastructure for the implementation
*Note: While a referral bonus repeatedly came up in both external research and internal discussion, we decided to experiment with the effect the closed network would have on growth before determining a referral bonus system.
Design:
Once we had a finalized list of feature requirements we began outlining a user flow for our new feature. The team broke out the graph paper and markers and began sketching. The final result was a simple sketch displaying each step and interaction needed to complete the invite process.
This was reviewed with the dev lead on the project to ensure that the functionality we had discussed earlier could indeed be implemented while adhering to our internal requirement of using existing functionality and infrastructure.
Finally we were able to take our user flow and move directly into designing comps — remember when I mentioned cutting corners? Since the end to end flow of our feature was straightforward and our goal was to use existing componentry, we elected to save time and skip wireframing. Opting to instead create a final prototype to take back to our users for additional testing.
This extra round of testing resulted in some last minute updates that made it into the final shipped version of our feature:
- Increasing the number of invites initially allocated to each user
- Moving from share via SMS to a unique URL that could be copy and pasted into any messenger (we had underestimated the number of users heavily using messaging apps like FB messenger, wechat and whatsapp)
*Note: the decision to move away from SMS also allowed us to avoid the extra cost of implementing an SMS integration and kept us aligned with our goal of using existing functionality
The final comp handed off to the dev team looked like this:
Wrapping Up:
After handing the final comps off to dev we quickly shifted our attention to planning the feature rollout and assisting with QA. After some internal discussion the rollout plan looked something like this:
- Quietly push the new refer functionality to production and monitor usage for a week or so to ensure any kinks were worked out before sharing with the community
- Schedule a larger announcement via email campaign
- Have the release coincide with updates to the opuslive.io landing page and the switch to a closed network in early December.
Reflecting:
Now that we’ve had a second to catch our breath a bit, we can look back on what we did right, what fell short, and what we can do better next time:
What went right:
We feel we were able to accurately judge which corners were ok to cut. Skipping wireframes gave us the time to conduct an additional round of user testing that identified some gaps we were able to close before shipping. This is a testament to the value of design systems even when operating at a small scale. Being able to cut down the time it takes to prototype in higher fidelity can make a world of difference.
Where we fell short:
We were unable to complete some of the internal and external requirements of the feature. Specifically, minimizing the interactions needed to complete the task and using only existing components and functionality/infrastructure. Adding the popup modal to inform users they were out of invites was not part of our existing componentry. That being said, now that we have it documented, it’s been added to the arsenal for next time.
Along the same lines as the modal, moving away from SMS as an alternative method of sharing an invite resulted in adding the ability to copy a link on button click/tap and added an extra step to share a user’s unique invite link. Either direction taken here would have resulted in a new implementation. Our solution ended up being cost effective when compared to implementing a way to share via SMS, but we should have identified this sticking point earlier on by communicating our intended functionality with engineering better.
What we can do better:
Training other team members so they can step in and lend a hand if need be. Having some plug and play scripts in place to fall back on when conducting user research would have been awesome. The team was stretched pretty thin while trying to complete this ask and as a result other priorities needed to be adjusted. Being able to recruit other team members to assist with some of the research would have freed up time to spend on other aspects of the process. We were luckily able to catch the last minute feedback regarding the invite allotment and SMS sharing, but we easily could have missed it and shipped a feature that missed some of our user’s needs and incurred additional unnecessary costs.
tl;dr:
For anyone who jumped to the bottom of the page, here’s the cliffsnotes version of our process outlined above:
The Ask:
Create a refer-a-friend feature with as little interaction as possible while maintaining a feeling of exclusivity (aligned with business goals) and semi-casual tone of brand voice.
Step1: Validate if new feature is actually needed/desired by users
Step2: After validating, conduct research on similar functionality present in other products and gain insight into how target audience will use the new feature via user interviews
Step 3: Take the research results and create requirements list for the feature
Step 4: Start sketching user flows and determine which to move forward with
Step 5: Get the ok from dev that all functionality can be implemented
Step 6: Skip wires and go right to designing comps because flow is straightforward and uses existing componentry
Step 7: Test rough prototype with a few targeted users and quickly iterate based off feedback
Step 8: Quietly ship with little fanfare to get everything battle-tested
Step 9: Plan official announcement of new feature
Step 10: Catch breath and reflect on what went wrong, what went right and what we can do better next time (aka write case study)
