Pursuing Design Quality

Hello, everyone.

Everyone hear me okay?

All good?

Cool.

Thank you so much for having me today.

I'm Jina, my pronouns are they or she.

And I am delighted to present today with you.

I love coming to Sydney.

I also love coming to Web Directions.

This isn't my first Web Directions.

Really great series of events.

And I'm really stoked that there's a design systems track now.

It's for us.

I really love the design systems community.

And I did.

I know they were just mentioned, but I did want to mention a couple resources that are really important to me.

The Slack, I honestly feel the Slack is probably the number one resource I would recommend in this community.

They're like, thousands of people in there, but it's actually not too noisy or busy like you would expect of a slack of thousands of people.

It's just been around for a while.

It almost self moderates itself.

I have a great community of admins.

So many topics, like process tooling, city focused channels, so highly recommend it.

If you can't get the QR code, I can invite you, or anybody who's in the Slack can invite you, we can get you in there.

And then, yeah, my, my conference next week, which is why I have to leave tomorrow, sorry, Clarity.

Obviously it's probably short notice to go, but I hope to see you at a future one, and you can join us.

So today, I want to talk about design quality.

Now I've seen some folks share negative thoughts on Twitter and other channels about, quality not really being something that you can achieve, and that it really shouldn't be a goal with design systems.

And I think when you use it in this type of phrasing of achieving design quality, it does feel a bit off.

Actually, I'm going to pour myself a water real quick.

Give me one second.

Oh, there's one poured already.

Yay!

Great.

How does one achieve quality?

Quality isn't a finite thing.

And if you ask a few different people what quality means to them, you'll get widely varied answers.

Is it even worth it?

That's why I didn't call this talk Achieving Quality, it's called Pursuing Quality.

For me, design quality is a standard of a designed experience as measured against other designs.

It's the degree of excellence of a design, not just in how it looks, but also in how it functions.

I heard a question yesterday that was like, is it function or design?

I was like, wait, but design can include function.

I think, design is definitely not just a visual thing.

And so when I think about quality design, I don't really think of it as like it's just a luxury.

I see it as essential.

And I think that we should all be striving towards pursuing design quality in our work because it has an enormous impact on people.

People rely on designed experiences every day to make their work or their lives easier or more enjoyable.

And so depending on what this designed experience is that you're working on, achieving, actively working toward quality can impact improved usability, increased satisfaction, reduced development time and effort, it could be improved safety and security, could be brand perception, and so much more.

It's, and it's going to be tailored to whatever it is that you're working on.

And another reason that I say pursuing design quality Is that the work is a continuous practice, just like design systems.

And it's never done.

There are always going to be new challenges to face and new ways to improve the experience.

And so to me, it's a big part of design systems.

And to ignore that makes me wonder why you would be doing design systems in the first place.

And maybe you just really love designing buttons.

And you've had your 500th button by now.

And if that's you do you.

I'm not going to judge you for that.

But for me, I like to say design systems are for people.

Not just the people that we work with, but the end user experience.

I wanted to share a few key things that you can do to make pursuing design quality a part of your process.

The ultimate thing that you can do to pursue design quality is to create a culture of quality in your organization.

And this means that everyone is aware of the importance of design quality and is working to achieve it.

One way to do this is to make it part of your product development process, and by having design quality as one of your key objectives, you're reminding everyone that it's important.

You can create a design quality criteria document that will outline what that criteria is, and when I say document, I'm not necessarily meaning like you're going to write like a 300 page textbook.

It could just be as simple as three to five slides.

It could be a fun poster that you put on the walls.

It could be pretty like concise and straightforward.

But it would be used as a guide for your team to measure success.

And if you have design principles or experience principles, you can derive your criteria from those.

For example, at Salesforce, we had four design principles that we used to guide our design decisions, and the first one is clarity, which is a coincidence that my conference is also called Clarity.

I had the name first.

But, I think just clarity was so top of mind for me that, yeah, it just happened.

The idea around clarity as a principle is to eliminate ambiguity, enable people to see, understand, and act with confidence.

Efficiency was around streamlining and optimizing workflows and intelligently anticipate needs to help people work better, smarter, and faster.

And then consistency around, familiarity and strengthening intuition by applying the same solutions to the same problem.

And the fourth principle is beauty.

Demonstrate respect for people's time and attention through thoughtful and elegant craft.

Now the order that I gave that to you was in a very intentional order, and so anytime we would list anything really, we always would put it in like a priority order.

So if you were like to have a design debate and maybe you're arguing, hey, this breaks consistency, and that's one of our principles.

But actually doing this change would actually improve the clarity or, the efficiency then that decision would actually win.

And so it was a way to help, guide you through the process.

And so the design principles became an actionable, tool.

