By Róisín Bowden, UX Researcher, Workday

Introduction

Have you had a moment in your career when you’ve needed to communicate with human resources? Perhaps you needed help from HR when you were experiencing a significant life event. This might have been for something joyful, such as preparing for the arrival of a new baby. But maybe it was for something that provoked more challenging emotions, such as a health issue. In these situations, you needed emotional intelligence, confidentiality and reassurance from HR, rather than simply an exchange of information.

As a UX researcher, I was recently confronted by these challenging emotions of our users. While working as part of a multidisciplinary product team, our objective was to create the employee experience of reaching out to your HR team for help. It was clear from our initial user interviews that understanding the full range of emotions they encounter at work was crucial to providing them with a successful user experience — we needed to design for emotion to build the right experience.

Enter Mindsets

We set ourselves the goal of creating an empathy tool that would allow us to consider the full range of emotions of employees at work. A “mindset” is ideal for this purpose, as it visually represents a range of emotions experienced by the user when they interact with a product. This artifact can then be used in design and research activities to ensure we consider the full emotional range of our users and prioritize our product work. It allowed us to wield empathy by spending time in the mindset of our users. This is our interpretation of mindsets:

We chose to focus on intensity of emotion and time pressure. From our research, we knew these two traits had the most impact on employees’ mindsets when they are reaching out to HR. From these traits, we then created a graph of four mindsets that represented emotional states relevant to the experience we were creating. Each of the four mindsets had a number of associated scenarios that emerged from our initial user interviews. For example, here is a scenario for the distressed and stressed mindset:

You have been experiencing persistent stress at work, which is affecting your everyday mental health. You’ve tried to speak to your manager about this, but nothing has changed. You are feeling anxious and exhausted and you urgently need to speak in confidence with someone in HR.

Imagine you are in this mindset; these emotions would most likely have an effect on your cognition and you would require a different experience from the product than if you were in the rushed but feeling fine mindset. Incorporating mindsets into our design development empowered us to incorporate emotion-driven design into our employee experience.

The Power of Mindsets

Mindsets were uniquely appropriate for this design challenge, because they take into consideration the swiftly changeable nature of the user’s emotional state. Our emotions are constantly in flux. By choosing emotion as an essential trait for our mindsets, we could incorporate the changeable nature of our human emotions into our design process. No employee is in one mindset all of the time; they shift between mindsets as pressures and emotions change over the course of the week, day, or even hour. In this way, mindsets distinguish themselves from other empathy artifacts, as they have the power to capture emotional shifts over shorter time intervals.

Because of their ability to capture changes in emotion, mindsets are a powerful compliment to personas. Personas are without a doubt an essential tool for capturing the behaviours, needs and goals of the user. However they remain static over time, and as such cannot capture the pressures and emotions the user is experiencing in any given moment. Mindsets make personas dynamic.

For example, imagine a product team with three personas representing their users. Each of these personas experiences their own time pressures and emotional states when interacting with the product. The team could create mindsets for each persona, adding a powerful layer of emotional understanding to each persona. Alternatively, they could decide that all three personas experience a similar range of pressures and emotional states. In this case, the team could create just one mindset that spans across all three of their personas. In either case, the addition of mindsets would add a powerful layer of emotional understanding to the team’s existing research artifacts.

How We Used Mindsets

Mindsets for Generative Research

The simplicity of our mindsets meant they were versatile enough for us to incorporate into a variety of design and research activities. One example is how we used our mindsets during a generative research workshop. The aim of our workshop was to understand how the employees’ desired experience changed while interacting with our product, depending on which mindset they were experiencing. First, we asked the participant to embody one of the mindsets, perhaps by remembering an experience of their own that they’ve had in this mindset. Next, we presented them with a common scenario which would likely evoke this particular mindset. Finally, we asked the participant to walk us through what their ideal experience might be when reaching out to HR. For example, one participant imagined themselves in the distressed and stressed mindset, experiencing a sudden bereavement in the family and needing immediate time off work. The journey they constructed revealed to us how their desired experience was distinctly different from that of an employee who simply needed HR assistance.

Mindsets for Design Ideation

We also applied our mindset artifacts effectively during the early design stages. In one of our design ideation sessions, our goal was to quickly produce a large number of ideas that would form the basis of our employee experience of communicating with HR. First, we chose the mindset that we decided was a priority to design for in this session. Then, we chose a scenario that would likely evoke this mindset for our users. Next, we chose a flow that the user would frequently encounter. Finally, we set a timer and sketched our design ideas as quickly as possible! In this situation, the mindset allowed the team to quickly empathise with our user’s emotional state in a specific moment. Here, the use of mindsets provided focus for our design work, allowing us to generate a large amount of ideas for a range of emotional states. Also, by focusing on the mindset of our user rather than their job role, we found our own mindsets were more open and empathetic, which unquestionably contributed to our creative thinking during the session.

Mindsets for Prototype Validation

One final example of how our mindsets allowed us to see our designs through a different lens was how we incorporated them into prototype testing. While crafting our tasks for a prototype test, we decided to create tasks based on the variety of mindsets the employee might experience when interacting with this prototype. For example, one task was based on the sensitive self-carer mindset, in which the employee needed to reach out to their HR team to discuss their work leave options due to an underlying health condition. This allowed the participant to easily understand the emotions they might feel when faced with this task. The participant then drew our attention to the need for confidentiality within the interaction with HR, an insight that validated our previous assumptions. As the prototype we tested was designed with mindsets taken into consideration from the start, incorporating the mindset into our prototype testing allowed us to validate this work. This ensured we designed for emotion iteratively throughout the design process, and not just the early brainstorming stages.

So why is designing for emotion important?

From these examples, it’s clear that using mindsets was crucial to the success of the product, as it allowed us to design for the emotions of our users. But why is it important to design for emotion when designing software for the workplace?

Because emotion-driven design is one step towards enabling workers to bring their full selves to work. In our modern workplace, many of us believe that expressing emotions is unprofessional or out of place. As Don Norman points out in his book Emotional Design: Why we Love (or Hate) Everyday Things, we often pit cognition against emotion and consider emotions to be out of place in polite society. But emotions are inseparable from and a necessary part of cognition. Therefore how can we expect our users to feel empowered to bring their full selves to work, if our workplace software does not allow for this expression of emotion?

I am aware however that designing products with emotion in mind can only go so far. Good product design alone cannot enable workers to bring their full selves to work; the culture of the organization must also empower users to do so. We can only expect our users to be vulnerable while using a product if they trust the organization will respond in an appropriate manner. But designing emotion into our products is a step in the right direction.

Next Steps

Through the use of mindsets and emotional design, we were better able to accommodate our users’ range of emotional states at every step of the product development process. However this experimentation with mindsets raised more questions that need further exploration. How can mindsets be designed so that they compliment personas? In which design briefs is it most appropriate to consider emotions of the end users, and when is it less of a priority?

How do you design for emotion in your own work? What form do your empathy artifacts take? We encourage you to try mindsets as an empathy tool if you haven’t done so already. We would love to continue this conversation and learn about the experience of the wider community.

Design for Emotion with Mindsets was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Carlos Yllobre Aleman, Senior Product Designer, Workday

