UX IRL Ep. 44: UX Help Desk 5

Hello! Here are our show notes for episode 44 of UX IRL: UX Help Desk #5. We hit the highlights in this article, but get the full context by listening to the episode:

We had so much to say in our last help desk episode that we didn’t get to everything! But that’s OK, we’re continuing in this episode. Picking up where we left off, we have three really interesting asks. If you have questions you’d like answers to, reach out to us on LinkedIn or social media. We might feature your question in a future episode!

As always, feel free to reach out to us on the zeroheight Slack community, (bit.ly/zheroes-signup), comment below or reply on Twitter @uxinreallife or Instagram @ux.inreallife.

Question 1

Our take

Michelle loves this question because it’s easy for her to answer. 😄 Based on her previous experience, she says, “Yes! Always have your components reviewed by a designer for a quality assurance gut check.” This is especially true for components in a design system — if it’s wrong, then it’s wrong everywhere. But because it’s a reusable component, when you fix it once, it’s fixed everywhere.

In terms of a process, this is how she managed the design system team at Citrix. They had a recurring maintainers meeting with designers and engineers, where they’d review any component changes. If the change was minor, we could do a quick inspection at the meeting. If the change was more complicated, a designer would do a deep dive later and work directly with the engineer on any changes.

If there are changes, they would note any changes in Jira, so the work can be associated in a sprint, pull requests, and other housekeeping needs.

For the first time the team does this, she notes it’s helpful to have design and engineering sit together, so the designer can walk through how they’re approaching the review. Having these conversations helps design and engineering build empathy and understanding for one another’s work. It can even help engineers be more aware of design details, too.

As you’re doing this, Mary Fran recommends checking to see how teams currently do reviews and if there’s anything already established to make it easier to follow or adapt.

In terms of tools, the Citrix team used Storybook, which renders a view of the component and allows you to alter them. For example, if you have a form field, you can experiment to see what it looks like with a short or long label, an error, if it’s required, etc. The designer would use that in combination with Chrome’s inspect tool to double-check that the right color, styles, or tokens were used.

Question 2

Our take

Mary Fran notes that it seems like product vision and strategy is getting put on design because the management consultancy isn’t working at that level. While design should be involved, it should be a team effort.

She also calls BS on titles. She’s worked at a variety places where the title “PO” means different responsibilities. It can mean someone is only focused on project management tasks. In other places, it could mean the role advocates for the product and helps determine its strategic direction.

She likes that you recognize this gap and definitely encourages you to call this out to whoever was in charge of hiring them.

We also note that while you and the team might be invested in the product, you might feel responsible for ensuring its success. We’ve been there, but we also know that you shouldn’t feel compelled or obligated to make up for this gap because it can lead to burnout.

In Michelle’s experience, she says this is classic management consultancy. She notes that consultancies, from her experience, can go two ways — either really well or really bad, and there’s no in-between.

Embedded consultancies, where you’re an individual contributor on a team seem to work out much better. We’ve both participated as consultants this way and vice versa with relative success.

However, Michelle’s experiences with management consultancies have been lackluster. Something that resonated with her over the year about this was a quote from Dan Klyn at his information architecture workshop. He mentioned, “Consultants are there to read you the time on your watch.” While you have the tool and can use it, a consultant is just going to tell you what you already know — and you have to pay them for it!

She’s noticed that management consultancies are really great a biz dev, but when it comes to the actual executable work, there’s a lot to be desired. Any experienced IC can easily detect this bullshit since we’re most familiar with the executable work.

In these situations, it’s important you bring your concerns to your manager so they can be addressed. Sometimes, it’s a good catalyst to reset expectations. Other times, it’s too late to do anything. If that’s the case, you might have to take this as a lesson learned for next time.

It’s also worth recognizing that at bigger companies, consultancies and other vendors must go through your company’s approval/procurement paperwork process. So the next time you need a consultancy, your company will recommend pre-approved vendors. We recommend that it might be worth the fight to find a different vendor so you can avoid this again.

Question 3

Our take

Michelle tackles this as our resident design systems expert. 😉 It’s our favorite answer — it depends! We recommend that a few more things need to be understood before deciding because it could go either way.

In Michelle’s experience working with several design system teams, everyone is trying so hard to make one unified design system. And it’s so difficult to do so. It’s rare to have companies that want to diverge.

To help you figure out what’s best, she recommends asking these questions or considering these scenarios:

• How important is consistency with the brand, even if it’s two different products for two different audiences?
• If you add a third product, what should that align to? Would the expectation be to create another design system?
• Maybe it’s not about creating a completely separate design system. Instead, it’s about having a base system, but each product might have differences to fit their unique needs. Consider how all Google apps follow Material design as a base. But Google Docs has different elements compared to Google Maps because they have very different needs.
• Theming might be an alternative approach that could provide consistency, but also flexibility. One example is Nordstrom and Nordstrom Rack are very similar from a foundational perspective, but they use different themes (e.g., different colors, fonts, etc.).
• Lastly, consider who’s working on the design and the development of the products — are they the same team or a different team? Will adding another design system create more work and add more friction?

What questions do you have?

Let us know by commenting below, and maybe we’ll answer in a future episode!