Data cOLLECTION orchestration
2018 – 2020
HERE NUCLEUS
(2018-20)
Design Lead UX/UI & Research
Envision, design, and shipping of a web application allowing users to plan and monitor map data creation from collection to publishing.
I The challenge
After spending a considerable amount of time working on commercial applications and services, I got the chance to explore the inner workings of the company. This transition from working with location data to producing it introduced me to the problem space of internal applications and the lack of UX support they usually have to deal with.
It also put me in the role of Lead UX/UI Designer for multiple products connected by a common theme: collecting map data and monitoring the process.
The topic itself is easy to summarize: it's about the end-to-end data collection orchestration that turns data picked up in the real world into a map product and map objects. From street level to map level, basically.
The execution required understanding of the complex pipeline that involved a lot of stakeholders and software applications, the latter of which we found in dire need of a redesign. Not a visual overhaul, but fundamental changes both on front- and backend were needed to increase output and decrease waste of time, management, and long-term engineering efforts.
As we were working in a live environment, we needed to be extra careful that any change, reduction, and reimagining in the front- and backend would not disrupt or completely break the running production pipeline. To make the process easier to rationalize, we split the work into three major areas:
Planning and monitoring
Data collection
Data processing
Data processing was more or less its own closed process in the company (more on this here), of which we’d merely consume information. This allowed us to focus on the first two areas: planning/monitoring and collection. This section documents the journey through the former - the challenges and solutions for the collection part are summarized here.
II The journey
In order for a driver to know where they're going, a plan must be made. Upon starting work on this project, we knew of 5 different applications and at least twice as many spreadsheets that took care of this planning step. The more people we talked to, the more duplicated efforts we discovered.
Through various discussions with stakeholders, strategic workshops, creating a common vision, and redesign efforts (first incremental, then finally radical), we reduced this to one single service that took care of planning, monitoring, and reporting.
Planning: figuring out where, when, and what map data to collect for adding to or updating the map product
Monitoring: tracking the fleet during collection and following the data along the pipeline from collection to publishing
Reporting: creating summaries of various data points, time zones, and map areas to inform stakeholders and shareholders, and plan the next collection cycle
After having set up the new structure, we worked together with the product manager on a vision and a narrative to get all stakeholders on the same page, and to get their support to move forward with this rather drastic change in this part of the pipeline.
On the tracking side, we learned from managers and fleet support what the most important pieces of information are to successfully track a driver, check the health of their collection rig, and bill them properly.
The solution we ended up with let end users not only see all collection rigs and their current and historical status, but also allowed them to create groups of rigs as a way to better focus on subsets of drivers across the globe - something very useful for regional managers.
On the reporting side, we gathered insights about what information from the pipeline was truly relevant to end users and what was considered lower value. To no one's surprise, knowing when something went wrong was crucial.
As the pipeline was long and complex, we created a general overview and 4 dedicated areas for each major milestone of it, all containing more detailed information. We dedicated a final page for fallouts; issues that were reported throughout the pipeline, broken down into various sub-issues. From within each of the sub areas, users were able to extract the fallout information to kickstart a re-collection or re-processing.
The visualization of those data points proved to be a small project on its own: finding a set of colors for each data set, with colors within for data subsets, was not an easy feat. Trying to find colors that also provided enough contrast between each other and adhered to color blindness standards was even harder.
Ultimately, thanks to a few online tools and a lot of trial and error, a set of colors was defined and shared with end users (which required them to overcome their personal bias and a legacy mindset).
Still today, the color scheme is an aspect we're constantly monitoring in order to improve it further.
III The takeaway
This particular project was a rare chance for design to be involved from the very first moment of its conception. Being allowed to take an active part in the orchestration and backend architecture of the pipeline, and contributing with a UX mindset, was empowering.
Tapping into data visualizations, where the presentation layer and the decision to show or hide information shapes legibility and narrative, was a fascinating learning experience as well.
Most of all though, the improvements we provided to the process emphasized the value that design can bring to any table, be it commercial products to delight millions of users or internal products that generate millions in revenue.