This is the third in a series of articles about design systems thinking. Read Part 1 and Part 2 here.

Essentially what makes up a design — or any — system is the sum of its parts and the connection between these parts, working towards a defined purpose. This concept is clear but not complete. When it comes to understanding the system as an entity, we need to dig deeper and get to know those pieces and their interactions.

In previous articles, I have talked about applying systems thinking and following a useful methodology to build a system. This time, I would like to talk about the design system itself, as well as its parts.

Tokens

Everything starts here. Tokens are the beginning of everything — as fundamental as it sounds — since everything in a design system is made of tokens. That’s why any small change you apply to one of these could trigger a ripple effect in every area of the system and the product.

The concept of “design tokens” was created by the design system advocate Jina Anne to refer to those entities that store visual design attributes. Since then, the name tokens has spread across the industry to become the most common way to identify these pieces. But what exactly are tokens?

As defined by the Workday’s Design System team:

Tokens are the smallest pieces of our Design System. Their primary function is to store UI information that allows for building assets, components, and patterns at a sustainable scale while securing consistency across our platforms.

Based on this definition, 2 key metrics help us understand and define tokens:

1. A token is an immutable element that requires a well-defined and justified adoption and/or modification process.
2. A token is a raw material or tool we use to build more complex elements like assets, components and patterns.

Some examples of Tokens are a color palette, typography, spacing rules, or non-visual elements like motion guidelines.

Assets

Some designers and developers like to treat assets as more complex tokens, and they are not necessarily wrong since these could be managed in the same way based on their characteristics. However, I prefer to separate assets into their own category for two reasons:

1. To avoid confusion between the two since they might be used similarly but come with different building and intake processes.
2. To keep the concept of tokens as clean and close to its true nature as possible.

Assets are more complex UI units used in the same way as components but built with a fixed function or purpose. They depend on tokens in the same way as components, but they are built differently. Some examples of assets could be your icon library, brand assets, or illustration packages.

Components

The components are groups or blocks of tokens or other components built together with specific functional behavior that serves a variety of applications.

These are the building blocks and the most recognizable parts of a Design System, used by many product teams and therefore subject to more updates and modifications than other elements.

I highly recommend to organize the components of your Design System by doing 2 things:

1. Consider Information Architecture:

In my previous article about design system maps, I talked about the importance of counting with a taxonomy map to organize and better understand our systems. The components, like any other part of the design system, are not exempt from this. By creating “umbrella” categories, we make sure we cover different sets of components with similar main functionalities, separating them from other sets and identifying at the same time, types of components and their variations.

E.g. Use Simple architecture to organize components:

Category: The descriptive high-level bucket.

__ Type of Component: Needed for additional categorization.

____Variation: Prescribed alteration of the component.

2. Define Levels of Complexity

It is important to notice that not all components are the same. They present different characteristics and different levels of complexity. Because of this, we need to be able to define our components and organize them based on their nature and structure.

The levels of complexity we need to define will depend on the size and the type of Design System, but for most of the systems out there I would recommend counting with three levels of complexity to define their components.

Level 1: Standalone components made with tokens only.

Level 2: Components built by grouping Level 1 components together with tokens and simple interactions.

Level 3: Components built using other components in addition to logic and interaction metrics. Due to their complexity, some of these are covered under Patterns.

Patterns

Patterns are tricky to define, and this is due to their complexity and how they are created. Patterns are more related to solutions than to isolated elements in a system, so even though they could be created and curated by the Design System team, the norm should be that Patterns are created and fed back into the system by those solving the problems in your organization: the product teams.

Patterns consist of a reusable collection of components that can be defined by their respective interactions when solving a design problem. These need to be adopted and documented as business cases and together build a consistent and robust ecosystem.

Based on this definition we can provide with 3 key metrics that help us identify and validate what a pattern is:

1. A pattern is a solution to a common design problem, always linked to a business case.
2. A pattern needs to be reusable and linked to components. This is not always the case, but it is where the main value is for product teams.
3. A pattern must document and provide guidelines about how the problem was solved by the product team.

Pattern vs Complex Component

It is common to have some confusion when talking about complex components and patterns; that’s why I want to shed some light here. Patterns and components are intrinsically related but they are required to be documented in different ways, simply because they are created and used differently.

A pattern provides us with a specific context about a solution, how that solution was tailored and what set of components and tokens were used to get to that result.

A complex component responds only to its primary function or purpose as a component. It provides documentation about its logic and interaction metrics without any other context than self-definition. Because of this, It can be used in multiple cases and scenarios by giving the product teams the flexibility they need to solve new problems.

Summing Up

Every design system is different because it is built based on the needs of its primary users, the development and design team, and the type of product it is serving, but there are always things in common worth understanding and defining. This article is not meant to be a reference for classifying the different pieces covered here; my intention is to help shed some light for a better understanding of systems and its parts.

Thank you for reading!

Written by Manuel Carerra, Design Technologist at Workday

Imagine having a New Year’s resolution of eating healthy, but two days in, you’re eating a box of cinnamon rolls and you haven’t changed your shirt. Complex visual states for User Interface (UI) components are just as hard to maintain as your New Year’s resolution. Don’t worry though, with some CSS overrides and visually representing all variations, we’re able to achieve our resolution!

Take a simple UI component like a button, for example. The designers spec out the colors for when the button is hovered and when it’s in a disabled state. However, a button can have many visual states and it can get overwhelming fast. You’re now on your fifth cinnamon roll and you don’t know how to stop.

In this case, I had to refactor some button styles. Although seemingly simple, it turned out to be way more complex. Through some trial and error, I was able to build a visual states table that made it much easier to maintain, update, and display all the states a button can have.

Buttons are Visually Complex

I work as a Software Engineer on an open source library called Canvas Kit. Our team had a request from one of our designers to change the background color of our seven icon buttons.

For context, an Icon Button is a button that usually has no text and it allows you to take action on a page.

You might be asking yourself, why does Canvas Kit have seven icon buttons?

The Canvas Kit team builds components that are reused in different parts of your application. Since there are a wide range of use cases, we have the flexibility of customizing a component to fit your needs. So, if you’re building an application and you want an icon button to be round versus square, we can do that.

In this case, that flexibility came at a cost, including some developer tears.

When I jumped into the code, I realized that all those buttons shared the same CSS (Cascading Style Sheets). This meant the way they appeared on a page was controlled by a single source of truth, or file. Panic ensued.

I don’t know what your experience is with CSS, but it’s a lot like solving a Rubik’s Cube for the first time. You move one color to the face of the cube, but then realize all the other colors are not quite where you want them to be. When you share the same CSS across many elements, it becomes very hard to track your changes.

In this case, the styles were tightly coupled and dependent on each button. Every time I changed a style, I had to look through every page to see how all the buttons were affected.

When I thought I corrected the background color, I would ask for a review, only to find out I had broken some other button. For each of the seven icon buttons I had to manually test every variation of a visual state a button could have, such as when it’s hovered, focused, disabled etc… Sometimes this would take me all day!

At this point, eating the cinnamon roll was making me feel good in the moment even though I knew it was bad for me.

