Creating an accurate digital representation of the world is hard work; keeping it up-to-date is even harder, and frankly impossible without Machine Learning (ML) as an integral part of the process. For map building purposes, those ML operations are often detectors, capable to identify real world objects from photographic or LiDAR based imagery. This way, the main labor is to collect new images of the world, while the processing and updates happen automatically.

However, those detectors don’t create themselves and won’t function as intended if not trained properly. Also, none of these detectors will run smoothly from day one. Their output must be verified and corrected if needed.

In short: automation requires a lot of manual labor by dedicated professionals using software specifically built to support the cause.

I was able to convince my manager (who was also the engineering lead for this tooling effort) to spend more time on this topic. I wasn’t interested in putting “lipstick on a pig”, but was very excited about the opportunity to apply some

product/design thinking methodologies in order to find a solution that will improve the overall quality of the tools and the user experience of the people who have to work with them for 8 hours a day.

Transforming this focus on efficiency into tangible design solutions required further deep dives. Luckily, I didn’t have to work on this all by myself: 1 designer in Berkeley, as well as 2 designers and a newly hired design researcher in Mumbai, joined me in this effort to improve the efficiency and user experience of HERE’s map buildout tooling.

To gather requirements and better understand what we were dealing with, we organized an initial kickoff workshop in Mumbai with relevant stakeholders. Afterwards we set out to analyze the existing tools, workflows, work environments, and internal processes.

We went from high level user journeys down to current keyboard commands used in existing tools and other production software (i.e. Adobe suite, 3D Studio Max).
The findings and proposals we ideated were regularly reviewed with key stakeholders to make sure that we stayed in the realm of possibilities and to create a sense of co-ownership.

This had the positive side effect of establishing good relationships and trust with everyone involved and being invited to more technical workshops and discussions, thus providing insights needed to get the job done. Having those close ties is essential if you want to change a bigger picture - you can’t just push a design and call it a day.

While not able to reshape the overall process, we proposed and established some practices into the existing operations that were more design/product thinking oriented.

To figure out how to make tools more efficient, I mapped the existing and upcoming applications on a grid.

This helped me to discover commonalities and patterns - useful for design and development.

In addition, I mapped out the user journeys for the two main types of workflows, first on a detailed level, then on an abstract one; again, the focus here was to find similarities and consistency.

As the tools became more efficient to operate, so did the support layer. We needed to reduce time spent onboarding and time wasted waiting for answers on a specific problem that hindered progressing in the current task.

I analyzed websites and wikis that provide guidance and troubleshooting, tutorials, and training sessions to onboard users, as well as tools that allowed users to allocate the workforce as needed.

Looking at both tools and support services, their interconnectivity throughout the user’s journey became evident: switching from working to looking something up or providing help happened constantly and needed a more instant, seamless transition.

Finally, the key piece: as we uncovered patterns and what looked to be common components across the tools and services, we realized that by transforming the development efforts into building tools out of components, the team would be able to support more stakeholders, while keeping everything consistent.

Following the guiding light of making everything more efficient, we found a solution that we deemed future proof: design and build tools based on components. This would guarantee consistency, lowered efforts in the long run, and easier maintenance.

The question was: what would the end user experience be like, and could there be a way to give stakeholders some control over using those components themselves?

The first idea for a product was one that looked great on paper and in the eyes of stakeholders, but ultimately clashed with the realities of the work environment.

As we thought of component-based solutions, I proposed the idea of creating a “tool creator”, a web-based service aimed at data scientists that would allow them to build their own tools.

The flow would be straightforward: from a home screen the user can monitor existing processes or setup a new tool. This setup lets users select the type of tool (creation, reviewing), the type of data, the amount of users, the QC processes, and other things required. After submitting, the system generates a tool based on existing components and sends it off to end users who would work on it for a set period of time.

This idea didn’t pan out for a couple of reasons: at the time it was deemed infeasible to create by the engineering team due to existing requests and lack of experience in this field. Also, the stakeholders, while liking the concept, didn’t think their needs for new software would be continuously high over multiple years to justify investing the time to build this tool creator.
However, the component-based approach struck a nerve with everyone involved.

While the whole creation system fell flat, the engineering team agreed to shift their focus to a component-based tool development. This was ultimately good for the end user, the stakeholders, and the business. It also put a healthy pressure on the design team to ensure those components would work across stakeholder needs.

So, with that pressure we finally set out to get started on redesigning the tooling experience.

The following and other specifications on a more global scale helped us in the design team to work more consistently and within set boundaries.

Holistic solutions that need to work within a fuzzy realm of requirements require a rock-solid foundation. Therefore I started out setting up the information architecture and component nomenclature, on which everything else would be designed. Grids, colors, typography, and other shared attributes would follow.

With the baseline set, UX patterns needed to be defined, often down to the most basic ones, such as creating a vector point or a polygon.

Other aspects that are considered “out of the box” had to be “reverse designed” and specified (remember the lack of frontend experience in the development team) to ensure a common behavior across all tools, such as camera movement in 2D and 3D spaces.

I was keen on keeping everything in the UX and UI consistent, that included re-mapping keyboard commands in a way that’s logical, ergonomic, and expandable.

In addition to defining the end user experience down to the smallest required detail, I also worked with operations managers and data scientists to figure out ways how to translate their current work flows and processes into application flows, for example in the areas of Quality Control and feedback escalation.

This had an interesting synergy effect, as me trying to understand their process, asking a lot of “outsider” questions

and designing towards simplifying the mental load for the end user also helped said stakeholders to discover different, simpler approaches.

After various workshops, presentations and discussions, those co-created flows were documented and used as basis for the UX and the underlying processes.

Over the course of a couple of months the design team and I created, tested, and iterated upon our set of guidelines, specifications, and detailed design components.

In parallel we started to work on designing the first set of tools that would follow this new set of specifications. A great way to put theory into practice and learn from usability testing.

3 months after the initial request we released our first redesigned tool, and thanks to our component-based approach were able to add 3 more just 3 months later.

Everyone in the design team owned the design responsibilities for one ore more tools, while I took additional care in ensuring consistency, stakeholder management, and working with user research.

I look back fondly on the time spent on this project. Sure, the user interfaces we’ve created didn’t look super slick, and the designs were not always implemented 100% (or even 60%) to spec. But we had successes right from the start: we improved the user’s quality of life with a better user experience, we managed to reduce onboarding time due to simpler workflows, we eventually decreased development time, and we created a great rapport with stakeholders.

Personally, I gained a lot of experience managing a design project of that magnitude (creating concepts and producing specifications while simultaneously leading a team without being their manager) and working in such a culturally and professionally diverse setup.