←Back to FullContact Projects



  • 5 Staggered Releases
  • 16 Weeks Duration
  • 2 Responsibilities, of Program Manager and Lead Designer
  • 4 LoFi Design Versions
  • 6 Internal Teams Consulted and Gave Input
  • 4 Customers Input in Beta Program

The existing reporting software was out-of-date, inaccurate, and lived in a separate ecosystem(URL). What made matters worse is that it needed to be turned on by a developer with a feature flag anytime that a prospect wanted to evaluate working with us. We also wanted the experience to be 100% self-serve. That is to say, we wanted to open this functionality to anyone on our marketing website. If they wanted to dig in deeper and upload a customer file we wanted to facilitate that with no human contact. In the past it required signing paperwork and talking to our sales department.

The ideal user is someone who believes in being responsible with consumer data. We were building a tool for brands that put a premium on their customers' experiences. Often these builders were Developers and Marketing Technologists that could see the value in our tool set to help them accomplish their work to resolve, enrich, and verify their most important individuals. Generating reports was our strongest way to sell our products and capabilities.

This project was large. We spanned two quarters from start to finish. When there are projects with this much risk and unknowns we use a "Discover" and "Execution" framework to coordinate our efforts. There are other benefits in this way of thinking as well. Often a very large PRD document is produced and then adhered to with dogmatic zeal. By not jumping straight to a PRD, we have time to experiment and get feedback from the market before we set things into stone. Instead of limited ourselves to one option, we have many to consider and test. The PRD evolves in this phase until in conjunction with design mocks we have the end-to-end journey. By combinging two phases of work we've found that it gives a time and place for creativity and building that makese sense for oursubject matter and team.

PHASE 1: Discovery
We started our work for this project in Discovery mode. We needed to insure that our work was as airtight as possible before our engineers started building out the vision. This meant some heavy lifting upfront from the Product and Design team. Once we shaped our idea we instantly got feedback from the market. We were able to adapt and change the vision working in low fidelity mocks. In this exploration period, we were able to try many different solutions. But through the feedback and internal calibration we came to an end-to-end user flow that solved customer problems and met internal teammates/ considerations as well.

PHASE 2: Execution
The second phase is all about building. Since theproduct, design, and engineering leads have been meeting for weeks now there are no surprises. The PRD and designs are complete, as are the stories/epics are written. Engineering has everything they need to build a technical solution to what we have shaped-up in Phase One. Design work continues always 1-2 sprints ahead of the Front-End team. Back-End in this case had started their work already in Phase One. To iterate and react quickly we pushed a new version of the reports UI every two weeks. The product and design teams again collected new feedback from internal and external partners. Once in beta it was all hands on deck. If a bug came up we would assemble a small ad hoc group and solve it with pace. By the time we got to public release we had a very robust feature that had been tested and validated throughout the course of months. Of course, in some ways the release is only the "Starting Line" as we begin to collect new data and analysis on our work.

Our two main personas were Developers and Marketers. Often times we found in our line of work selling an API product is that Developers are often working in service of a Marketer's desires. While the Marketer may not be the most tech-savvy, they partner with someone at their company who can help them navigate considering an API solution like FullContact. Because of this relationship we needed to create a reporting user interface that would appeal to both ends of the technical spectrum. Through the course of user interviews we distilled what we had learned into some internal info sheets on the two personas of "Developers" in "Marketers" and how they might benefit from FullContact's capabilities.

We spent four weeks in low fidelity land. We took inputs and changes the design mocks quickly. Customers were great in telling us how they would benefit from a tool like this. Internal stakeholders gave us a wealth of feedback on how this work might affect their teams. Without feedback we cannot grow our designs and offer the best solutions. This stage of the project was perhaps the most crucial, because we needed to be brave in our design thinking. We wanted to create as many diverse solutions as possible for consideration. Once the project started moving we needed to consolidate all the amazing thought processes down into one narrative. But in this stage the work is free, as we search for truly understanding the problem we wanted to solve. The final stage here was creating an End-to-End user flow through the new reporting functionality. Only after that is complete can we finish the PRD, create epics, write stories, and graduate the work into high fidelity mocks for the FE engineering team to work from in Phase Two.

This is where it all comes together. Engineering kicks off their work to begin coding out our solutions. Design is mid-way through translating our low fidelity work into high fidelity. As we ship new small releases, we continue to get feedback on the now "live" product. After several releases and a beta period we finally push to production on our live servers.

The new reporting functionality inside our Dashboard software was something that helped us better sell our products. We now had a way to visualize our products like never before. By starting with functionality for "Non-Techincal" users we were able to show our value more than tell folks to visit our API Docs as we had done in the past. Visualizations and charts were ultimately a great design asset in our solution to help quickly explain how our APIs work and the value they could provide to brands. We stil have more work to do, but being able to get multiple value payloads through iterative releases proved invaluable in our work to de-risk and understand the problem.