No matter what I did, there were visual regressions, feedback on the changes took a long time, and there was a lack of common language between designer and developer on all the states a button can have, so alignment was off. I realized that my process for solving the initial problem needed to change.

A Visual States Table to the Rescue

After working on this issue for close to two months with little to no progress, I looked over to my co-worker Nicholas Boll in despair, and finally asked for help.

This is like asking someone to hold you accountable to not eat that cinnamon roll and stick to your initial goal.

I explained to him why it was so difficult to solve the problem with buttons. Buttons are complicated!

Before attempting to solve the problem, he suggested creating a table with all the buttons I was working with so that I can see them on one page. This solved the problem of manually going through every page and testing each visual state.

Once we got all the buttons together, the next step was to “force” a visual state such as hover, active, disabled, focused etc, for every single button.

If we do the math, we have 7 buttons, each of those buttons has a toggled on state (where the background changes color on click), so there’s 14 variations. Each of those 14 variations have 8 possible visual states for a total of 112 visual variations. That’s a lot.

This is why buttons almost make me cry, but make me stronger at the same time.

Writing some code to apply those styles provided its own challenges. There wasn’t a way to force those states without manipulating the underlying CSS of each button.

A little more context here. Without a human pointing their cursor over a button to see the hover effect in the browser, I had to find a way to target pseudo selectors like `:hover` to show those styles without specifically hovering over the element. And not just for that one element, but all 14 variations of our Icon Buttons.

Thus, we decided to write some code that rewrites the CSS so that we could apply the styles we wanted for each state. We basically took all the pseudo selectors like `:hover` and `:active` and converted them into regular classes like `.hover` and `.active`. This allowed us to apply those styles in the browser without the interaction.

Think of it this way, your body is the HTML, and your clothes are the CSS. With the code written, we were able to have a stylish outfit for every possible occasion rather than wearing the same outfit 3 days in a row with the stain you haven’t removed.

Note: This was the solution that worked best for us. There’s many ways you can achieve this, including something like post css. But you will have to manipulate the CSS somehow to achieve the end goal.

After some manipulating, we now have a visual states table!

I was now able to track down and change the background color of the button that was initially the problem. From a development point of view, the visual states table greatly decreased the time and effort it took to review the pull request. From a design perspective, it allowed the design team to learn about all the visual states a button can be in.

The visual table solved the initial problem, but we soon realized that we could use this for other components that had complex visual states. The solution evolved into a pattern that we now use to capture visual differences in components.

Both design and development have reaped the benefits of the visual state table, creating shorter feedback times, providing a visual diff of changes, increasing our coverage of visual regressions, and creating a common language when describing visual state of UI components. After all the trouble, I felt like I had become the button king but in reality, I learned how to manage visual complexity and eat less cinnamon rolls.

By Emma Siegel, Inclusive Design and Research

Each member of a team has a different level of awareness, knowledge, or understanding of the value of inclusive design. Stakeholders and collaborators might have other factors they prioritize over inclusion. Advocating for inclusion isn’t always easy and can often lead to some challenging conversations.

What happens if UX teams don’t take action or speak up to advocate for inclusion?

• We may exclude and disable people.
• We may harm, erase, or dehumanize entire communities.
• We may perpetuate the idea that inclusion isn’t our responsibility.

How to Frame the Conversation

Members of Workday’s Digital Accessibility and Inclusive Design teams advocate for inclusion every day. Here’s how we recommend you best frame these conversations.

Be Prepared

Being proactive when it comes to inclusion and accessibility is always important. Sam Smith, an Accessibility Specialist at Workday, recommends having a concise pitch prepared: “One thing I always tell people is to have their elevator speech ready on why accessibility is important. To focus on why it’s the right thing to do, how it makes our product better, and who it impacts. Then, end with the business need and potential legal risk.”

Consider Both Positive and Negative Impact

Erica Ellis, an Inclusive Researcher and Designer at Workday advises considering the holistic impact of a product or experience to grasp the weight of inclusive design: “It’s imperative to not only focus on the positive impact of inclusion, but to have a full understanding of the potential negative impacts of exclusion. Once you begin thinking about all the ways in which the experiences you design could disable, exclude, isolate, oppress, harm, and even dehumanize people and entire populations, that’s when you understand the stakes of not prioritizing this work.”

Educate and Collaborate on Actionable Takeaways

Working in the inclusive design space, I try to provide meaningful and actionable feedback rather than saying “no” during design critiques and reviews. It’s important to educate teammates on why something doesn’t work and keep the momentum going by suggesting an alternative solution. If a collaborator proposes an inaccessible or exclusionary solution, I’ll explain the problems and then brainstorm with them to come up with a new solution.

Advocacy Scenarios and Talking Points

At Workday’s Accessibility Research and Training Lab (ART Lab), we run workshops to scale awareness and education for accessibility and inclusion. Our Designing for Accessibility workshop includes a section on how to advocate for inclusive design on cross-functional teams.

Our ART Lab team compiled the following set of five scenarios you might run into when collaborating with design and product teams. With each scenario, we’ve provided responses we recommend, and a call to action for next steps.

Scenario 1

A PRODUCT MANAGER SAYS:

“If we’re going to do usability testing, it needs to get done ASAP to deliver the feature to customers by the deadline. A diverse and inclusive participant sample sounds nice, but we don’t have time for that.”

TALKING POINTS:

• Investing in inclusive design now will help uncover more use cases and problems. If we solve those before a product ships, they will be much less expensive in development and implementation costs.
• Inclusion is not a “nice to have” — it’s a core part of how we build products. We need to practice our company values not only in the way we operate our business, but also in the way we build our products.

CALL TO ACTION:

• Revisit the project timeline together to figure out how to make time for inclusive research and still deliver to customers in a timely manner.
• Have a conversation about working towards company values. Those values should be seen in how you build your products and experiences. Think about how you can tie those values into the case for inclusive research.

Scenario 2

A DESIGNER SAYS:

“Making things accessible for all users does not necessarily improve the experience for all users. I want to avoid choosing a solution that works well for all users but is sub-optimal for most users.”

TALKING POINTS:

• Contrary to that opinion, designs created to benefit people with disabilities often benefit a much larger user group. Text messaging, audio books, curb cuts, closed captions, and voice assistants are a few examples of Accessible Technology that have drastically improved everyone’s experience.
• If your organization has contracts with educational institutions, governments, or other publicly funded organizations, you may have contractual or legal obligations to provide an accessible experience.

CALL TO ACTION:

• Brainstorm together how to adjust the experience so it works well for everyone, including people with disabilities.

Scenario 3

A UX MANAGER SAYS:

“That’s just an edge case, we have to design for the majority.”

TALKING POINTS:

• Regardless of numbers, an exclusionary experience could, depending on severity, be a complete blocker for an entire user group. We can’t leave them out of the experience.
• If we do look at numbers, 1% of users might be hundreds or thousands of people who are impacted.
• A customer isn’t buying a product for the majority of their workers, they’re buying a product for ALL their workers.

CALL TO ACTION:

• Review the use cases and user personas to make them more inclusive to design with all users in mind.

Scenario 4

A PRODUCT MANAGER SAYS:

