“One minute you’re on top of the world, the next minute some secretary’s running you over with a lawn mower.”

We at Lab Zero are big Mad Men fans. We’re also fans of building valuable products solving users' problems. 

All too often, a team builds a product, excitedly launches it, feels on top of the world, and...the product isn’t used as expected by users; or even used. It feels like someone ran over your foot with a lawn mower. Or worse.

This can especially be true for data products. There are lots of varying definitions, but we generally think of a ‘data product’ as a product in which data is the primary value being delivered to users, while there is little to no interface involved. Examples are a recommendation engine, search functionality, predicting who will win each state of an election, or in our case, if an electrical asset will fail or not during high wind speeds. Elixir developers write data ingestion routines and you're done, right? Not so fast. We recently spent time building AI products to help with depowerization efforts and preventing wildfires for one of the largest public utility companies in the United States. And we have an opinion about whether a data product needs a designer.

When building technical products, it can be easy for teams to consider going without a dedicated designer (and sometimes a product manager as well, but that’s for another blog post). A myriad of reasons can arise; it’s cheaper, it seems obvious what to build, perhaps fewer meetings will be scheduled. When a product is so technical that data is the primary value being delivered to users, the trend of not including designers on the team becomes even more common. Often though, organizations and teams misunderstand the value of a designer. Design is not just putting together a nice user interface. A good designer understands and advocates for users, resulting in an experience solving the problem being addressed. 

Because of the above, our experience at Lab Zero is that a data product absolutely needs a designer and / or a user researcher. What is being designed you ask? The user experience. There will be users, and they will be using the data to accomplish the task at hand. The question is, what are these tasks? Who are the key users, what are their skill sets, environments, pre-existing mental models, and how will they consume and use the data? The design of the product answers these questions and more.

Why A Designer Is Needed

A simple example is the difference between how a marketer, analyst, and data scientist would prefer to consume data as simple as gender results:

Many data products are built before unpacking important questions such as:

• Do users prefer working with raw data or with easy-to-understand reports? 
• What is the preferable way to access raw data? A csv export, API, and querying a database are very different.
• How will users assess data quality, the number one issue impacting data analysis? 
• How will the product include an overview of methodologies and definitions to the user who most likely is not familiar with the data?
• What are the needs of users across the org who provide the data, or who support users?
• How is the entire service workflow orchestrated to meet both organizational and user needs?

How would a product possibly be built without knowing this basic information? A designer would unpack key information during the discovery process to define users, and help the team build a product which solves users' needs. For example, a product at the public utility company went without a designer. The team spent all their effort on the technical challenges. It took months to acquire, wrangle, clean, and store the data, and then build predictive models. After launch, the models were deemed unusable. Users were not accustomed to working with what appeared to be raw data in Excel. As this was the first time they saw the data, they also had no idea what they were looking at. Users deemed the product unusable, and distrusted it.  A designer joined the team, and quickly unpacked users were accustomed to working with an internal mapping tool. This tool was already widely used internally, and had a feature which accepted raw data! It took a few days to create a map of the data models and output, and provide context outlining the data sources and methodologies. A few days of user research saved months of development work.

Our Recommendation

Do yourself a favor, and don’t fall into the trap of only bringing in a designer when there’s a custom user interface. Save yourself from the feeling of being on top of the world on day one of launch, and getting ‘run over by that lawn mower’ on day two. Avoid building a worthless product, make your life easier, and always recruit the best designer for the team; even if that product is ‘just’ data. 

Let us know how your data needs help!