Overview

Mobile Survey Experience

Completed: 2018
Timeframe: 6 weeks
My Role: Project Owner
Collaboration: PM, CX, Support, QA, Development

Objective

Simplify, refine, and update the entirety of SurveyGizmo's mobile survey experience while maintaining its robust functionality.

Deliverables

Inventory, Visual Design, Improved User Experience, Interaction Design, Clickable Prototypes, Motion Specs, Jira Documentation

Process & Methods

Competitive Analysis, Paper Prototypes, Wireframes, Visual Design, Framer, Invision, User Testing, Task Tracking, Presentation & Feedback from internal  teams, Jira Documentation

Overview

This project encompassed a robust set of questions, actions, and extensive options spanning 10 years of development. It provided me the opportunity to work with many stakeholders across the organization and gave me the ability to drive real change.   

Important customers were leaving us — they demanded a better mobile survey experience. To grow small team accounts into enterprise accounts and attract new customers, we needed a better mobile experience.

Project Goals

Simplicity + functionality

In-depth customization is a key differentiator and a crucial part of our product's story. It’s one reason why we’ll be able to transition into the enterprise market, but a rich feature set also increases the difficulty of finding simple solutions.    

My primary goal was to make the mobile survey experience easy, enjoyable, and consistent. To achieve this, I needed to simplify our patterns, clean up the UI, and reduce the number of taps required. Up until this point, mobile was an afterthought. Most of the question types would need to be retrofitted to work well in mobile. With this project, we hoped to design for mobile first and then extend the changes to the desktop experience.

Analysis

Competitive analysis makes it easier to see your product

The project started with a detailed look at our competitors. Which problems were they solving more elegantly? What were they doing well that we could learn from? Competitors like Typeform and Google Forms had a limited feature set but excelled in their mobile survey experience.

Their navigation patterns made survey taking easier. Their microinteractions made the survey seem quicker and more enjoyable. The experience was consistent and the UI looked minimal yet stylish. It was clear that we’d put off updates for too long and had a lot of catching up to do.

To close the loop, I created several docs communicating what I’d found through this exploration. I also saved a series of screen recordings for future conversations with the development team. Sometimes showing a live example can help push an interaction pattern through to production.

Inventory

Our mobile survey experience lacked efficiency

Over several years, our company added many new question types in an ad hoc design process. For customers, this made the mobile survey experience unpredictable.

To get a clearer picture of the current state, I created an inventory of the 34 different question types and an additional set of customization options. It was eye-opening. I collected notes on confusing interactions and points of uncertainty. Screenshots cataloged survey actions and anything visible to survey takers. Then, the QA team helped locate any additional problems.

After completing the inventory, I grouped it into interaction patterns. This helped visualize where we needed to merge patterns and where we were falling short. Our mobile experience needed simplification and some light animation to reduce the perceived effort of survey taking.

Process

Building new designs

The design process started with drawings and wireframe iterations of the flow and layout. Putting these into InVision made it easy to test on a mobile device and get early feedback from the Dev team. For the sake of transparency, I organized the feedback and resulting tasks in a spreadsheet with Airtable. This allowed me to track and share the project status as it progressed.

After testing our initial assumptions, I began working on a design system for the new mobile UI. Adjustments to the typographic scale increased legibility and added a clearer hierarchy. Basic vertical spacing rules helped chunk information for clarity. All changes needed to work with our existing interface for user styling. By working on these system-wide changes early, I could confirm their viability.

After building a basic design guide for mobile surveys, I started focusing on specific question types. The most commonly used question types and shared interaction patterns were a good starting point. By solving for these, a broader set of rules and logic for other question types began falling into place.

For new interactions or patterns that needed to be rebuilt, I used paper drawings and prototypes to iterate through possible solutions. Designing for touch can be tricky, but paper prototypes provide tactile feedback with less invested effort. Because they’re disposable, there’s less attachment to the solution.

Prototyping

Communicating motion

The survey taking experience needed to feel quicker. Microinteractions provided an entertaining way to animate success and progression throughout the experience. The existing transition between questions was confusing. It didn’t seem to follow the logic of related interactions within the UI. Worse, it felt canned. So, we knew that the interaction design also needed an update.

To address this, I created a clickable prototype in Framer to test and design a new transition between questions. I also created microinteractions for our most used question types and an SVG animation for our “Thank you” message at the end of surveys.

This prototype was instrumental in engaging stakeholders and warming the dev team up to the changes. It made the changes real. It also filled in a lot of the gaps that were hard to communicate in an InVision prototype.

The InVision prototype transformed the static screens from Sketch into a mobile experience. It wasn’t perfect by a long shot, but it got the point across. It also provided an easy way for developers to reference specs and leave comments where necessary.

Buy-in

Buy-in & testing

The prototypes were essential to getting feedback and buy-in. In the early stages of the project, I was able to collect informal feedback from the product team and front-end developers. As the project got closer to completion, I led presentations of the project for the CEO, support leads, QA, and the documentation team.

As the project neared its finish, I used the prototypes to lead a kickoff meeting for the development team. At each stage, I collected feedback into my Airtable spreadsheet and worked from that task list.

Testing in UsabilityHub gave us quick feedback. Proof from these tests made decision-making easier. We were able to locate areas where affordances were missing and whether the new patterns worked. We discovered that our text fields needed floating labels to be more discoverable. 

Outcome

Part of a larger transition

The mobile question project was well received, and we’re proud of the work. I'm told that a version of this work is finally making its way into production. The project focused specifically on Mobile, but a version of it will also be extended to the desktop experience.