“We’ll focus on inclusion and accessibility later in the development cycle, after we’ve designed the basic functionality.”

TALKING POINTS:

• Being inclusive later in development costs up to 100x more over the lifecycle of a project.
• Sometimes it isn’t possible to retrofit functionality for accessibility without redesigning/redeveloping core functionality, which could compromise the entire project.

CALL TO ACTION:

• Revaluate the project roadmap to ensure inclusion and accessibility are considered at every stage, starting at the beginning.

Scenario 5

A DESIGNER SAYS:

“That high-contrast accessible design doesn’t look as good. Grey on grey is way more aesthetically-pleasing and on-brand.”

TALKING POINTS:

• If your organization has contracts with educational institutions, governments, or other publicly-funded organizations, you may have legal or contractual obligations to provide accessible experiences through compliance with WCAG. Workday’s Canvas Design System can help you in ensuring your user interface has accessible color contrast ratios.
• Insufficient color contrast excludes a wide spectrum of users. Some examples are people experiencing situational vision impairments (like bright sunlight or high contrast screen sharing on video calls), permanent vision impairments (like cataracts) and temporary vision impairments (like getting your eyes dilated at the doctor).
• Aesthetics is only part of good design; usability is more important. If people cannot access or use an experience, it doesn’t matter how it looks.

CALL TO ACTION:

• Explore other color combinations and find one that is both aesthetically-pleasing and has sufficient contrast for accessibility.

These conversations often aren’t easy. Sometimes, your talking points will be met with another round of push backs and you might feel stuck. Remember that you’re not in this alone! Find other inclusion advocates in your organization and leverage them for support.

Being an advocate isn’t just disagreements and being right — it’s an opportunity for growth and education. At Workday, we’re working together through the tough conversations so we can build inclusive experiences for all.

What challenging scenarios have you encountered when advocating for inclusive design? How did you respond? Let us know in the comments!

This article was previously published on designsystems.com.

This article is the third of a three-part series that takes a deep dive through Workday’s experience of developing, productizing, and eventually releasing their design system out into the open. Check out Part I, Design Systems are Everybody’s Business, and Part II, Productizing Your Design System.

The heart of any design system is the community built around it. This is the underlying engine that powers the Workday Canvas Design System with our community defined by transparency and inclusion. In other words: we strive to be open.

In this article, we’ll go over what “being open” means, both as a vision and what is actually happening today at Workday. We’ll also explore tangible examples showing why being open matters and how we’ve benefited from it.

Moving toward openness

Our design system wasn’t always an “open” concept and we can argue that at its infancy, most design systems shouldn’t be. They are ideas and concepts that need to be protected and nurtured until just the right time. Canvas took plenty of behind-the-scenes work to get it off the ground (you can read about this in part 2 of our series) but as adoption increased, we needed to be more transparent about our decisions and open up the system to new ideas from our users.

Our journey toward being completely open is continuous. Yet, in the relatively brief time that we’ve been doing this, we’ve observed three important lessons that we want to share with you:

1. Access stimulates progress
2. Working openly promotes communication and accountability
3. Slowing down first allows us to speed up later

Access stimulates progress

Do you ever get stuck on an idea? Whether it is writing code or creating designs, making progress can be as simple as considering a different perspective. This can come in the form of a customer insight that reveals a fresh take on a stale problem. It can be a poignant observation from a trusted colleague. It can even be as simple as taking a walk through nature (seriously). New perspectives seem to kickstart our brains.

For us, seeking new perspectives took the form of increasing access to our design system. We did this in two big ways: first, we switched our product design tools to Figma, a cloud-based platform; and second, we migrated our developer libraries (Canvas Kit) to Github.com so that our source code could be accessed by anyone at any time. The result is that, by design, many more teams can see what we’re up to and their perspectives allow us to make incredible progress very quickly.

Generally speaking, too many opinions can slow a process down. We found that the feedback helped us make better decisions, quicker. Given the vast array of users and products in our suite, edge cases, accessibility, and optimizations on components need a large amount of research and outreach. These requirements now flow into our process as a natural side effect of increasing access to our system.

Imperfections become improvements

A great side effect when increasing access to your design system is that your imperfections become improvements. Even the most mature design systems have flaws. At Workday, we have had to address missing/incompatible components in our Figma libraries and fix cross-browser bugs in its codebase. Every time someone brings those to our attention, we get better. Since we open-sourced Canvas Kit in July 2019 we’ve fixed more than 90 reported bugs in our codebase. Many of those were solved by contributors outside of our own team. Additionally, since we switched to Figma, our internal Canvas community on Slack has more than doubled. That community alerts us to at least one inconsistency within our design system every week. As designers, we’re often conditioned to hide our flaws so that we can present a polished product. Ignore that urge. This doesn’t work when it comes to design systems because they serve as a foundation for product design. The faster we are able to discover its imperfections, the faster we can improve the platform that our community depends on.

Development becomes diverse

Building a truly scalable design system is a near-impossible task for any singular team. Consider all the deep expertise that goes into the design, development, accessibility, internationalization, and testing of it. It can be daunting, to say the least. It’s important for us to leverage the subject matter experts around us to make the design system and all its parts work for everyone. We achieve this by being open. For example, our accessibility gurus conduct regular audits on new and existing components knowing that our latest and greatest code is available for them to look at any time.

By no means are we advocating that simply being a more open design system will resolve your issues through crowd-sourcing. But we are saying that in an open design system, its development becomes diverse. The true value of this is the way we are able to multiply the impact of these diverse viewpoints through the design system. Teams who may have had limited access to these subject matter experts (SMEs) now indirectly have their expertise added to their products through the design system’s components, Figma libraries, and documentation.

Scrutiny becomes sustainability

If “being more open” sounds like you’ll be inviting a lot of scrutiny, it’s because it will. But in an open design system scrutiny becomes sustainability. By opening our design system to the world, we’re inviting opinions about how we do things and can also highlight the things we don’t do quite right. Things change when you’re official.

To consider this, we’ve implemented plenty of guardrails like visual regression testing across all of our supported browsers and formal design documentation processes largely because many teams watch our every move. Yet this scrutiny works in our favor and we’ve made incredible progress on being a more sustainable, better-documented design system.

How open you can be with your design system’s access largely depends on your organization’s goals but we recommend that you strive to be open to as many diverse perspectives as you can. We have found that if we take the time to grow and build the community through openness and transparency, it encourages contribution. Contribution creates that sense of ownership, but just as importantly it means more people helping the design system grow. Some of the teams we have worked closely with through communication and collaboration are now some of the biggest contributors to our codebase.

Working openly promotes communication

If the community is the heart of a good design system, then open development can be thought of as the arteries and veins: it carries life-sustaining communication principles like clarity, transparency, and accountability around the body and back to the heart. When we talk about “development,” this isn’t just our codebase on Github but also our design specifications and documentation on platforms like Figma and Confluence. Also, all are welcome to participate in our Slack channels and our sprint demos.

Being open is not just about lifting up the veil on our code but also the way we work as a team. The fortnightly demos we hold for our engineering kit go over upcoming changes or newly released features. We cover why these changes were made and ask for feedback. This openness allows users of our design system to see how we decide on changes that will best serve them. It’s kind of like showing your work on your math test. If your teacher sees that your approach to the problem was correct, even if the answer is wrong, they’ll understand your thinking and may give you partial credit.

