Pursuing Design Quality


Jina introduces herself and the topic of design quality in design systems. She highlights valuable community resources like the Design Systems Slack and her upcoming Clarity conference.

Defining Design Quality

Jina discusses the concept of "pursuing" design quality as a continuous process, emphasizing its impact on user experience, usability, and brand perception. She differentiates design quality from achieving quality, focusing on its subjective nature and the need for a shared understanding.

Creating a Culture of Quality

Jina outlines strategies to integrate design quality into the organizational culture. This includes incorporating design quality objectives into the product development process, establishing design quality criteria, and using design principles as actionable tools.

Design Quality Criteria at Asana

Jina shares her experience developing design quality criteria at Asana, drawing insights from the company's experience principles and a collaborative feedback process. She emphasizes the importance of stakeholder alignment and provides examples of Asana's "do, try, consider" feedback framework.

Asana's Design Quality Categories

Jina reveals Asana's five design quality categories: Inclusive, Intuitive, Reliable, Cohesive, and Delightful. She explains each category's definition and their priority order, showcasing how these criteria served as a shared vocabulary for design reviews and critiques.

Mapping Principles to Criteria

Jina details her process of mapping Asana's experience principles to the design quality criteria, demonstrating the interconnectedness between company values and design decisions. This emphasizes how design quality criteria reinforce the organization's overall mission and vision.

Feedback, Checklists, and Metrics

Jina stresses the importance of establishing a robust feedback process using a consistent language. She recommends using design quality checklists as a self-serve tool, embedded within existing workflows like Figma libraries. She also highlights the need for establishing goals and metrics to track progress, utilizing a combination of qualitative and quantitative data.

Milestones and Rubrics

Jina suggests viewing design quality criteria as milestones rather than fixed targets, acknowledging the evolving nature of design standards and user expectations. She introduces the concept of a design quality rubric to assess designs against predetermined criteria on a scale, ensuring more objective evaluation.

Testing and Design Systems

Jina advocates for early and frequent testing using both automated tools and user-centric approaches like UX testing. She reiterates the importance of design systems in fostering design quality, emphasizing their role in creating a unified and consistent user experience.

Beyond Public Design Systems

Jina challenges the conventional perception of design systems as public websites, proposing that the true essence of a design system lies in the methodology and practice it enables. She encourages focusing on the internal system's functionality and impact over solely prioritizing outward-facing representation.

Design Tokens and No-Code Movement

Jina expresses her enthusiasm for design tokens as a powerful methodology to enhance communication and minimize friction in design workflows. She connects this approach to the no-code movement's goal of bridging gaps between disciplines, advocating for tools that facilitate seamless collaboration and reduce unnecessary handoffs.

Easy to Do Right, Hard to Do Wrong

Jina concludes by summarizing the key takeaways: establishing a culture of quality is essential, design criteria, feedback processes, and checklists are crucial tools, and inclusive practices are fundamental. She encourages the audience to reflect on their own actions to foster design quality in their respective organizations.

Hello, everyone.

Everyone hear me okay?

All good?


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.



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.


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.




Screenshot of the Design Systems Slack

A Design Systems Conference

Clarity is a design systems conference focused on how we work together. We provide tools and standards to scale across an increasing number of devices, platforms, and products. But real success comes when people align around a shared vision and language. Diverse perspectives for design, development, and product unite so more people can be a part of the conversation. At Clarity, we elevate our skills through multi-faceted inclusion, empathy, technology, creativity, and collaboration.

Screenshot of the Clarity conference website.


Pursuing Design Quality



An illustration of a small notepad with a spiral binding at the top.


Eliminate ambiguity. Enable people to see, understand, and act with confidence.

An illustration of a tall tower with arches, set against a dark gradient background with cloud-like shapes at the bottom.


Streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.

An illustration of a tall, pointed building with a gradient background transitioning from dark blue to a lighter shade.


Create familiarity and strengthen intuition by applying the same solution to the same problem.

Illustration of five colored houses in a row with a gradient sky background.


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

A silhouette of a cityscape at twilight with a prominent red bridge in the foreground and small stars scattered in the background.

Clarity > Efficiency > Consistency > Beauty

Asana Design Quality

design Jina Anne


1-3. [Redacted]


1-3. [Redacted]

4. Provide value for every offering.
We deliver a high quality experience at every tier, and a clear understanding of our paid feature set.

5. Lead with an opinion.
Based on customer insights, we have a strong viewpoint. Guiding our customers will make them more successful in the long run. Be the co-pilot for their team’s success. We are opinionated by default, but flexible under the hood.

Two beige speech bubbles pointing towards each other against a black background.


Mandatory feedback

Used very rarely.

