Rise to the level of our Design Systems
In my earliest days as a new Product Owner, I was deep in a conversation about observing a user’s transition between tasks in our software’s workflow, when the Engineering Manager asked me, “Are you only a product manager because you didn’t have the artistic skill to make it as a UX designer?” I immediately retorted, “Excuse me, Sir. I’d put my repertoire of boxes (and boxes-with-Xs-in-them) up against anyone’s!”
Each of my interactions with UX Designers has been similar to how I work with all levels of my product and engineering teams. We walk into a project kick-off or design session with the same desired outcome: “How can we solve this problem for our customers/users together?”
My interactions usually begin with a product brief — a one-pager about what problem we’re trying to solve and how potential solutions benefit users and stakeholders alike. Since the project has made it past the brief and I’m speaking with a UX Designer, I have already started drafting my product requirements document (or PRD) with the who, what, when, where, but not yet the how answered.
We get to build the how of the feature or functionality together.
I have earned the respect of my individual designers by deeply understanding their preferred design systems. On my current team, for example, we use MUI and DevExpress for our frontend libraries. Therefore, I familiarized myself with these preferred components within my first weeks on the job.
I came to the first design meeting and pulled up the Widgets Gallery as my visual aid to discuss how I wanted the Promotions Chart to look like the “Strip Lines” component. I wasn’t pulling something out of a random website where I liked how it looked — I worked within the constraints of the libraries our teams had already chosen as their “design language.”
I can offer the same level of courtesy for the brand guidelines, as well. If our marketing team has already determined the rules for colors, typography, spacing, and other visual elements, I can use those visual languages in our design discussions. Consistency can be a fantastic tool in the User’s Experience. These systems allow us a short-hand or an affordance for how to get things done within our applications.
As Product Manager, I do not necessarily see myself changing or even contributing to the design systems of a software. But once established, it can be my privilege to design application features and functionality with those design systems in mind.
To that engineering manager who was clearly confused about how much the Product Manager and the UX designer both care about user empathy and the user’s journey, I say this, “I don’t design the reusable components in a design system. I don’t draw the buttons, the layouts, or the typeface styles.” Instead, I get to use their design systems to solve my users’ problems and together we get to build a delightful experience.