By being transparent, we try to build with the community and the developers using our codebase. Before going open source, this approach also helped us build trust inside our organization.

While we strive to be as open as we can to as many people as possible, it does produce an interesting side-effect: open development forces us to be accountable. As more teams at Workday depend on Canvas, we become beholden to more and more requests, expectations, and results. That’s terrifying. But while accountability can be scary, a healthy dose of fear is a great thing! In 2019, our biggest feature request was a roadmap and a release cadence. Our users want to know what’s coming and when. To accommodate these asks we spun up a read-only Slack channel to let folks know about what we’re up to.

Slowing down allows us to speed up later

Just like any other product, design systems are not immune to debt.

As your system grows, your user base should also grow. After you have a minimum lovable system, further growth should have a balance of speed and quality. We know that iterating fast is important to give value to your users. But, considering how a change could impact your users and the system itself is even more important.

For our design system, changes to the way a component interacts with other components is a concrete example of a breaking change. It must be carefully managed and communicated. However, this also extends past the technical changes to visual breaking changes. Changing a button color or increasing the height of a text input can have wide-sweeping effects. For example, it could change the layout of a page or the application as a whole. In turn, this may affect components and interactions around it, break tests, or even require an update to documentation. These changes have the potential to create friction when adopting a design system. Friction is inevitable, but a release cadence can help ease the burn.

We’ve introduced mechanisms to communicate planned changes through change logs. We note everything from the update of a library dependency to a visual breaking change. Through semantic versioning, we bundle breaking changes into major releases. This allows us to easily communicate changes to our users.

Although we have processes in place, we are still refining our approach to visual breaking changes. Our aim is that our changes are well understood. Coupled with the right communication channels, a team’s upgrade path should be clear, reducing the friction of change.

We continue to work on the frequency of our major version releases. We’re looking at how we can align visual evolution to the Workday product releases. For us, this is twice a year. Aligning to this cadence means we can use internal processes around change management for our customers. But, it’s good to note that we do not need to align technical breaking changes with this cadence.

Being open amplifies the impact of a design system

Yes, there are considerations to building an open design system. But for us, the benefits have allowed us to nurture a community of open design.

By slowing down our rate of change, we’ve been able to increase the impact of our design system as we move forward.

Being open creates transparency for how and why we do things. This transparency allows us to come full circle. It allows us to iterate faster and deliver more value to the teams using our design system, and at the end of the day, empower them to deliver quality and cohesive experiences to their users.

By Carlos Yllobre Aleman, Senior Product Designer, Workday

This is the second in a series of articles about design systems thinking. Read Part 1 here.

The first time I heard about systems thinking was back in 2017 when my team and I started building a more complex library of components to serve developers when they updated our product. That first attempt would evolve into what we know today as a design system, but the real change didn’t come with the outcome. Instead, it came with the learning path that opened a door to a new and more rational way of approaching problems with many touchpoints in common with other methodologies, like design thinking.

With the arrival and evolution of design systems, we discovered a new way of approaching business, engineering, and design problems. Before I talk about the how, let’s talk about the what.

What Is a System?

A system is a group of interrelated parts that work together to perform multiple basic or complex functions. It is precisely this connection and interaction of the parts that makes a system work and form a single unit or entity. This simple and beautiful idea is present in many shapes and with a rich variety of purposes, from natural to artificial constructions. We can wonder about the Great Barrier Reef in Australia or learn more about the behavior of financial systems and the markets across the world using systems. We live, think, and work in systems; they are the result of complex natural processes and our capacity to understand and recreate them.

The interesting part is that this simple concept of small units interacting with each other can be applied to the way we think, organize our lives, or face new projects and challenges. This problem-solving approach can take multiple shapes based on the type of system and problem that is meant to be solved. I like to use a (simplified) scheme that explains one of the system thinking approaches when it comes to building or reorganizing system structures. Let’s learn the alphabet!

A is for Audit

This point comes with 2 parts: the first one is about understanding and defining the system, while the second one is about identifying its problems. Curiosity is a powerful tool at this stage, and I invite you to use it!

1. Defining the System

Having a map of the existing components or pieces will serve multiple purposes along the way, but the primary one is to unify our language, naming conventions, and structure, as well as to always have a source of truth across our sources that serves as a reference point when it comes to organizing, modifying, and updating our system.

We start by learning the basics about a system and identifying and defining the tiny pieces of data. The first questions are about the basic parts of the system: What are the pieces? How do they behave? How many do we have/need? How many types do we have or need?

Once we have answered these questions, we move on to other questions about the whole: How does the system work? What patterns does it follow? What results is it producing?

We can’t jump ahead and try to identify the problems or run an inventory of the things we need to fix without knowing where and what we need to look for first — that’s why this first step is key.

2. Identifying the issues

In this step, we need to identify the issues affecting the system, the areas of improvement, and the broken links in the chain. I like to think of this process as a layer we add to our map where we mark our points of interest. These could be issues or problems impacting the system or areas of improvement.

By adding this layer, we are in a better position to create a backlog of tasks we can classify based on the level of complexity, the effort involved, etc.

B is for Building

3. Planning

Producing without planning is a rookie mistake. We don’t produce to tick boxes and mark Jira tickets as done; we produce to tackle the issues or areas of improvements identified in the previous 2 steps, and all this falls under a systematic view of what building stands for: building our system or product.

Planning before producing will provide us with a unified building process that can escalate and be shared across teams and individuals. Things like the necessary steps, the desirable outcome, and quality metrics can help us avoid generating more tech debt once we move to the production phase.

4. Production

Production doesn’t equal release and implementation. It represents the phase where the core work is done and provides us with measurable results. These results need to be reviewed using the quality metrics we defined in the planning phase, and this can be translated into multiple iteration cycles happening between Step 3 and 4.

C is for Communication

Communication is an overused concept but a powerful one. People talk about how everything is sorted with communication, but like everything, for this to work you need to put certain metrics in place: when and where to communicate, what type of communication, what amount, and what type of information is shared and received. To simplify, when working on a system it is good to define 2 types of communication.

5. Internal Communication

Communication happening within the team or group of people responsible for performing the core work about building the system. It is important to mention that this doesn’t happen at a specific point in the systems thinking process, but in parallel with the whole process, focusing mainly on points A and B.

6. External Communication

Communication happening outside the core team responsible for building the system. It is important we build and maintain clear communication channels with key stakeholders but also with our end users. These 2 communication channels take major relevance in the latest stages of the process.

D is for Deployment

The deployment phase is where the core work finished in the building phase gets to see the light as a product. This point consists of 2 main steps.

7.QA

Quality assurance is the process to assure that the outcome of our work fits the defined use or purpose. When building and optimizing systems, it is critical to build a well defined QA process. This is the last filter before releasing any modifications to the parts or the whole of the system.

8. Release & Documentation

And we arrive at the last step of the process. I like to include documentation here since I believe every release must be accompanied with a summary of the whole process, a description of the release itself, and other important information covered by default in any versioning exercise.

Summing up

