Throughout the first part of 2016, I spearheaded the redesign of Whistle's on boarding as part of an overall app redesign effort by the team. The redesign was self-guided and was in addition to over a dozen other projects in parallel. I thought I'd detail the process and share what I learned along the way.
Just a heads up! This design hasn't been publicly unveiled yet. Everything shared below is in good faith as an example of my process, and as a starting point for anyone else who might be tackling a similar task with little to no direction.
The Problem, Scope, and Requirements
The old Setup & On-Boarding process contained too many screens (showing the first 5 of 20-ish above), was confusing, and wasn't optimized for the expanded vision of the product. It didn't scale well with multiple product offerings, and it had drop-off rates we wanted to turn around. The process also didn't feel "Whistle'y" enough, and was devoid of our cherished brand voice. We can do better.
I defined the problem as the setup process missing 3 key marks:
- Time - The process took too long to complete, and had way too many steps.
- Usability - The process was difficult to complete, which directly impacted the business.
- Cohesion - The process felt distinctly sterile compared to the rest of the app.
The scope of the redesign covered the creation of a user account and a pet profile, at minimum. Optionally, it could include additional account or device-related screens.
The requirements included things like gathering a user's email, password, key pet metrics, and a number of other similar factors. Experiential requirements included maintaining the brand tone and feel, not feeling cumbersome, and creating a memorable first-impression of the product.
Because the team was so small, I had to jump into the foundational research solo. I've detailed the research behind this redesign here, on Medium. The research process was informed by analyzing user-research the team had done, creating a doc of synthesized findings, and mapping the key findings to the 3 parts of the problem.
From there, I started asking "how" and "why". I managed to find a number of studies and examples, linked in my Medium article, that helped to lay a directional foundation for planning the redesign.
Concepts & Iterations
From the research, I sketched out a first-take on a basic flow (a few screen states shown above). It was a starting point for iterations, and it allowed me to break free from the 3 pages of research links I had been compiling. This first conceptual take on the flow revealed a few opportunities to optimize individual components - such as form labels, which ended up becoming Fancy Fields, a CSS-reliant take on a multi-input float-label pattern, after a healthy dose of frontend-dev wizardry by Emmy Armintrout (on GitHub here).
One after one, the iterations progressed. The designs were vetted across the team, and light prototyping helped to identify friction points. We identified a number of key elements to test moving forward.
- A indication of progress, such as a percentage-bar.
- Emotional anchors, such as a pet's photo.
- Float labels, to tidy up input fields.
- Huge CTAs that embraced motion.
- A number of fine-detail notes around motion, derived from game-design.
- Permission priming.
- Conversational tone.
Because this redesign hasn't formally launched, there's only so much I can show. I can say that after some preliminary testing, the redesigned setup flow has nearly a 100% completion rate, which includes two OS-level permissions being granted and 10 data points gathered. As soon as the redesign is made public, I'll be updating this case study with mocks from the release, our findings, and the results of testing step-by-step.
Thought this process, numerous people helped form and evolve the concepts. The entire team jumped in for feedback sessions and design workouts. Also Emmy Armintrout, our frontend developer, turned the spec for our float-label into a usable thing which accelerated and enriched testing, and added sincere value across the org.