So when I was at Asana, I was a manager of a team of designers that were focused on design systems, accessibility, visual design, and mobile foundations.

And the director I was reporting to asked me to come up with a criteria for what would be Asana design quality.

And this was what I would usually do, you would hear like in design critiques, this doesn't meet our quality bar.

But there was no quality bar to point to, and so it just felt like this, myth, like this quality bar that doesn't really exist, so I set out to help try to fix that.

I started by looking at Asana's experience principles, and I'm not allowed to share all five of them, cause, some of it's under NDA, but I was given permission to share a couple of them with you.

And so the ones I can share is, to provide value for every offering.

We deliver a high quality experience at every tier and a clear understanding of our paid feature set.

And to lead with an opinion, based on customer insights, have a strong viewpoint.

Guiding our customers will help them be more successful in the long run and will be the co pilot for their team's, success, right?

Opinionated by default, but flexible under the hood.

So those two principles, along with the secret three that I can't mention, hee, it gave me a sense of what was important to Asana, like what was important to their mission and their vision.

And so I spent time researching various quality definitions and rubrics that I could find online.

A lot of these things aren't published online because people try to hold those kind of close to their chest.

But for what I could find online, I did a lot of reading and understanding what people, had done prior.

I also brainstormed terms and definitions around quality that would align to Asana's objectives and I ran them by, tons and tons of people at Asana, various stakeholders.

And there were a lot of stakeholders to talk to.

You had PMs, you had other design leaders, engineering partners, user research, data science, and so on.

And I received a lot of input.

And some of the input was in conflict with other input I received because I kept getting conflicting opinions and differing expectations of what this work should entail.

And fortunately, at Asana, they had a framework for giving feedback that helped me process all of this feedback that I had received.

And they call it do, try, consider.

And the way it works is like when you receive, or when you give feedback it should always be framed as a do, a try, or a consider.

Now if you have a do, this is mandatory.

It also should be very rare that you give a do.

This is like show stopping, like absolutely critical, we cannot ship without this.

The try is like explore next step, give it a shot, see if it works.

And then consider, think about it.

You don't have to try it, but at least consider it.

But no further action is required.

By having this framing, I was able to understand, what really was, like, important to the various stakeholders.

I, made a bitly to an article they published, if you wanna, Read more about it, so it's bit.ly/dotryconsider.

So after iterating through lots and lots of feedback, I finally landed on a criteria that we could all align on as an organization.

And I was given permission to share those with you as well, and I'm so glad because I wrote them, so here they are.

The first category in the criteria is inclusive.

To build toward our mission of enabling all the world's teams to work together effortlessly, we need to account for the needs of all people.

We want our design to be inclusive of all people using our products.

There's a lot of text here, so I'm not going to read everything, but I can share slides later if you want to read them.

But this was, like, really important.

So this included Accessibility, but then took into account other aspects like diversity, localization, even like mindfulness and digital well being, because it was a product people would be using every day in their work, and so it included other facets, but the core of it was around accessibility.

The second category is intuitive.

When our customers feel confident in their actions, next steps, and decisions they make when using our products, they are better able to achieve their goals.

The third category is reliable.

We protect flow by building a seamless product that helps customers perform tests quickly and easily.

I will mention in the second paragraph, one of my favorite things outta Asana that they would say a lot was like, we wanted to reduce work about work.

How many times do you find that at work you find yourself doing work about work, but not actually doing the work?

So I was, I'm a big fan of that phrase, and I repeat it now and since, I've, moved on from Asana.

So it stuck with me.

The fourth category is cohesive, so similar to what I mentioned earlier with the Salesforce principles, but I liked cohesive better than consistency, because it was really about achieving unity without over indexing on uniformity.

And then the fifth category is delightful.

Delight is when a customer feels empowered, motivated, and rewarded when using a product.

So priority order, again, inclusive, intuitive, reliable, cohesive, delightful.

And.

Even though we had this criteria in place, we had a lot of work cut out for us to meet this criteria.

But it was like setting an intention, like we knew it wasn't going to be a night and day, overnight change.

But we now had a vocabulary that we could use in design reviews, critiques, and so on.

So then I took the Asana experience principles that I mentioned earlier and mapped them to the design quality criteria.

For example, provide value for every offering.

I felt all the principle, or all the criteria of inclusive, intuitive, reliable, cohesive, and delightful mapped to that.

But then for another example, lead with an opinion, I felt inclusive and intuitive was more tightly mapped to that, where the other criteria may be, less so.

The purpose of the exercise was really to understand, our purpose, like, why are we making this criteria?

So with your criteria in place, you can create a feedback process, if you don't already have one.

Asana's do try consider one, I think is a really good one.

Maybe you have your own, maybe there's others you've tried.