Systems thinking doesn’t differ too much from design thinking or other problem-solving methodologies. All of these can be used in multiple iterative cycles with similar steps, recycling themselves accordingly with the project. The main difference and where the value of systems thinking lives is in understanding the parts as a whole and translating this idea into a process where every step is linked to the previous and further ones, and the sum of all to a successful framework.

Thank you for reading! 😊

The ABCD of Systems Thinking was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Simone Ehrlich, Content Strategy Manager

Redesigns are easy, right? Just glance at the page, and it’s instantly clear what should stay and what should go. Far from it. The beauty and risk in design is that inherent in any page are a thousand small decisions. All these add up to an efficient, delightful experience, or degrade it until it’s a broken, incoherent mess.

A priority guide has the potential to inform your decision-making. At Workday, this is one of our Content Early methods, which we use at any time during the design process. We use priority guides to design, in the manner of content first, before ever opening a Figma file. We also use them to bring fresh perspective if we’ve already started a design. It’s never too late to consider content.

By infusing intent into a priority guide, it helps you to analyze the hierarchy as well as the purpose of each section and element of a design. You can do a priority guide based on an existing wireframe, mock, or even a page from your product that’s out in the wild, but begging for a redesign.

How to Create a Priority Guide for Analysis

Here’s how to create a priority guide for analysis:

1. Identify the goal for the page.
2. List the content (and their associated UI elements, functionality, and intent) in the order of the current hierarchy.
3. Analyze the hierarchy relative to the page goal, in light of any research you have, and add ideas for the redesign.

Let’s say that we’re redesigning the Recipe page for ProCooking (a fictitious website). Here’s the current page:

To analyze the order and content of your sections, you can make a high-level priority guide.

Identify the Goal for the Page

This should be the goal of the page in your new design. You’re going to use this goal to compare what the current design is communicating, and then make decisions about what to change to better support the goal. For example, the goal here is to “Guide cooking enthusiasts and new cooks through a recipe of interest to them.”

List the Content, Elements, Intents, and Functionality

What is the existing design telling you is most important? What draws the eye? Look at the size of the element, placement, weight of text, vividness of color and imagery, and more. Make a list, in order of the current priority communicated in the design. Leave out the header area or nav if it’s not a part of your redesign.

In the example, right now the recipe page has some elements that are competing for priority. Because of their relative size and visual interest, the 3 images on the left are high in priority: Baking Basics, The One Dutch Oven You Need, and Quick Dinner Rolls. It’s not immediately clear that these represent 3 separate sections: classes, equipment, and related recipes.

Two other sections, Ingredients and Steps show as lower in priority. Yet these are the sections the user cares most about when making a recipe! (Yes, you’re starting to analyze… 😄 It’s irresistible once you write down the priority.)

Analyze and Add Ideas for the Redesign

To analyze the content priority manifested in the present design, question everything. How does the content in its current order reflect its importance to the user and support your page goal? Add any ideas for how the information and its hierarchy might change with your redesign.

Consider what you know from user research or the usage data (if the design is already live). Then think about what needs to be changed or eliminated. Is something too high up in the list? Does it not even need to be there?

Now’s the time to make a note about moving Ingredients and Steps up in priority, above Related Recipes. You may add a redesign idea to expand the Related Recipes section, based on usability testing. And if you know from your usage data that users aren’t navigating to Essential Equipment or Cooking Classes from the recipes page, you can ditch these sections entirely.

The priority guide helps you to first evaluate how well the information supports the goal for the redesign, then determine what changes to make in that redesign. You can ruthlessly slash sections that don’t support the goal and revamp or rearrange sections according to what information best serves it.

The redesign ideas listed in the margins of the priority guide may cover functionality or intent. For example, the ingredients section is essential (after all, what’s a recipe without ingredients?), but you can improve it. The original intent to “Make it easy to order” supports the goal, but the new functionality, “Integrate ordering via the user’s preferred delivery service” better fulfills that intent and serves the overall goal.

Get into the Details

As part of your redesign, you can make a detailed priority guide of the individual sections you plan to keep and dive deeper into the redesign of the page in lowest fidelity. What’s lower fi than notes in the margins?

Let’s look only at the Related Recipes section of the page. By analyzing the intention of each element, and keeping in mind insights from research, you can decide what you want to move around. You can also determine what changes in functionality to make and vet these with PM and dev.

This deceptively simple section has a lot going on. There are 5 elements that convey information, some of which you can eliminate, substitute, or move around. To expand the section, you’ll need to move the text button up in hierarchy and also add a section header: Related Recipes.

If you know from usage data that users don’t tend to share before they dig further into the recipe, you can eliminate the share functionality at this level, and reserve it for when the user clicks into the recipe.

Say you have a hypothesis you’re thinking about testing — that seeing the ratings from other users will encourage the user to click into a related recipe. By adding that new idea to the priority guide, you can gauge your partners’ reactions. Then when you go to wireframe or mock up the redesign, you have a better idea of whether you have buy-in and how feasible your design will be.

Take a look at the redesigned Related Recipes section.

An intent frame, in which you plan the layout of elements based on the purpose of each one, could help you gauge where on the page you’ll have space for all these new related recipes. But let’s stay focused on priority guide, shall we?

Benefits of Analyzing Your Intentions in a Priority Guide

The benefits of analyzing your designs with a priority guide are similar to those that accrue when you design with one.

Alignment Made Easier: Shared ‘Ah Ha’ Moments

The tool is the conversation starter with your partners. You don’t need to argue your point. Just show what the present design is communicating about what’s important, all by itself. The conversation swiftly moves to how to improve the prioritization, and you’re off to the races.

Rapid Iteration: Kickstart the Redesign

It’s super fast to get a jump on your redesign with a priority guide that analyzes the current design. You can iterate without having to create wireframes or mocks yet — just move the sections around in your priority guide and change the information, rapidly.

Then you can use the priority guide to inform your next wire or mock (or an intent frame if you’re using one) and translate the design back to a more visual and spatial form again.

Check out the newly redesigned mock for ProCooking’s recipe page after its glamorous transformation!

So What?

Why analyze your designs with a priority guide and bring intent into the mix? Like much in design, if you ground your goal and priorities in a combination of user and business needs, and communicate your intentions clearly, you’ll succeed. The user needs, you get from research. The business needs, you get from product management. The technical feasibility, you get from engineering.

And, like all Content Early methods, you can bring priority and intent to bear at any point in your design process. Whether you use a priority guide to design from scratch or analyze an existing design, it brings value because it helps you to organize your own thinking and align with your partners.

Using priority guides in similar or different ways? I’d love to know how. Reach out!

Priority Guide with Intent: Analyze with Content Early was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Simone Ehrlich, Content Strategy Manager

Nothing sharpens our sense of priorities like a crisis. The COVID-19 pandemic has certainly thrown my personal priorities into sharp relief. The goal is to get through this. My priorities, in order, are my family, my team at Workday, and my community.

It shouldn’t take a crisis, however, for you to know your goal and priorities. In design, knowing both is key to success. A priority guide is a design tool that helps to establish the goal for a page and what should go on the page to serve that goal. You can use a priority guide to design from scratch or analyze an existing design, which is why it’s part of the Content Early suite of methods here at Workday.

