Designer spotlight: Pavika "PJ" Buddhari deep dive
PJ dives into what it's like to work in client-oriented environments, and how design system teams empower other designers in an organization.
Last week, we met PJ Buddhari, design manger of design systems at Adobe, and learned how she journeyed into design, which you can read about here. Today we’ll be diving deeper into her experience
working in client-oriented environments, and
building and maintaining design systems.
Next week, we’re entering the realm of designing for web3 and venture capital with Yang You, Head of Design at Paradigm, a research-driven technology investment firm.
Working in client-oriented environments
My first job was as a brand marketing designer for a small consulting agency for health digital health projects. That’s where I learned and discovered UX design as a field.
I realized I enjoyed solving problems and learning about UX. I still wasn’t the most confident that I wanted to do this for sure so I moved to freelancing to explore more.
What are the pros and cons of designing at an agency?
There is a lot of room for big ideas and brainstorming, which you don't always get in a larger company. You’re always working with the same groups of people, but on different problems. The range of problems is interesting and exciting.
On the flip side, you don't always get to see your work through. You deliver ideas, proposals and plans. You're also not on projects for very long.
What kind of projects did you work on at the agency?
Our agency was small and focused on clients in the health care industry looking to get into the digital health space or larger companies looking to spin-off experiences for their presence.
One project was around genetic testing and how to surface results in a non-scary way. You can't say, “You're going to have cancer,” because that's not true. How do we communicate how useful this data is but at the same time, be human about it? Not using red to call out the risk was a thing. We explored showing a percentage, but it came down to communicating clearly with words to tell the story accurately. Then we offered something you can do about it, like set up an appointment or read more about what this means. We also balanced it out with other facts you can learn from genetic testing to paint the whole picture.
Then there was also improving or redesigning some older, larger companies’ websites, health portals and the like.
How did you find clients during your time freelancing?
The people at Medullan, the agency, were connected to the Boston tech industry, and referred me to people that would reach out to them. I ended up doing some work for Medullan as well.
From college too, the MIT network helped too. I also reached out to companies with contract positions on AngelList. Mostly people knowing people helped me a lot.
What were your major takeaways from freelancing?
It’s very tiring. It's a lot of work because you don't have a team to rely on. There’s a lot of work that's not just designing that I didn't particularly enjoy.
I did a bunch of non-UX projects too, like illustration and animation. Those made me realize that I prefer to appreciate them rather than do them myself. It helped me answer that I wanted to stay in the digital product design space.
My biggest takeaway was that I enjoy having teammates, people to bounce ideas off of, and being part of something, rather than being the solo one.
But it was very valuable for me, because I wouldn't have gained that confidence to try it out. I'm not sure if I had that moment now, that I would have been able to get myself to take that risk again. Looking back, I was very brave.
What was the hardest, non-design part of being a freelancer?
The whole phase before you commit to a project, the back and forth. How do I talk to people? How do I make sure the contract is written in the way I would like? Do I provide the contract? Do they provide it?
How to define the deliverables was hard too. Depending on who you work with, some people just want your help, some people want a certain number of hours, some want extra hands, and some want a final deck with specific things in them. You have to know how to get that information out of clients too, because they won't always know what they want, especially smaller start ups.
What were the hardest types of freelance projects?
The hardest ones were helping with non-defined things and being strict about my hours.
As a younger person with not much else in my life that I have to leave work to take care of, it was very easy to work more than 8 hours a day or work on a Saturday if I really wanted to. Literally the more I worked, the more I was paid. Making sure I defined those and learning to communicate was not intuitive for me.
Some projects went on longer because I felt like they needed the help and they asked me if I could work more. Although I was getting paid to do it, I could have stopped to focus on finding my next project. It's always hard to say no.
What did your work schedule as a freelance designer look like?
I wasn’t working the whole time, I would take breaks or vacation, but I always had something planned to start next.
My work schedule was not very healthy. I always had a project, but because I was learning in the moment, it was hard to know how much time something would take. I was working a lot of more than I should have because I was worried when something didn’t look perfect. I wanted to show that I could do more because I wanted to leave a good impression.
I worked at home too. It was hard to stop, so I worked nights too. It was as if I was back in architecture school in some ways.
Building and maintaining design systems
I ended up in design systems by chance. I applied without realizing that design systems was going to become a hot thing.
What do design system teams do?
The most tangible aspect that people outside of a design system teams can see and touch are our component and pattern libraries and documentation. Whether it’s as a UI Kit in your design tool, or in code as a component you grab, or as a website that explains the standards, we provide that shared resource of how our experiences should look, feel, and behave.
That way product designers and engineers can focus on what they do best, which is designing the actual product flows and features, rather than worrying about what a drop shadow should be or what a form should look like. We get out of the way, help them move faster and be able to focus on their product.
How does a design system team work?
Something that is less visible is the communication and process design involved. My team helps set the standard for how our peers should work. For example, what does the communication between a product designer and their engineer look like, how can we improve what happens today, as well as come up with ways to engage with the rest of the company. It’s all communication, which is always surprising to people moving into design systems.
Our team specifically, we have multiple touch points, or ways of engaging others, such as:
a self serve way in the documentation itself,
video tutorials to onboard someone,
casual channels like Slack to ask questions,
office hours to help people through challenges, as well as
formal collaborations meeting regularly with specific teams to work through larger initiatives
These touch points not only help us spread awareness and educate others about the system, but are also a great way for us to receive feedback and understand the challenges people face when using our current system so we can further improve it.
What does shipping a new component look like?
It looks different depending on who you talk to because we work with so many different frameworks.
Regardless of the implementation, it usually starts out with defining the requirements, like what does it need to be able to do. We also list out any known problems or challenges because there is usually already product context or existing things we can pull from. Here is when we usually highlight specific areas we want to explore during the design phase.
During the design phase, apart from mocking up the different states, edge cases, and various known contexts, we also start drafting out the design API, which isn’t tied to a specific framework or tech stack.
We also start drafting the documentation itself with guidelines and do’s and don’ts in a rough draft with bullet points. Writing this draft has become such a valuable step for us because it allows our ideas that’s in our heads to be captured on paper, so fewer things are up to interpretation. This way, key stakeholders and cross-functional partners can start reviewing what’s being done early on to ensure we’re all on the same page. The last thing you want is you design something you totally misunderstood.
Once the designs are further along we start defining design tokens for a component or pattern. These are essentially design decisions captured in data form, for example the minimum width of a button. Engineers can then take this information and turn them into whatever they need. Our UI kits are also connected to these tokens too.
How do you work with engineering to bring a design system into production?
Our team has come a long way in terms of how we work together with the various engineering teams.
It’s not a strict here-you-go, never-talk-to-you-again type of hand-off. We have engineers in the room early from the moment we start defining requirements. For example, having the design API defined early during the design phase has really helped us because it’s allowed us to have a shared language when talking about components. It really helps us communicate clearly these ideas and behaviors that were previously harder to describe or overlooked when you’re looking at a static mockup. For example, how does this label overflow, does it truncate or wrap? Or is the maximum-width of a tooltip fixed or customizable? Little details written in table in the form of an API has helped both designers and engineers.
Ultimately, fostering a close and comfortable relationship between designers and engineers, where there’s mutual trust, has been very important to the success of our team. It’s important have constant dialogue, rather than a hand-off, where it’s more set up to get in a you’re-right-I’m-wrong argument.
What’s the hardest part about working on a large design system for a large organization?
The biggest challenge is trying to come up with not just rules, but also a flexible system that works across our ecosystem. I don’t think we’ve solved it but it’s we'll continue continue to work on.
The hardest part of our job is knowing where to focus. Adobe is really big and very old, as well. You have both products that are built 20+ years ago and products that are brand new. It’s knowing where we can make the most impact and change, and how we can partner with those teams.
What’s the main difference between a design system for a large organization versus a small startup?
The main difference is how our products span such a wide range. The Creative Cloud side of Adobe is already a big range. You get screen design and graphic design tools all the way to dense 3D or After Effects type animation controls which are very different from what we may find in Lightroom or Photoshop.
On the other side, there’s also Acrobat for document reading to marketing, analytics, and that world. That’s a big range of products, market, and users.
We are multi-platform, whereas a smaller design system can probably have a stronger opinion on when to use this one component for exact use cases. The level of strictness could be different for a smaller one.
Prioritizing what to work on for a smaller design system is probably easier than for us, where it's never ending.
What makes a good design system component?
A button is a button.
It doesn't matter whether it's Adobe or not Adobe, a good component is one that is flexible enough to be used and reused for whatever use cases it needs, as well as accounts for all the things that, say a product designer, might not want to have to care about.
For example, keyboard interactions, how it scales, how it reflows responsively from desktop to mobile. How would screen readers see this component? Where should I be using this component over another component? Those are questions that I hope product designers don't have to spend time thinking about.
How do you know if a design system is working well?
There are creative ways of measuring how something is doing well or how much it's being adopted throughout the company. You could look in code how many people are using something.
What I find the most valuable is when we actually talk and interview people at the company.
When I first started, we did interviews with fellow designers and design managers to walk through their day-to-day workflow to understand how they know what to do, where they grab say, a text field, and then where do they go. It taught us so much. People were going to different places. People were recreating UI kits for their teams. Our website, people always go to it, refer to it, and send links to it when others ask questions. That’s how we know it holds a lot of value and people trust it. Having these insights was so valuable.
When is the right time to have a design system?
It's never too late. Maybe there is such a thing as too early.
If you're trying to discover what your product is, it might not be the best use of your time for a smaller company. It doesn't hurt to start with some standard stuff like a button rather than recreating it every time.
When you're starting, just start with something—even if it's just a component in a mockup of a UI kit. A component in code that's documented and visible to those you are working with goes a long way. It doesn't have to be on a flashy website or have tokens. Start something and communicate it out.
People in the design system community geek out on tooling and all of that, but as a small company or team, you don't need all of that. You can always improve it.
It's going to be a living, breathing thing that you continuously touch and improve and grow. There’s always room for change. We've gone through a lot of different token systems, colors, ways of doing things, websites. Starting simple is good.
That’s a wrap! I hope you enjoyed our conversations with PJ.
Stay tuned for the fifth and final interview of this topic arc on core design skills. We’ll be hearing from Yang You, Head of Design at Paradigm next week.