"Do" feedback is appropriate when the quality bar impact or systems impact goes beyond the scope the team is responsible for.

  • Find a solution and implement it by the next milestone
  • Loop back with stakeholders if new information comes up
  • Usually takes, minutes, hours or days


Request a specific exploratory next step

eg. drawing some options or looking into the code to cost something. After doing the exploration, the team is empowered to decide whether to change course or not.

  • Share the exploration with stakeholders & let them know what you decide
  • Usually takes minutes or hours


Share ideas or alternate ways of thinking

After thinking through the point briefly and responding, the team is empowered to take the feedback or not.

  • Think about the feedback and respond, either in the moment or in a written follow-up
  • Usually takes seconds or minutes

The Criteria

The Criteria


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.

This is an iterative process, and we won't get there overnight. Accessibility (which the industry has been framing as part of the larger umbrella of Inclusive Design), is a long-term commitment that involves continuous improvement.

In addition to accessibility, we can make strides toward a more inclusive product by considering multi-faceted diversity, localization, mindfulness and digital well-being in our products, and more.

Asana Design Quality


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.

By creating an interface that behaves as expected and has appropriate feedback, customers can more easily accomplish the task at hand. As the product gets more powerful, it must become simpler.

We provide clarity by designing a more understandable experience, including content, hierarchy, and interactions.

Asana Design Quality


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

We reduce work about work and help people accomplish goals efficiently.

We minimize surprise by preventing errors and dead-ends, predicting common pitfalls, and offering smooth recovery to build trust that Asana is the right tool for the job. We also do this by increasing the performance (speed) of our products. And we ensure reliability to maintain our customer’s trust.

Asana Design Quality


We create a familiar experience by having strong consistency standards that enable us to deliver innovative and creative products. We help customers learn our product through consistent patterns — it feels “learnable.”

This experience is seamless cross-platform, while feeling at home in their respective device and platform contexts.

We can achieve unity without over-indexing on uniformity, so we can create a product that feels polished and professional.

Asana Design Quality


Delight is when a customer feels empowered, motivated, and rewarded when using a product. Our customers should be satisfied with our products’ excellent craft, taste, and aesthetics. They delight in our thoughtful and clever interactions and transitions.

We ensure added delight feels meaningful by aligning it with an action that deserves celebration.

Customers enjoy using Asana to succeed in their work.

Asana Design Quality

Priority Order

  1. Inclusive
  2. Intuitive
  3. Reliable
  4. Cohesive
  5. Delightful
Asana Design Quality

Mapping our Quality Criteria to our Experience Principles

Provide value for every offering

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






Lead with an opinion

Based on customer insights, we have a strong viewpoint. Guiding our customers will make them more successful in the long run. Be the co-pilot for their team’s success. We are opinionated by default, but flexible under the hood.

Asana Design Quality



Two hand symbols: one giving a thumbs up and one giving a thumbs down.


  • Run accessibility audit.
  • Check performance metrics.
  • Dogfood the changes.


Reduce number of accessibility-related issues reported in the audit.

A black slide with a simple tan-colored target graphic in the center






Chart displaying five categories (Inclusive, Intuitive, Reliable, Cohesive, and Delightful) against a five-point scale with varying check marks across the grid.


✔ Pass
✖ Fail

Two check marks: one for "Pass" and one for "Fail" in a list format


A color palette with four shades, text "Aa Bb Cc" representing font samples, and a button labeled "BUTTON".

updating UI when you don’t have a design system:

An animation of a SpongeBob SquarePants cartoon character struggling to perform multiple tasks simultaneously, including ironing, ironing clothes, and vacuuming.







This slide features six screenshots of various design system websites. The screenshots are organized in two rows. The top row includes the following design systems, from left to right: Google Material Design, Salesforce Lightning Design System, and IBM Carbon Design System. The bottom row includes Shopify Polaris, Adobe Spectrum, and GitHub Primer.


A scene from the Matrix where Neo is told by a guru-like child there is no spoon.


The slide includes an illustration with pink and green stick figures and an arrow pointing from the pink group to the green group, indicating a handoff process.

Headline - Regular 18sp

The slide has an illustration of text layout guidelines with measurements
106 unique text colors in a grid.
73 unique font sizes.


A slide with two groups of stick figures on either side of a chasm. One group on the left has pink stick figures, and the group on the right has green stick figures. A green bridge is depicted between the two sides.



Drake meme where 'handoff' elicits disapproval, and 'handshake' approval


Illustration with several pink and green stick figures arranged unevenly on the left side of the slide.

Easy to do the right thing

Hard to do the wrong thing



A timeline featuring logos of companies (Oden, Apple, Crush + Lovely, Engine Yard, Do, Sass, Salesforce, Amazon, Consulting, Asana, Google) and corresponding years (2004, 2007, 2009, 2010, 2012, 2013, 2014, 2017, 2018, 2020, 2022).