Data Lens is a lightweight business intelligence tool for understanding the shape and attributes of a dataset. I helped design the product that makes it possible for our customers to visualize any data, in any schema and size, and with minimal human effort, present you with a useful display of information. Data Lens enables Socrata's customers to increase the quality of their published data, as well as make simple analysis of large amounts of data available to more people within the government.
Data Lens showcasing 311 Service Requests on NYC Open Data
During my time working on this project, I transitioned from being a contributing designer to being fully responsible for the end-to-end product experience. Apart from creating typical design deliverables, I took part in the initial ideation phase, then co-managed the backlog of features and user stories that were developed in close collaboration with engineering. I also designed, ran, and analyzed the results of several research efforts that affected the design and direction of the product.
The old tabular experience for viewing a dataset, in this case - 311 Service Requests from the NYC Open Data portal
Data Lens was born when an older part of Socrata’s platform was no longer sufficient for the needs of our customers. In particular, our users were becoming increasingly sophisticated, and with that both their need for simple analytical tools, and the size of their datasets, grew. The old visualization experience, which was difficult to use for analytical purposes, was only performant for datasets up to a few hundred thousand rows, and we were starting to see more and more datasets that were in the millions.
The other complaint was the fact that the default experience for any given dataset is to view it as a data grid, something that is less useful the larger the dataset. Scrolling through rows and rows of data only tells you so much about what the dataset contains in its entirety and the quality of the data therein.
The goal of Data Lens was defined as designing a product that does the following:
The first iteration of this product came together quickly considering its scope. We designed and developed the first version, that we released as a beta during our yearly customer conference, in less than 6 months. During that time I:
Managing the backlog of features
Initial sketches for how the product should behave
Mid-fidelity wireframes
I created a survey for testing a few different designs that our visual designer had made. The results of this informed which design we picked going forward.
Results from a benchmarking study I ran. You can clearly see how Data Lens has higher success rates than the other products tested.
Results from the benchmarking study showing time on task. You can see how task 2 had a long tail of people taking a long time? It was because the search box was hard to find. In later designs we moved the search box to a more conservative position.
From idea to production. Sketches on paper...
... evolves into detailed specs for the devs to follow...
... that then becomes the real thing!
This is one of the the most complex product development projects I’ve ever worked on, and I was thankful to have an academic background in software engineering. As we were designing we had continuous discussions and negotiations with senior engineers and architects. Being able to speak the same language regarding any technical constraints or opportunities made it easier for us to design and deliver a system that would accommodate datasets of any size in a performant way.
The other challenging part of this project was the breadth of data that needed to be supported. Typically, if you are designing a data visualization experience, like an infographic or a dashboard, you know the subject of the data, and probably even the exact set of attributes and types found in the data. Not so for Data Lens, here we had to accommodate any data possible, not matter shape and size. Our approach here was to go through hundreds of the datasets our customers had already uploaded, and analyze the schema of each one. To do this we used a prototype that my colleague had written that took in real data, and after categorizing the columns, it would render an interactive experience similar to the one we were aiming for.
The prototype that helped us figure out how to deal with many different schemas
We ended up shipping a product that made it really easy to gain basic insights. It tested really well in the usability and benchmarking studies with a successrate that was 22% higher than its competitor.
The strengths of Data Lens lay in the fact that you never have to start from scratch, and the low technical bar needed to perform advanced roll ups and filters to answer questions. The interface always suggests a few visualizations as a starting point, and data is automatically rolled up. Filtering is as simple as clicking any part of a visualization and it will filter the entire page. With a little bit more effort of customizing your page, you can end up with a tailored information experience that makes it easy to answer basic questions.
The shipped version. Showing a state where someone has applied a filter to only look at service requests in Queens between 2014 and 2017
In general, our customers’ initial responses to the product were positive:
Over time however, adoption of the new tool did not take off as anticipated. There were a few reasons for this:
Motivated to solve the issues that were hindering the adoption of the product, I eventually became the lead designer for Data Lens and kicked off several projects to address the problems mentioned above.
My approach to the fact that the page didn’t visually fit with the rest of the product was aided by a styleguide project started by myself and another designer. Using the guidelines we had defined as part of that initiative, made it easier to put together a vision that aligned better with the overall look and feel of the Socrata platform.
My vision for what Data Lens could look like
I also put together a plan for how to make Data Lens work better on mobile. We had opted to de-prioritize this work in the first version due to time and resource constraints. One of my many learnings of this project is that unless you build a mobile responsive product from the start, you’ll have a really hard time finding the time to go back and do it later.
These changes together with continued effort of expanding on the visualizations to make them as feature rich and customizable as Socrata’s legacy dataset visualization toolset would be the first steps to increased adoption.
The short form creative brief that outlined the approach for making Data Lens mobile friendly.
At some point in time, looking at the usage data and the requests from customers that were still trickling in, we (product management, product design, engineering management) came to the conclusion that in order to make the changes we deemed necessary to increase adoption, we would need to re-architect a rather large portion of the code-base. After carefully planning and laying out the transition between the current and the re-architected product, I was pulled off to go lead the efforts of a different area of the product that struggled with a really high value problem that had been prevalent for years. After I left the team, the re-architecture was unfortunately put on hold in favor of things with potentially higher ROI. While it was disappointing that most of that work never made it to production, I personally found it a valuable exercise in both visual design and project planning.