←Back to FullContact Projects
Try It Out
- 1 Week Sprint
- 6 Participants
- 3 Days of Workshops
- 1 Day for Testing
- 5 Experts Input Collected
- 30+ Sketches
Some of our work at FullContact needs to be timeboxed because of higher priority work. We plan to run a design sprint on a unique project once every quarter. Usually this coincides with the overall EPD department's hack week. We can take 4-5 days to workshop an idea that hasn't gotten a lot of love, and see what results we can generate for consideration getting onto the product roadmap. We utilize something that looks a bit like the Google Ventures Design Sprint. Instead of five days, we run a four day model with testing our ideas on the last day. The sprint allows us to take a shortcut toward understanding if a particular idea will help our business without the weight of building and launching in our traditional day-to-day model. Our week sprint consist of four days/components. We sketch, storyboard, prototype, and test in that order. Once completed we share the results back with the wider team.
DAY 1: Define, Map, and Sketch
The first day is all about setting expectations. We spend some time with the long term vision, and then drill down into what is something that will do two things. 1. We want it to add value to the business and 2. We want the idea to be testable in just a few days time. Because of these constraints we cannot shoot for the moon. While we always keep the longer goals in mind, we work toward smaller steps in service of the overall outcome. To capture the sprint's conversations we used a tool called Miro that allows remote teams to brainstorm and ideate together. You can see some of our ideation on sticky notes for longer-term goals below.
As both the facilitator and decider, in our small group I drive clarity after considering all the arguments. In this case the decision was to focus on "Non-technical" users like Marketers. How can we better serve users in educating them on the value of our products and capabilities? For this sprint we decided a good place to start would be within our Dashboard software. As it stood there was only the ability for a "Technical" persona to come in and generate an API key. They then would have to take the API key to a tool like Postman to start querying our API by hand. Instead we desired to keep our user inside our ecosystem. We want them to be able to query our API with "No Code", that is to simply enter a valid mapping key such as an email address to see what our API data asset can return to enrich and resolve an identity.
The current user flow is heavily biased to "Technical" personas like Developers. It looked quite similar to other Developer portals for API companies. We over-indexed on security and verification to insure we protected our person-centric data asset from bad actors. While this made us very secure and compliant, it side-stepped the opportunity to create a more wholistic user experience regardless of the user's technical pedigree. We decided we wanted to show more and tell less. The "Try It Out" user interface was a hypothesis centered around the belief that most new users simply want to understand what FullContact does in a quick and efficient manner.
In the afternoon we invited internal teammates to represent their expertise and understanding of our market. In a way, these folks are like bartenders. That is to say they have an ear for our customers' desires and frustrations. We wanted to tap into their extensive experience and advice to try to de-risk our assumptions as quickly as possible. Their input was integral to correcting some of our early thoughts and ultimately helped shape the end designs we put in front of folks for testing. With our mandate for the week solidified and our teammates expert input we moved into the sketchng phase of the sprint.
We sketch to learn from each other. When our group can sit down and dump all of their ideas onto paper we find that we expand our possibilities and afford an opportunity to build off each others ideas. With this small group we had everyone try to create as many different variations of their ideas as possible in a few hours time. We took breaks in-between. Played music. Got snacks. And moved around and shook things out when needed. This is more similar to a traditional agency way of working that we don't do all too often within product development organizations. Once the work is completed we each took turns presenting our ideas. We had good conversation and critique on each presentation. The sketches, and sometimes areas of sketches, that resonated the most toward our goals were starred and saved for the next day. As the first day came to a close we looked forward to storyboarding out a consolidated vision in the next day.
DAY 2: Decide and Storyboard
DAY 3: Prototype
After we completed our end-to-end storyboarding exercise in the day prior we moved to high fidelity mockups with the Figma tool. Not only does Figma provide a way to design our layouts in pixel perfect aesthetics, it also provides developer tools, and most importantly in this case the ability to setup clickable prototypes for testing. We all pitched in on different areas of the user flow, and ended up with a rather polished idea by the end of the day.
DAY 4: Test
Would our idea flourish or flounder? The last day is always the most exciting for our team. We all take pride in our work, but are also realistic to understand in our line of business it is less about our vision and more about uncovering your customers' desires. We were able to recruit and setup review meetings with a mixture of internal and external folks who had never before seen the designs we had created earlier in the week. Their input was crucial and helped us put together a great report to share back out with our larger EPD organization. The learning was invaluable and the costs was a mere four days, compared to other roadmap items that sometimes had been in discovery mode for months.
We achieved our goals for the week. And we learned a ton along the way. Eventually this work made its way onto our prioritized list and was coded out. Once work was finished we waited three months to see how our new functionality was performing. We found the following metrics below.
As you can see below, just a little over half of users' queries were valid and returned a profile from our API data asset. We want to get that number up higher. A few reasons it is lower are around user error and perhaps not fully understanding the correct formatting for input keys. Although we have greatly simplified this with a UI there is still room for improvement. We can add more micro-interactions and helpers to the UI to hand-hold the user a bit more in this regard.
Minds were changed and our assumptions challenged, but it all started with a few sketches from the design team. We learned that it is perhaps too oversimplistic to paint our picture as "Technical" versus "Non-Technical" user personas. In our testing we found that it is more fluid. We need to show our value in a "Non-Technical" way first, but always have the "Technical" functionality right there for when it is needed. Our eyes were opened. As it stands, sometimes we can swing the pendulum too far one way or the other. The balance is something we found quite beneficial to design team conversations long after our sprint had concluded.