I think the important thing is to make sure that everyone is speaking the same language.

I find a helpful self serve way to help everyone apply this criteria is having design quality checklists and this could live inside your Figma library if you have stuff in Figma.

If you have stuff on a website, you can put it there, but the important thing is like where the people are doing the work, that's where you want to surface it.

You don't want to create like a new destination because then it's one more thing that they have to go to, but if they're already in Figma, then you put it there.

Similar to like a, what do they call it, in GitHub, a commit check, if they're already in code, you can put it there, where it makes sense.

Checklists won't solve everything.

It'll help you get a lot of things, like the, low hanging fruit, but there's still a lot of things that are a little bit more intensive and might take on, fuller projects.

I think the way to really determine the success of these things is by establishing goals and metrics, and there were a couple of talks yesterday that touched on this, I won't dive too deep into it, but I think, when you're measuring design quality, one way of looking at it is like, what kind of user feedback are you receiving?

Are people happy with the design?

Are they able to complete their task, easily and efficiently?

And just a couple examples, like if you're looking for a more qualitative, feedback, you could do that through surveys and, one of those goals might be to increase customer satisfaction with the design of our product.

If you're looking for more, quantitative data, this might be more, around, issue tracking, for example, reduced number of accessibility related issues reported in the audit.

So you'll have, a mix of qualitative and quantitative.

I think it's important to note that some of the things that you track will be a moving target.

For example, your accessibility compliance criteria probably get updated as the accessibility standards evolve.

So you view your design quality criteria more as milestones.

Instead of like a single target.

And once you have your goals and metrics, you might even create a design quality rubric to assess against.

And usually that would mean you would have on a scale of one to five, and you might have a specific set of tests in place to determine that score.

For whatever it is that you're testing for, of course, I always want to recommend to test early and often.

And that's whether it's automated tools that help find and fix issues, or people driven testing through, UX testing.

Both are essential.

And you're in the design system track, so I don't think I need to tell you this, but just in case, have a design systems practice.

They're an excellent way to further design quality.

And, yeah.

That's why we're all here, right?

You probably don't need me to preach to you why they're important.

I think we know, but I think, without a design system practice, it's just going to be really, hard to achieve any of this.

Now when you ask someone what they think of when they think of design systems, they're probably going to mention some of the very popular public sites like Material Design, or Lightning, or Carbon, Polaris, and more.

But, I have a little tongue in cheek thing that I like to say and, wrote an article about this a little while back, but there is no design system.

And you're like, wait, what?

What I mean by that is that design systems are a methodology.

It's not like a thing.

Like a one time thing.

Like it's a, practice.

And I've been thinking a lot about, like, all these beautiful public sites that people put up.

And I love working, on them.

I love looking at them.

I think they're great.

But, are we putting our time and attention in the right place?

The representation of the system versus the actual system that needs the love.

It's just something I've been thinking a lot about lately.

And I've been thinking a lot about our tools that we use.

And can our tools Surface, better suggestions for accessibility, localization, usability, because it's all just based off of tools, and that's what I'd like to see more of.

I'm a big advocate for design tokens.

I could give a whole talk on just this alone, but I won't do that right now, but huge fan, but I think the gist of it is really around minimizing friction and confusion and communicating about design using a shared vocabulary.

And taking away the old school process of tedious specifications, which can lead to duplication, like at Salesforce, we had 106 text colors, we had 120 background colors, we had 73 font sizes.

We had a lot of work cut out for us, but tokens really helped us, clean all that up.

So I love methodologies such as tokens because I think they do more than just bridge an existing gap.

I think they actually remove the gap altogether by improving communication, and that's pretty exciting.

I heard Peter Michaels Allen refer to design tokens as a Rosetta Stone, and I thought that was really cool.

And then yesterday in Adekunle's talk, he mentioned the hand, hand off versus hand shake.

And I really liked that framing.

So I really want to see our tools move away from just bridging the gaps and just getting rid of them altogether.

This is part of the reason I'm a fan of the no code movement that's happening right now because it's really trying to bring people closer together.

Yeah, no more gap.

More of this, please.

And a phrase that we used a lot at Salesforce was, we wanted to make it easy to do the right thing, but hard to do the wrong thing.

And I think this approach can apply to design quality as well.

So creating a culture of quality is essential for providing great experiences.

And by establishing design criteria and having a feedback process, and using checklists, you can create a system where quality is the norm by having more inclusive practices.

So I ask, what are some steps that you will take to create a culture of quality in your organization?

As I mentioned, I am a design systems advocate.

I've been working on them a long time.

As mentioned earlier, back in 2004, all the way to, Google, where I got laid off earlier this year, womp womp, and I need a job.

If you're hiring and I can still live in San Francisco, let's talk.

Thanks.

Thanks.