Potato project for Google

The Situation

What I’d like to share is a slice of a complex project I worked on at Potato. Google needed a web-based tool for managing a complex system. This system featured millions of things (physical and virtual), time-critical messages, and transparent communications of data between the company and third parties. (The closest comparison I can share is like a supply chain.) The way they were working was very labor-intensive. They used spreadsheets with custom scripts, emails, and phone calls, which made for a brittle system where users missed critical issues that cascaded.

This is not a story about look and feel. This is a story about tackling complexity and making a tool that was clear, comprehensible, and reassuring for the users, the company, and its partners. Spoilers: in testing, we saw a reduction of errors (resulting in poorer customer service) of over 50%.

Because of this focus, I’m going to share only a few images (though our handoff document to the client had hundreds). Apologies for the blacked-out areas due to the NDA.

The contract for this project was to deliver an MVP of this web-based system tool in 12 weeks.

Our Actions

For this 12-week project, we were a team of three Product Designers (including me), one Visual Designer, and a Product Owner. We worked in an Agile framework with two-week sprints. Each sprint included presentations to the client to share our findings, progress, and next steps.

At the stakeholder kickoff, we facilitated a group exercise to uncover goals, needs, expectations, and risks. This helped us build our Statement of Work and gave us a starting point for our research sprints. We iterated this exercise after we shared our initial research findings.

We began our planned sprints focused on research. We wanted to gain domain knowledge, learn through SME and contractor qualitative interviews how the existing system worked, and learn what the pain and failure points were. We saw that the existing system was a ton of spreadsheets, custom scripts, and phone calls and emails on a daily basis. The users were overwhelmed with complexity and lack of clarity. They could not see what they needed to do next, nor was currently or about to be on fire. This moved our focus from building a better front end for spreadsheets (the client’s initial idea) to reducing complexity while adding transparency, lowering user anxiety, providing insight into the health of the system, and reducing errors.

Three Insights

The first insight was about a core point of failure for the system, one invisible to existing thinking.

I presented to the team the idea of mapping out all the necessary communications in the system. We had seen in our research that many critical failures had occurred when any part of the time-critical signals (“Did you receive X at the necessary time?”/”Yes, and I’m sending confirmation in the necessary time window”) broke. In the existing system, there was no insight into when these failed or were about to fail – unless someone made phone calls after the fact. The service blueprint I created was the first any of the client teams had seen of this. It also allowed us, when we built our MVP, to allow users to see when these communications occurred, needed to occur, or had not occurred.

The second insight arose from systems thinking. The client teams, operating in silos, had never been able to see how their teams, third parties, and customers, had to interact predictably, before missed data cascaded into critical failures.

I and another designer took a look at the entire ecosystem: teams, third parties, their teams, customers, and the data and communications that needed to flow. We found that certain time-sensitive comms were predictable within set time windows, something that was invisible to the way Google was currently managing things. This allowed us to build in predictive alerts for users, so they could see when issues could emerge before they were critical.

This high-level system and process map would also later help us to learn more about how to manage communications with third parties. (An unexpected business goal: it allowed the client later to manage business relationships with third parties).

The third insight came from IA: instead of building our tool around showing all information, we could build the tool around objects and their attributes, creating a simpler workflow.

I worked with another designer to audit the vocabulary used for items across the system by various third parties. This IA work showed that items and attributes had a many-to-many relationship. This dovetailed with our research that showed many user errors arose because of misunderstanding of terms. It also meant we didn't have to show all users all object attributes at once – only the ones relevant to the user at that moment. When we presented this to the client, they were able to see value in moving from their assumption of "the more information, the better". This gave us room to pitch our idea about simplifying complexity.

From this work, we could see that the users needed to handle items with many complex attributes. When thought of this as a faceted system, we could create an interface that showed these users only the attributes relevant to what the user needed to do. This allowed us to reduce the complexity to three basic interface templates: a view of the system, a view of a specific problem in the system, and a view of the object. Each view reduces to what the user needs to see based on the actions related to this view, while allowing paths towards deep dives. Creating these templates and interaction models also allowed us to center our design work on the components that were persistent across templates. (Side note: If we had known about Sophia Prater’s Object-Oriented UX at the time, we would have been able to leverage her learnings in this area; as it turns out, we were heading towards her model.)

This, in turn, allowed us to move forward rapidly in our design sprints. We worked both on our own and in co-design and usability testing with both end users and stakeholders. We tested our assumptions about information hierarchy, and the arrangement and design of components. (Having done this conceptual work, we could run development of high-fidelity components in Sketch parallel to testing with paper prototypes). Note: these were collaborations among all the designers where we took turns with the markers.

And in turn, we could move quickly in usability testing and iteration. The object-oriented focus meant that the macro elements such as templates and components could be tested and refined in parallel with the micro elements. I had the most experience in usability testing on the team, so I built the testing protocols and helped the other designers feel more comfortable leading test sessions, either in-person or remote.

The components (not to be confused with widgets or affordances) were built to the client’s own design system and packaged as organized and editable files.

Delivery and Results

Within 12 weeks we had delivered a mature, tested, and innovative blueprint. This helped Google to build the tool they wanted. We built out components using their preferred design system, met the goals in the Statement of Work, and could show that our work reduced the risks and increased expectations we had mapped out at kickoff. And we provided them with data that showed our object-oriented model led to lower errors, increased confidence in the system, and reduced anxiety on the part of users. Though due to the nature of the NDA, I cannot say anything about how they are using our work for what today, the client was happy.