In order to dazzle users on the surface, a site's internal processes need to work smoothly, too. Code needs to run seamlessly. Load times need to be kept to a minimum. And everyone who built that final product needs to collaborate behind the scenes easily and transparently. After all, a site’s design elements can only talk to each other well if the people who built them do, too. As much as a strong site is about layout, navigation, and aesthetic, it’s also about team harmony.
No one knows this better than Adekunle Oduye, design engineer at fintech company Plaid, who has previously built products for NASDAQ, Memorial Sloan Kettering, and Mailchimp. Though his title may be design engineer, Oduye is an example of how designers actually wear many hats: he’s a designer and coder, a people manager, and systems designer.
As he explained to Rob Goodman, host of Wix’s Now What? podcast, in a recent episode, a strong design system relies first and foremost on understanding people—both internal and external—and building bonds. Below, you’ll find some of our favorite takeaways on building harmonious design systems. Listen to the full episode here:
1. Build cross-company bonds
To build a design system that works well, all its separate pieces need to work well, too. Every company is different, so try to understand the unique needs of various internal stakeholders first.
“Build a design system that solves their needs, and then hopefully create a process that allows them to build a better product,” Oduye says. “At the foundation, it always starts with the people, understanding their needs, their wants, and their goals.”
2. Show the process
Bring in various stakeholders early and often, and show them your work as it progresses. This will give team members across departments a sense of ownership, build camaraderie, prevent last minute changes, and help other team members understand your role.
“Even if I'm creating a prototype or I'm creating some sort of component, I showcase the product to everyone,” says Oduye. “It doesn't matter if it's still a work in progress or if it's finished. Sharing the process will allow people to understand what a design engineer is, and what it entails, because it's just not just like building stuff.” It's macro-level problem solving, like a lot of design roles: asking questions, identifying problems, and finding solutions.
Bring in systems tools that minimize back and forth. According to Oduye, prototyping can smooth out the decision-making by injecting quantifiable data into the process and removing guesswork. “I like to prototype things out, show it to users, get feedback and then allow the data to figure out how we want to proceed.” Test a few ideas before moving forward with one.
4. Lose the jargon
Stakeholders from different teams will come to the table with different skill sets. So, speak to them in a language they’ll understand and find approachable ways to talk about technical aspects of your work, especially for non-technical team members. (Start talking in technical jargon to your project manager or CFO, for instance, and you could risk losing them right away.)
“I want to make sure to be able to make it as simple as possible, so that even if I brought my mother or sister and explained stuff to them, they could understand it,” explains Oduye.
To do this, Oduye employs references that just about anyone would be familiar with, like restaurants or recipes. “Showcase a lot of [your work], but also communicate in a way where everyone can understand what you're doing and the benefits,” he says.
5. Showcase your value
Sure, you’re a designer. But in order to get the resources and support your project needs, you also need to be a salesperson and showcase your worth internally. Have an answer ready for when your boss asks “why do you want to do this?” or “what’s its value?”
“You always want to try to sell yourself and be able to kind of showcase the value of your ideas,” says Oduye. “Whatever I do, I’m selling something.” This could also mean showing off your project’s results in a post-mortem presentation or email. After all, how will the rest of the team know the product was a success if you don’t share it?