Simplifying a Complex Internal System

The Gallup Survey Manager is an internal tool used to create surveys (known internally as compilations) for Gallup’s various in the field studies. An implementation analyst uses this system to create and setup a survey, which can appear in both digital and print formats, and can be translated into multiple languages. Once the survey is published, interviewers read the survey questions, answers and instructions, and assist in collecting data for the research study.

Goals:
The goal was to create a more a streamlined survey builder tool that would allow implementation analysts to more efficiently create 300 surveys in the span of three months. I was given 4 months to work on the design for this project.

Key Partners:
Data Engineering | Implementation Analysts | Managing Consultant | Technical Project Manager

View of the Compilations Screen

Kick Off, Alignment, and Pre-work

I was given the freedom to really own the design of the project and laid out a few goals for the team to align on. First, I wanted to get the system to be more closely in line with Gallup’s other systems by bringing in components that could be shared across platforms and by styling new components with our Gallup brand standards. Secondly, I wanted to make a better experience for the end user, and create something that was more efficient, intuitive and enjoyable than the current platform. With that in mind, I began researching and reviewing existing artifacts including a definition document created by my lead engineer and a survey that a user would expect to see as the final exported survey.

Definitions Document Laid Out by Engineer (L) and Exported Survey Example (R)

Breaking Down the Flow & Functions

Once I was aligned with talking about the system and understood the starting and end points for a user, I laid out a user flow that included key pages and functions. For each of the key pages, I listed features, tasks and expectations for the user. I used this document to discuss with my engineer and made changes as needed. Then I created a more finalized categorization of the features and what pages they lived on.

Updated Sitemap

Concept Wireframes & Aligning on the Direction

With the breakdown and categorization started, I began to recognize patterns in the structure of the system, that helped me to begin ideating on the elements and look of the system. I began putting together rapid wireframe concepts that I had imagined for design direction of each page. These wireframes included the grid, navigation, and general page hierarchy or elements. I also began including and reusing components concepts into my wireframes (ie. tables, modals, input fields, etc...). With these wireframes laid out I was able to discuss and have a clear understanding of what I was thinking for the direction of the system.

Screens From Rapid Prototypes of Initial Concepts

Creating Interactive Prototypes to Give Users A Realistic Experience

We went through rounds and rounds of iteration, adding functionality as we got deeper into the system and changing features based off of data changes. Along with those meetings that we had on the development side, we did regular check-ins and updates with our implementation analysts. They were a crucial role in all of our meetings because they were our main users of this system, and they had an ambitious goal of creating 300 surveys within the end of a 3 month timeframe using this new system. Because they weren’t tech or design savvy it was important to create functional prototypes that they could more authentically react to.

Screens of Some of the Page and Component Connects

Final Designs

Our final designs included screens for building a question and building a compilation. This system pulls a lot of data from existing questions and smaller surveys in the creation of new survey so there were a lot of modals that were incorporated to allow the users a more focused action when working on this larger goal of creating a survey. Sadly, the project wrapped up right as Covid was beginning to get bad and the project had to come to a pause. We had saved the final styling for the end but were never able to, so these are black and white mock-ups.

Final Builder Screen

What I Learned

•Having a shared understanding of the terminology was extremely helpful in alignment and continuous back and forth is crucial for this type of project and made for a successful project. Communication and regular check-ins was crucial to the success of this project.

•My design process wasn’t a linear one for something this complex. It was a lot of back and forth going from interpretation to ideation and back, which made for a better end product.

•A lot of our internal systems at Gallup aren’t given the time and resources to create an optimized experience. Users can start to accustom themselves to things being overcomplicated just because. Because of that, it can be hard understanding from them what features would be most important and useful and beneficial to update and change.