For the original priority guide, introduced by Drew Clemens as a form of content first design, you identify the goal for the page and list the real content that supports it, annotating with the UI elements and any functionality.

I like to modify the priority guide a little and infuse it with intent. A priority guide with intent has particular power in fostering alignment and collaboration. Ultimately it leads to better design.

Let’s take a look at what this tool can do.

Designing with Intent in a Priority Guide

A prerequisite to a priority guide, like any content early method, is solid user research. Another valuable input is the business need that is so often the invisible hand in design.

At the core, there are really 2 things you need to do — identify the goal for the page and list what information needs to go on the page to support the goal and why.

Here’s how to create a priority guide:

1. Decide on the goal for your page.
2. List what goes on the page — the elements and the information that goes in them — in the order of importance to the user.
3. Add the intent of each element.
4. Note any functionality, if applicable.

Let’s break it down a little more. Let’s say ProCooking, my entirely fictitious website, wants to add a Quarantine Cuisine page. (Hey, it’s gonna be a long year.) These are the steps to making a priority guide:

Decide on the Goal

First, get the project team in a room (or on a Zoom) together. Align on the research insights before you begin. Assuming you have your flow already designed, you’re ready to start defining the priority for your page. Identify the goal first. For example, Support cooking enthusiasts and people who don’t already love cooking through Shelter-in-Place on a culinary and emotional level.

List What Goes on the Page

Figure out with your team what information needs to go on the page, in support of the goal. Make a list of each section you’ll need, in order of most important to least important. For example, FAQs, Quarantine Tips, Food Related Entertainment. This ordered list shows the content priority. It serves as a quick reference for the page’s information hierarchy.

Add the Intent of Each Element

For a high-level priority guide, the elements are just the sections. You can label them on the left side of the content. (This starts to add value when the elements change, for example, Section, Prompt, Button.) Now, note the intention of each piece of information in the list, off to the right. Start with a verb, for example: answer a variety of questions, appeal to social need.

Note the Functionality (if applicable)

Write down any key functionality for each section if it occurs to you. It’s great to vet these ideas with dev to make sure what you want is feasible. For example, does this section content change on a particular frequency? If so, you can add a note such as: Update tip at 12 a.m., local time.

Here’s what the priority guide looks like at a high level — you can see that it’s just the sections right now.

This single column of content in the middle acts as a constraint (much like designing mobile-first), in which you have to ruthlessly prioritize the relative importance of the information. Writing down the UI elements and the functionality helps you plan the page and what you want it to do. The intents express what purpose the information serves. All these notes invite your partners, who need to implement the page, into the conversation about what they’ll need to build and why.

The Sequence of Priority and Intent

What’s next? You can translate the priority guide directly into a wireframe, but you’ve already got those handy intents all listed. If you make an intent frame, you can get a preview of the wireframe in lower fi.

Here’s how you use the tools in sequence.

Each tool provides its own opportunity for alignment with your partners (and even feedback from users), keeps the focus where you need it in each step, and ultimately makes for a better design. You can also revisit your priority guide after new research sessions to see if any of the priorities in your design have changed based on what you learn.

Translating a Priority Guide into an Intent Frame (or Wire)

To determine the placement of each section in the intent frame, think about 3 things — location, size, and visual engagement — that factor into what gets the user’s attention first.

Consider, in combination:

• The highest priority real estate on the page based on the F-shaped pattern of scanning
• Relative size — the amount of space the content will take up
• Visuals that draw the eye (e.g. color, images)

However, to better plan the relative size of each section and factor that into the placement, first you need to think through the information that goes in each section in more detail.

Detailed Priority Guide

Enter the detailed priority guide. Think of it as the expansion (accordion-style) of the high level one. It’s the same thing, just at a more granular level. Here it is for just one section — the one on Quarantine Tips.

This detailed content doesn’t have to be perfect — typos don’t matter. The important thing is to get a good sense of what’s actually going in the elements so you see how much space it’ll take up. That’ll tell you if you’ve got the right element or if you need a particular interaction pattern to reduce the cognitive load for the user.

To make this post slightly shorter than War and Peace, I’ll skip over showing the intent frame and wire for this section and show just the hi-fi mock. Here’s what it looks like for the Quarantine Tips section:

Notice that something low down in the priority guide may end up higher up in the mock, because of how users process information on a page. Since the image is most engaging, the eye goes first to it, then to the subheading, ‘How to Freeze Citrus’, then to the button. The heading ‘Tip of the Day’ is low priority, because of its small font.

Once you detail each section, you can put it into your design, confident that, having already vetted the intent and functionality with PM and dev, your design is something your partners are bought in on and can implement.

Benefits of Priority and Intent in Designs

The Priority Guide is an expression of intentional design and an invitation to collaborate. It is both a plan and an alignment tool. By using priority and intent in combination, you can design more efficiently and foster collaboration with your partners.

You’ll make each iteration of your design more purposeful by not jumping to layout before you have figured out:

• The goal for the page
• What information you want on it
• That information’s relative importance
• The feasibility of implementing your intent

A priority guide with intent organizes all this information into a blueprint for a successful design and a successful collaboration. It’s not that a priority guide eliminates iteration — it just makes each one more effective, because it’s a communication tool.

The annotations in a priority guide — the UI elements, and in particular the functionality and intent — make for great conversation with PM and dev. Why not find out early whether your idea meets the business need and is feasible to implement…or if it doesn’t, how the team recommends you proceed?

Better yet, if you invite your partners into the process early (this is content early, after all), the goal, priorities, and intent are no longer just yours. They’re shared.

I flat out love doing a Priority Guide in this setting. It’s designing with partners without the pain of designing by committee. You’re making the hard decisions real time, and you still get to go off and figure out how to creatively bring it to life. Then when you come back to your partners with the next version of your design, they’re like, “Yeah! That’s just what we talked about!”

Try a priority guide. Then do an intent frame (super fast since you already have the intents), and then go to a wireframe. Your partners are bought in every step of the way cause now it’s a shared priority, a shared intention. Beautiful.

Interested in learning more about priority guides? Don’t stop here. Check out this pair of great resources:

Priority Guides: A Content-First Approach to Wireframes — Alistapart provides a super clear explanation of how to use a priority guide, by Heleen van Nues and Lennart Overkamp.

Design Process in the Responsive Age — This is the pioneering post on priority guides, by the man who invented the tool. My favorite line is Drew Clemens’ explanation of his original name for the tool: “my mobile-sized content prototype wireframe thingy.”

Priority Guide with Intent: Alignment through Content Early was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written and illustrated by Jonathan Keyek-Franssen, Product Designer at Workday

Most information has no perfect channel to be passed through–social media posts are good for advertising, but so are TV spots. Podcasts are good for storytelling, but so are novels. And, as it turns out, repetitive, expensive, and synchronous meetings are good for getting slack messages like this:

Effective design communication that creates actionable insights is built from one-part engagement and one-part perceived value. If you have information I need, but don’t present it in a way that makes me want to listen, I won’t care. If you have a great presentation but the information you relay isn’t valuable, I won’t learn anything useful.

