Good Fences Make Good Proposals

Creating a scope diagram to assist in alignment with clients in the proposal phase.

Project Overview

Project + Client: Scope Diagram for Warehouse Automation Client
Team: Proposal Team of 3 (VP of Engagement, Exec Creative Director, Lead UX)
Duration: 1 day
Role: Lead UX Designer

Opportunity + Process

After using UI cards successfully to communicate with a development team for a Contact Traciing app, I was interested to see where else this method might help to close gaps in conversations. This was on mind when a warehouse logistics company approached our team about a platform they had developed, but the usability was not what they thought it could be. The prospective client wanted us to review the product and redesign the experience and user interface.

In the initial conversations I listened to between our team and the prospective client, it became clear that we were struggling to define the scope of the project. For me, it seemed like this was happening because they were communicating a combination of the current state of the platform and what they wanted the experience to be. The conversation was also confused by the fact that we (team + client) were talking about the functionality and the experience at the same time. This is normal, but it blurs the edges of the scope for this particular type of project. So we needed a way to show them what we were hearing that also made sense to our team and didn’t take weeks to illustrate.

More often than not, I will start diagramming what people are saying to try to make sense of it. This shows me the gaps in what I am hearing and helps me ask the right questions. In this case, it was important to create a clear diagram of what they wanted. There is the added benefit that showing what you think can remove the ambiguity gap when two people or groups don’t speak the same lingo. In this case, the content we wanted to show included:

• a variety of sources of data input

• role-based dashboards

• addressing the devices each role needs, and

• addressing the scale or scope of data that a particular tasks/role/seat needs to view at once

In our internal debrief after a call, I showed the diagram to my creative director. I originally sketched the diagram with iconographic images to show a few of the items above. We had some clear gaps, but realized we could make a few assumptions to fill in the blanks. Sharing this with the proposal team helped to consolidate the different threads each of us heard. We had a great conversation to resolve areas where we interpreted the client requests differently. This gave us a solid diagram of what the user experience design needed to address across roles, devices, and physical environments.

Outcomes

Using a set of assets I had on hand, I created a client-ready version in less than an hour. This uses a set of UI cards I purchased from UX Kits and modified, icons from The Noun Project, and avatars created by my coworker Danny Martin.

We created a scope of work from this diagram and reconvened with the prospective client. We started the conversation with the diagram to describe our understanding of the desired scope of design. We asked them to review it with an eye for what might be missing or not aligned with their request. Since it was created in a visual whiteboard, it was very easy to tag our assumptions for our review session with the client. Amazingly, a conversation that often takes several days of back-and-forth with a written scope of work was clear and everyone agreed to it in about 25 minutes.

This became a standard part of scoping product redesign for our team. We saw a reduction in misunderstandings about the scope which reduced the time required to sign the contract and also to execute change orders during the project. The design team also reported that they used this as a reference point and it increased their individual confidence when starting new areas of work.