3 Reasons to Put a Designer on Your Product Team

The value of a keen eye for design

“I’m a visual person,” said Justin. It wasn’t the first time I’ve heard that from a client.

Acknowledging that all of us are visual learners to some degree, I’ve learned that having a designer as part of your product team can lead to a higher quality and better outcomes for your product’s customers.

Of course, designers have a well-trained eye for design, but their expertise extends far beyond leading and learning. Designers also have a detailed understanding of usability and accessibility principles, the ability to solve for transitions and interactions across views and at different points in time, and the inclination to seek both input and feedback from those who would use those interfaces.

Here are three reasons why I recommend always having a designer on your product teams based on one of my latest client projects:

1. They build a model, while the builders get ready to build.

As is typical at large enterprises, getting our engineers up and running can be an excruciatingly slow process. Mandatory training webinars loom ahead. The procurement of hardware, access permissions, and other on-boarding tasks seem to stretch to the horizon. Partnering with my designer, we jumped right into the discovery process and dug into existing artifacts, conducted discovery interviews, and familiarized ourselves with the technology ecosystem in order to convey our vision for the product and get feedback on our direction. In the past, I’ve had to make do with text descriptions buried in requirements documents. (Oh, and if you’re lucky, Gantt charts and multi-hued, Tetris-like roadmap slides.) With our designer’s skills, however, we were able to build a realistic model of the subject, well before the engineers broke ground. Sharing and gaining feedback on prototypes (built with tools like Figma, Sketch, and Invision) helped us mitigate a key product risk of poor usability. By sharing the prototypes early and often, it gave us insight into the value of our vision and allowed us to setup meaningful interaction patterns for our engineers to build.

2. They delight through simplification.

I had been working through a new feature mostly on my own while our designer was on vacation. The tool included a series of pages with similar controls that allowed them to review data and create text entries associated with that data. I had the basic details worked out and acceptance criteria filled-in, providing a framework to discuss the outcome. I also had some feedback from our client and the engineering team. Everyone was satisfied it would do the job.

Our designer returned, and we brought him up to speed. He quickly sensed a pattern of complexity in the existing specifications that the rest of us all missed. With the introduction of a simple toggle control on the User Interface, we were able to eliminate redundant pages and controls from the design. Perhaps more importantly, there was a tangible sense of delight that the toggle created upon its introduction.

The Kano model provides us an explanation as to why these kinds of features are so important to your product. Their unexpected and appealing nature amplifies the sense of value, as in “Wow - I didn’t know you could do that!” In time, the design team helped us identify and prioritize additional delighters, including a “copy to clipboard” function. While the time-savings offered by these kinds of elements are sometimes nominal, their elegance and unexpected nature amplify their value to the user.

3. They level-up all product communications.

Roadmaps - love them or hate them - have a special place in the world of software and product development. The best ones tell a story – how and when the product will evolve – and set consistent expectations accordingly. A good roadmap both enhances real-time discussions about this evolution and serves as a clear, unambiguous plan for “offline” references. As a product manager, I’m well-versed in the art (not science) of narrating an evolving set of features over time: feature details and time commitments early on, hypotheses and risks tackled further out. Roadmaps carry a visual element to them – and their graphics send subtle signals to your stakeholders. I distinctly recall the drastic before/after improvements that our designer incorporated into our roadmaps. We improved color choices in particular, avoiding red and green shades to prevent us from unwittingly communicating something as good or bad. Tempering the level of color also improved the ability of the audience to focus on the content.

This was not the first time I’d seen the value of a keen eye for design and a strong orientation toward the user experience, but it was an important lesson in how versatile this role is – and how many ways we could put it to use. In the past, I had witnessed design at either the edge of development or seen it as a separate workstream altogether. And while I never questioned the depth of value they bring - for creating useful, intuitive digital products – this experience showed me the breadth of work they can enhance. From the ability to deeply engage business stakeholders, to validating hypothesis, to the tangible joy users get from “delighter” features, our designer’s skills enhanced many facets of our work. For a product team, success hinges on your ability to communicate ideas and telegraph intent with stark clarity. Every product manager can stack the odds in their favor by partnering with a strong designer.

[1] Build What Matters: Foster, Ben