The design team at Cockroach Labs recently doubled in size (Hooray!). During the hiring process, I got many questions about the company culture, specific projects that a new product designer would be working on, and of course, personal growth. The most common question, however, was surprisingly about what exactly a product designer does.
Product design encompasses a wide range of responsibilities. Depending on the person and their company, the typical day of a product designer can vary quite a bit. Some write thorough code for their mockups, while others write clear, witty copy. Some craft pixel-perfect icons, while others excel at prototyping animations and user flows.
If you're attracted to working at startups like me, then you're probably drawn to wearing many hats. Since resources are scarce, product designers sometimes manage projects, conduct interviews, create mockups, and take on prototyping. And if you're working on a product for which you aren't the primary the user (like a database), one skill that's crucial to success is the ability to leverage knowledge from your fellow coworkers so they can help you arrive at great solutions.
A product designer at Cockroach Labs has three main responsibilities: research, translation and facilitation.
Product Designer as a Researcher
To deliver a great product, design skills don't necessarily come first. Listening to customers is undoubtedly the key to unlocking the product’s potential. Researchers help the rest of the team see the product through customers' eyes, prioritize problems to solve, and validate ideas before it's too costly to reverse course.
Since we don't have researchers (yet!) at Cockroach Labs, product designers are picking up the slack. We run quantitative surveys as well as one-on-one interviews to create a direct line of feedback between users and the team.
Just last week, to find out how to make a better monitoring interface for the database, our new designer Josué put on his researcher hat. He drafted a recruitment guide to make sure we spoke to the right people. He brainstormed activities to learn more about the participants during the interview and moderated all the sessions.
As the team grows, product designers may no longer need to recruit and conduct usability studies. Still, it will always be our job to listen to customers and observe users. Having the empathy to ask questions and the persistence to dig deeper on why people do what they do is what makes product designers natural researchers.
Product Designer as a Facilitator
With insights gathered and features prioritized, the next step in the product development phase is to get everyone onboard with a solution. Facilitators get the right people in the same room, lead exercises for the group, and facilitate and document the conversations so by the time the meeting is over, everyone is on the same page.
Having product designers as facilitators has two benefits. First, some database concepts are harder than others for product designers to understand. We need to hear about a feature from multiple perspectives, such as engineering and marketing, which helps us to comprehend the full scope of the project.
One of the bigger initiatives on the admin UI side is to create some visualizations that would communicate the core benefits of CockroachDB. To kick off the project, I organized a few meetings to gather every stakeholder in the same space. We discussed why the project was important to us and what information needed to be there. Then, we brainstormed and sketched individually before coming back to the group to share our own ideas. Each meeting inched the project forward, until we were able to start designing how the visualization looked and felt.
Making sure everyone aligns on the North Star every step along the way is crucial - not just for us with our still-growing team, but also for much larger companies. It's also important for larger organizations to execute on projects that grant the highest return on investment.
Secondly, when we facilitate, we also educate the rest of the team on design thinking. Instead of talking about it, we apply it while guiding discussions. Classic tactics such as "How might we..." and ideation sketches are used to leverage the creativity of the rest of the team, and spark ideas unknown to us. In short, what's better? Fishing for the whole village, or teaching the whole village to fish? We tend to think the latter.
Product Designer as a Translator
Once scope is defined and everyone is onboard, product designers translate product requirements insights into wireframes, mockups and prototypes.
Designer Michael Rock describes the goal of a translator in relation to design beautifully. He wrote, "The intimate goal is the expression of a given content rendered in a form that reaches a new audience." Great translations capture not only the meaning of the content, but the spirit of the message with individuality of the translator.
Whether it's the product page on our website or the graphics for our tech talk presentations, product designers most likely aren't the authors of the content. Instead, our goal is to transform the content into visually interesting layouts that help tell the story.
When we launched our messaging, "Build it right," on the homepage, I brainstormed many ways to translate it in subtle visuals to add depth without competing with the headline. The idea of the moving pixels on the grid in the background came to me as a way to illustrate how CockroachDB distributes replicas (small bits of data) flowing around the cluster to achieve high availability. The outcome reflects my aesthetic as a designer: grids, patterns, and contrast.
No matter how big of a team we have, designing database systems will always require product designers to act as translators to grasp abstract concepts and to render them in a way that's understandable to the audience. Yet, what's more exciting is to have different aesthetics on the team to influence and mold each other, so our translations can be more alive and spirited as we grow. Next year's translation of our homepage will be radically different from this year's, for the better.
Product Design is a Work in Progress
Defining and refining the responsibilities of a product designer at Cockroach Labs into those three main roles has helped us tremendously in looking for the right candidate in the search. And we’re very lucky to have Josué aboard - he dances gracefully with his researcher, facilitator, and translator hats on.
As Lindsay, our Head of People, always says, hiring doesn’t end the day new employees start. In order to continue to grow the team and strengthen design at Cockroach Labs, we have a lot more work to do. I recently peeked at what is the most thorough designer onboarding document ever to have existed, and one section is on team principles. In the next few months, I am working on defining some principles for our small team of two, and the responsibilities are the seeds where principles will likely blossom.
How do you define product design in your organization? Which design team principles do you follow? What is one principle that you wish your team followed? I’d love to hear about them. Tweet
or .
