Nate Jones

Design was a major focus of the founding CEO of a fairly mature startup in the Chicago suburbs, and it was the key to our success. Within a very low-margin, red ocean industry, the company excelled in delivering the most compelling & inviting user experiences for its customers. They were never in the business of building the most complicated systems or the most comprehensive solutions — instead they carefully & quickly crafted the best user experiences and killer user interfaces within their industry.

How Things Were

The design workflow would start with the CEO dreaming up an idea, and immediately sketching wireframes on giant sticky notes. He’d call in the product manager (me at the time), the marketing department, and the solitary product designer to listen to his plan.

While thoroughly considered and relentlessly ambitious, the plans always needed to immediately jump directly into the high-fidelity UI design phase so that the CEO could get feedback from a few likeminded clients.

We’d all leave his office and immediately reconvene to fill in the knowledge gaps with assumptions, assign a few follow up tasks, and turn our gaze to the product designer who had several weeks of late nights ahead of him. He’d face the ambiguity with fearlessness and would build out multiple iterations that would be presented to us, to the CEO, and to some clients.

He would also create a bunch of high-fidelity work that was thrown away and would end up returning to his normal design work exhausted. A week or two would pass, and we’d end up back in the CEO’s office again with another exciting project up on the glass.

The Do Over

When I made the switch from Product Owner to Director of Product Design, I knew that I had two immediate tasks ahead of me; equitably balancing the workload, and inserting process before high-fidelity assets were created.

I hired two more designers and embedded them within the individual product teams to allow them to truly understand each product, and allow them to be a specialist in that vertical & be the designer on call for the CEO’s future ideas.

Instead of focusing on UI details from the start, I switched our focus to user stories, intentions, flowcharts, and wireframes to let the designer marinate in actual meanings & implications of the request.

The Process

USER STORIES

A narrative description of a person-focused scenario. A story is the why that sets the scene for the team to break it down into the how. Read the user stories and ask questions to pull out more details and enhance them. Are there other user stories that should be documented?

INTENTIONS

Intentions are sentences that describe a single intention for at least one type of user. Take the user stories and break them down into intentions. We’re poking holes and being annoyingly specific now so that overlooked intentions don’t snowball into a big problem later. They are written with imperative mood and in the first person.

While intentions are a super simple tool to represent user needs, the list is an essential step to complete before creating a flow chart because it defines the scope of the design. The list acts as a checklist to ensure the flow we’ll create addresses all the user needs. Every intention gets an ID that we can use to label different aspects of the flow chart.

FLOW CHART

Flows are an important part of the planning process, as we’re able to show the user’s path before anything has been designed or built. In addition to having a visual guide to pull from in the latter stages of the project, laying out a user flow also helps uncover any holes or gaps in logic that may not have come up otherwise.

Here’s where the intentions really come to life; take the IDs for each intention, and tag applicable steps in the flow chart to make sure it addresses each of the user needs that you already listed out.

WIREFRAME

With a solid understanding of the intentions and user flows, you can build wireframes that encompass all of the needed functionality. When completed, move the wirefrafme task into Engineer Review status.

ENGINEERING & PRODUCT OWNER WIREFRAME REVIEW

Wireframes are an important part of the design process, as we’re able to show layout, interactions, and flow without needing to dedicate time to creating pixel-perfect mocks. Wireframes help stakeholders focus on approving functionality without the distraction of a specific UI, and are also helpful for the developers by allowing them estimate work.

High-Fidelity Mocks

Create high-fidelity mocks by assembling design system components informed by the wireframes. Upload the files to InVision for prototyping and sharing. When completed, move the the high-fidelity task into Peer Review status. It’s very important to link this design task to an engineering task for future quality testing.

Peer Review

Once the high-fidelity task appears in the In Review gadget on the Product Design dashboard, it will be assigned during the team’s daily standup and will be assigned to peer designer to ensure concept, consistency, and quality. When any edits are completed, tag the Director of Product Design for review. When those edits are complete, move the the high-fidelity task into PO Review status.

The Outcome

I’ve now grown the team to four designers who are able to create amazing work and still log off around 5:00 to be able to enjoy their lives. We can also take more of our time back to redirect energy to projects that can make future us happy — like migrating to Figma and building a design system.