Valuable + Non-Engaging = I don’t care

Not-Valuable + Engaging = I learn nothing useful

While looking at how our design meetings were working for us, our Communications Technology Design team at Workday saw that designers have a special aptitude for operating in the information-dissemination space: we have the creative skills to make things enticing, and an innate ability to understand emotions and turn them into insights.

This partnership of traits makes us especially valuable in communicating ideas in an effort to make things better (I mean, that’s how we got hired, right?).

Valuable + Engaging = I gain something I can actually utilize

Where We Were

Based on that examination of our ceremonies, we realized that the way we were attempting to communicate our design activities to the org at large was costing unnecessary time and money.

Our primary communication method was a bi-weekly cross-functional meeting consisting of about 2 dozen participants, ranging from Sr. Director to Jr. Individual Contributor. Turnout was always high and the conversations were usually engaging, so from the surface all seemed well.

Then, the cracks started to appear.

A few months in, we noticed people started coming into the meeting late, deep questions stopped being asked, laptops stayed open, and eyes became more glazed. Confusingly, we were getting feedback that the information we were covering was valuable and our presentations were always well prepared.

So, why the lack of engagement?

Well, if we break apart our formula from earlier, we can theorize that “engagement” is built from relevancy and convenience, and it was clear we did not have the latter dialed in. The value of the information we were passing was being counteracted by the context switching required to engage with the content.

To this point, we had not fully utilized the value of communication in Design and had stumbled backwards into a muddy triad of crap meetings:

“This could have been an email.”

Right people, but wrong forum

“Oh I missed that, can I retroactively add my thoughts?”

Right forum but wrong people

“This info isn’t pertinent to me.”

Wrong forum? Wrong people? Wrong info?

With opportunity staring us in the face, we regrouped to explore our options.

What We Did

To start, we held a feedback session with some Sr. org leaders to work out what could be done. To start, we defined what it was that we were trying to accomplish:

“Reimagine the way the org and Design communicate by disseminating information about Design activities, offering inclusion in the design process, and showcasing the connection of Design efforts to larger business objectives.”

Along with that definition, we also determined that the best manifestation of this idea would be scalable (no more “really, another meeting?”), asynchronous (no more “oh, I missed that”), and engaging (no more “I can’t keep my eyes open”). In short, we needed to level-up our communication skills.

We first looked to others in the industry to find out more about effective design communication and found example after example — like Neilson Norman’s Storytelling to Present UX Work and Jared Spool’s Combining Our UX Metrics With Compelling, Emotional Stories — about storytelling and its inherent ability to entice and engage.

Our team then spitballed ideas about how we could realize our goal through storytelling and determined that a video newsletter would:

• Let our viewers digest the information asynchronously.
• Allow us the space to create worthwhile content at scale.
• Enable us to effectively use our creative energy to create engaging content.

With the details of producing (I conveniently have a background in video production), cataloging (Google Drive), and presenting our content (Slack) figured out, we set up some calendar time and hit record.

After our boisterous first recording session, I edited down the footage, interspersed a few memes to add some lightness, and wrote a text breakdown of the video to post along with the actual recording. We posted the video on the primary slack channel for our org and we (well, maybe just me) watched our Slack notifications nervously to see what, if anything, peoples’ reactions would be.

Much to the chagrin of my inner critic, people were very into it.

Within a few hours, our post resulted in more engagement, more fresh ideas, and more questions about our Design happenings than we had ever received from our original meetings.

These are a few of my favorite reactions from that original post:

We also had multiple Sr. stakeholders reach out to show their support for the new method, we had design leaders from other orgs ping us to see how they could learn more about our process, and our management pushed us to cross-post the videos into other channels to promote the value of our org at large.

This level of enthusiasm validated that what we were trying out really was effective design communication.

What We’re Planning

In the 5 or so videos since our initial pass, we have learned how to:

• Properly budget our time by being more intentional with our pre-planning.
• How to level-up our content with engaging editing and videography.
• How to make the most of our time in front of people by including guest stars from outside the Design discipline.

With that, if you asked me if we have successfully “reimagined the way the org and Design communicate,” I would have to say, “not yet.”

While we may have a steady increase in viewers, and much more engagement than before, we are still figuring out how we can most effectively leverage that audience to reach our goal.

For now, we must continue asking questions like, “how can we evolve the series? What is the secret-sauce to engagement? How do we scale this beyond just our org and discipline?” and trust that through diligence and enthusiasm, we can create something great.

Through building this idea from the ground up, we have not only seen the power of Design as an open and inclusive domain, but we have seen that creativity plays a massive and oftentimes undervalued role in effective design communication.

The video newsletter is not the only way that our Design team is trying to get more creative and asynchronous with our communications. Below are a handful of ideas that are free and easy to implement:

• Have a long form thought you want to pass off to others? Try Loom (yes Loom, but Zoom would also work!) to record yourself walking through your idea. We’ve used this to walk our direct teams through design iterations, unpack research findings, and more.
• Have a research readout that you want a large group of people to see? Try iMovie to splice together your findings, recordings from your sessions, and your next steps. We’ve done this frequently to enable people from all levels of our org to digest the findings on their own time.
• Working on a lot of designs at the same time? Try design cover pages like this Figma thumbnail kit from Joey Banks to help others keep track of your progress. We utilize our own version of this to help identify finalized items for PM and development and keep in-progress work out of the production stream.

I’ll end with a plea. To anyone reading this, if you’re even tangentially contributing to a meeting that has some of the negative side effects we experienced, change it! Push your team to explore more scalable, asynchronous, and engaging ideas to improve your meetings (your calendars can thank us later).

Effective Design Communication in the Time of Zoom Fatigue was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Michael Blume, William Stanton, and Justin Panté

Accessibility often represents the difference between a usable website and an indecipherable mess for people with disabilities. This is all the more important because of the recent need and desire to work from home; Gallup reports that in 2012, 29% of American employees worked remotely at least some of the time, but by 2016 that number grew to 43%. Despite this growing trend in remote work, the number of accessibility issues in web applications continues to slowly increase. The need for individuals and organizations to integrate accessibility best practices into their daily work is stronger than ever before.

At Workday, we believe products should work well for everyone, regardless of ability. Because of that, our Workday team is working diligently to improve the accessibility of all of Workday’s digital assets throughout the company. No matter a user’s ability, they should be able to perceive or do everything in Workday with equivalent ease of use.

Workday’s Canvas design system has particularly revolutionized the way we are integrating accessibility into Workday products. Through collaboration between our dedicated Accessibility team and the Design System team, the design system now provides our designers the tools and guidelines to build out a single, cohesive experience across all products and platforms. Canvas is also open source, meaning that anyone can access the original source code.

While Workday’s presentation on this topic at the 2020 CSUN Assistive Technology Conference was cancelled due to COVID-19, you can listen to the full video recording of our presentation in which William Stanton, Justin Panté, and I discuss:

• What is the Workday Canvas Design System?
• How do we define our accessibility guidelines in the Canvas design system?
• How do we scale accessibility throughout components in the open source library?

Optimizing Canvas Accessibility For a Changing World was originally published in Workday Design on Medium, where people are continuing the conversation by highlighting and responding to this story.