Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Các kiến thức cần ghi nhớ trong việc thiết kế Design System


Nội dungURL

Lý thuyết:

A design system is a series of components that can be reused in different combinations. Design systems allow you to manage design at scale. Example:

  • Lego: How many ways can you combine six 2×4 LEGO® bricks of the same color? →  915,103,765 different ways! 
  • Taco Bell: 8 ingredients = 50+ Menu Options

Another name: Design System = Atomic Design = Design Language = Modular Design = Component Design

Why should you use a Design System?

  1. Save time and Money: Scale - Consistency - Efficiency - Teamwork 
  2. Design Systems are the future

Style Guides, Pattern Libraries, Design Systems

Atomic Design Process: 

 


Atomic design: how to design systems of components

Nowadays, digital products must be able to exist across any and all devices, screen sizes, and mediums at the same time:

So why the hell are we still designing our products by “page” or by screen?! → Instead, we should be creating beautiful and easy access to content, regardless of device, screen size or context.

How is this different than before?

 

Everything starts with the brand identity

Enrich the system -  Think generic

The part and the whole - Mutualize the work

Share the system

 


Three golden rules for great architecture:

  • Durability (Firmatis ): The building should be robust and remain in good condition.
  • Utility (Utilitas): The building should be functional and useful for the people who are in it.
  • Beauty (Venustatis): The building should be delightful and soulful.

Design principles:

  • Human layer: To create a design system you must understand the rules that humans live by, and by rules we could also call these restrictions or limitations.
  • Conventions layer: Every system needs a set of common conventions to help with users learning the ability. Human beings do not like change, so creating a set of consistent rules will help them understand what they need to do.
  • Branding layer: This is where the visual style, beauty, and personality of your design system shines. The branding layer helps your system create a standard that is visually distinct and recognizable.

Shopify’s Polaris Design System is one of the best examples. On the homepage, they’ve already broken down all the core sections:

  • Product principles – What is the purpose and soul behind all the products?
  • Written content – How should the product’s interface copy look and feel?
  • Visual properties – What should the “skin” of the product look and feel like?
  • Components – What are the UI patterns and code components needed to build products coherently across devices?

Atomic Design & creativity:

When you really find your own interpretation on how to use Atomic Design, you can decide precisely where and when you want to give room to creativity.

Examples:

  • Lego: This is the first metaphor I found interesting and it’s definitely the most commonly used when approaching components systems.
  • Music: It begins with the idea that music starts with 7 notes and some rhythm indications → We can combine those notes to create chords → We mix these chords into verses → And with those elements we’ll create an entire sheet of music and why not even an opera!

Một số ví dụ:
Tiêu chuẩn thiết kế:
Plugins:
Enterprise Design:
Toolkits

Designing your design system - Step by Step


StepContent: https://www.designbetter.co/design-systems-handbook/designing-design-system
Step 1 - Who should be involved

Before beginning work on your design system, take a moment to think about the team you’ll need to bring it to life. Who needs to be involved? Spoiler alert! You’re going to need more than just designers.

Here’s a quick list of the disciplines that can be represented in your team to create an effective design system:

  • Designers to define the visual elements of the system
  • Front-end developers to create modular, efficient code
  • Accessibility experts to ensure your system conforms to standards like WCAG
  • Content strategists who can help the team nail the voice and tone of the system
  • Researchers who can help you understand customer needs
  • Performance experts who can ensure your system loads quickly on all devices
  • Product managers to ensure the system is aligned with customer needs
  • Leaders (VPs and directors) to champion and align the vision throughout the company, including up to executive leadership

Once you’ve got the right skillsets represented in the design systems team, identify leaders to represent each area. These people should be able to drive decisions forward. Know who on the team can advocate for each of the areas of the design system.

With a team of experts guided by strong leadership, your next task is to establish the right team model to help you achieve your goals.

Step 2 - Choosing the right team model

https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0

The solitary model: an “overlord” rules the design system.

The centralized team model: a single team maintains the design system as a full-time job.

The federated model: team members from across the company come together to work on the system.

There are strengths and weaknesses in each of the above models. A solitary model is fast and scrappy, but with 1 person in charge of so much, the “overlord” can become a bottleneck to the completion of many tasks. A centralized team, on the other hand, keeps the system well maintained, but the group may not be as connected to the customers’ needs as they may be less involved in user research. Finally, a federated team has great insight into what’s needed for all the product features and user needs, but this group can be quite busy working on those areas outside of building the system.

Many teams are moving away from the solitary model to the centralized or federated model. As Curtis mentions in his article, overlords don’t scale. The centralized or federated models are usually much better for scaling a design system.

I wrote about the Salesforce team model in response to Curtis’s piece. When I was at Salesforce on the Lightning Design System team, we used a combination of the centralized and federated models. In an enterprise organization as big as Salesforce, a centralized design systems team was not enough on its own. With so many key players involved and the amount of ground we had to cover across products and platforms, we needed a more sustainable approach.


Step 3 - Interviewing customers

As with any product design process, it’s important to do your research. Who will be using your design system and how will they use it? Your design system will get used much more often if you create it to fit into the workflow of other teams. By interviewing users, you can pinpoint problems ahead of time, define principles that will help others use the system properly, and focus your energies on the most important things.

A less common group of people to interview are members of your open source community. This exists more likely in organizations that provide developer tools for customer and partner communities. If you plan to open source your design system—a potentially bigger project—then you’ll need to speak with potential contributors and consumers to discover what use cases your design system will need to satisfy.

And then there are the executives, leaders, and management. It is important to get their thoughts as well. You will need their buy-in to support and fund the system. Listen to their concerns and use them as actionable goals and metrics to achieve. Examples of requests might be shipping features faster, better performance, and improved UI quality.

With insights in hand from customer interviews, it’s time to take an inventory. There are 2 types of interface inventories to be created:

  • An inventory of the visual attributes (such as spacing, color, and typography), which will help create a codified visual language
  • An inventory of each UI element (such as buttons, cards, and modals), which will help create a UI library of components

Let’s first focus on a global visual inventory.

Step 4 - Creating a visual inventory

Of course, if you’re starting a design system for a product that doesn’t yet exist, you can skip this step and jump straight to creating a visual language for your new product. Lucky you!

Conducting a visual audit

As we start to take inventory, it’s good practice to take a look at the CSS used to create all of those elements you just captured in your visual inventory. Use a tool like CSS Stats to see how many rules, selectors, declarations, and properties you have in your style sheets. More relevant, it will show you how many unique colors, font sizes, and font families you have. It also shows a bar chart for the number of spacing and sizing values. This is a great way to see where you can merge or remove values.

If you’re creating an inventory in Sketch, use the Sketch-Style-Inventory plugin to aggregate all colors, text styles, and symbols. It also gives you the ability to merge similar styles.

Step 5 - Creating a Visual Design Language

I must admit, as an art school graduate the visual design language in a design system is my favorite part to work on. I love thinking about color theory, typography, and layout, which are at the core of any design system.

If we break apart each component of a design system we find that these fundamental elements make up its visual design language:

  • Colors
  • Typography (size, leading, typefaces, and so on)
  • Spacing (margins, paddings, positioning coordinates, border spacing)
  • Images (icons, illustrations)

Depending on your needs, you may also include the following to further standardize the user experience:

  • Visual form (depth, elevation, shadows, rounded corners, texture)
  • Motion
  • Sound

Consider the role each of these design elements plays in a simple component like a button. A button typically has a background color, typography for the label, and spacing inside it. There may be an icon next to the label to create a visual cue. A border on the edge serves as simple ornamentation and may even round the corners. Finally, hovering over or clicking the button could trigger animation or sound as feedback to the user. Though a button may seem simple, there are many design decisions required to bring it to life.

Design Tokens


Before we dive into visual design standards, I want to discuss design tokens. Design tokens are the “subatomic” foundation of a design system implementation. At its simplest, they’re name and value pairs stored as data to abstract the design properties you want to manage. With the values for all design tokens stored in a single place, it’s easier to achieve consistency while reducing the burden of managing your design system.

Example:

SPACING_MEDIUM: 1rem

In design tokens you can store colors, spacing, sizing, animation durations, etc., and distribute them to various platforms.

Color


The colors you choose for your design system are more than just an extension of your brand. A UI uses color to convey:

  • Feedback: Error and success states
  • Information: Charts, graphs, and wayfinding elements
  • Hierarchy: Showing structured order through color and typography

Common colors in a design system include 1–3 primaries that represent your brand. If none of these work well as a link and button color, then you may have an extra color for that as well. It’s a good idea to use the same color for links and button backgrounds as it makes it easier for users to recognize interactive elements.

You’ll likely have neutrals for general UI backgrounds and borders—usually grays. And finally, you’ll have colors for states such as error, warning, and success. Group these colors to see how well they work together and refine as needed.

The in-progress book, Programming Design Systems by Rune Madsen, has some great chapters on color available online to read, including “A short history of color theory.”

Larger design systems sometimes include colors for objects and products. For example, at Salesforce we had a color for contacts, for sales deals, or groups, and so on. We also had them for products: Sales Cloud, Marketing Cloud, Analytics Cloud, etc. Color can be a helpful wayfinding tool for your users.

Using color for wayfinding can be tricky to do while maintaining accessibility, as people who are color blind may not be able to discern some differences.

Depending on how strict you want to be with your palette, you may want to include a range of tints—a color mixed with white—and shades—a color mixed with black. Sometimes you may use other colors instead of white or black to avoid muddiness, such as an orange to darken a yellow so it doesn’t appear brown.

These color variations allow designers to have choices. But be warned, having too many choices can lead to major design inconsistencies. Keep your inclusion of tints, shades, and neutral palettes slim to prevent misuse of the system while still giving designers the flexibility they need. You can always add more colors as you find the need.

Figure 11. The Pivotal UI style guide chooses to give a wide range of color tints and shades with their design tokens. While I personally prefer to only give a leaner set of options (as seen in the Sass style guide), some design systems prefer to offer more choices. Consider which approach works for you as you balance concerns like creative freedom versus tighter consistency.

Typography


Fonts and weights

The fonts you choose have a high impact on both your brand and your user experience. Keep legibility in mind as you select the right fonts for your system. Keeping to common system fonts like Helvetica, Times New Roman, or Verdana can be a great shortcut, as they are familiar to the user’s eye. Some companies prefer custom web fonts to better reflect their brand, but pay special attention to how you use them as performance can be affected.

Most design systems I’ve worked on include just 2 typefaces: 1 font for both headings and body copy, and a monospace font for code. Sometimes there’s an additional font for headings that compliments the body font. Most design systems do not have a need for more, unless you have a system that supports multiple brands. It’s best to keep the number low as it’s not only a best practice of typographic design, it also prevents performance issues caused by excessive use of web fonts.

Figure 12. Google’s Roboto shown in varying weights.

These days it’s trendy to use a font at a very thin weight, but be aware that legibility can become an issue. If you want to use light or thin weights, only use them at larger text sizes.

Type scale

When selecting the size to set your type, consider the legibility of the font you’ve chosen. In most cases, a 16px font size works well. It’s the default font size in most browsers, and it’s quite easy to read for most people. I like using 16px as it works with the 4-based metrics used by Apple and Google (and is gaining traction as the standard approach). I recommend this as your baseline, though I would use it in a relative format like 1rem for CSS-based systems.

You can use a modular scale for larger or smaller font sizes for other elements such as headings. A modular scale is a set of numbers in which you have 1 base number, and a ratio to generate the next number. You keep applying the ratio to the new number to get yet another number.

Learn more about modular scales to create more meaningful typography.

Figure 13 The Modular Scale tool helps you find one that works for you. It even provides a Sass version of the tool, which you could add to your design token set.

As you design your type treatments, be sure to give thought to how it will respond to various screen sizes to maintain legibility. You won’t want your headings to be too large for mobile devices. And for much larger displays, you have the room to bump up sizes.

A common method is to enlarge headings on larger viewports. You can also use viewport units to scale your type based on a percentage of your screen size.

There are many methods people use to create responsive typography. A more recent one to check out is the Fluid method with CSS Poly Sizing. Zell Liew’s The Rules of Responsive Web Typographycover basic principles and systems to know.

Leading

Leading, or line-height in CSS, can improve readability and aesthetics of your typography. While the best line-height can vary depending on the font face and the line length, a general rule of thumb is to have leading at around 1.4–1.5x the font-size. 1.5 is recommended by the W3C Web Accessibility Initiative.

Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

WCAG

WEB CONTENT ACCESSIBILITY GUIDELINES (WCAG) 2.0
W3C

It also makes your math more predictable, but you don’t have to calculate it. You can define your line-height without a unit of measurement and the browser will do all the hard math for you.

For headings, tighten it up depending on your typeface. In most cases, I find a 1.25 or 1.125 ratio works quite well.

Figure 15. Tachyons also use 1.5 for body and 1.25 for headings.

Spacing & Sizing


The system you use for spacing and sizing looks best when you have rhythm and balance. This means using numbers based on patterns and proportions. Using a consistent spacing scale also promotes maintainability through ratios by making layouts more predictable and more likely to “fit” and align well.

When I designed an Android app, I studied Google’s design guidelines. I noticed a pattern of using 8dp between elements and 16dp for outer gutters. It broke me out of using a 10-based scale I was accustomed to, as I found that 4-based worked so much better.

A 4-based scale is growing in popularity as the recommended scale for many reasons. Both iOS and Android use and recommend metrics that are divisible by or multiples of 4. Standard ICO size formats (which are used by most operating systems) for icons tended be 4-based (16, 24, 32, etc.) so that they scaled more easily. The browser’s default font size is usually 16. When everything is using this system, things are more likely to fit in place and line up. And finally, responsive math works out well.

Figure 16. The Google Android design guidelines (before this site was replaced by material design). Studying these guidelines made me a better mobile designer.

For horizontal spacing, an 8-based scale works quite well. You can make margins and padding equal or in proportion to the font size. But for vertical spacing, I tend to use a 12-based system. This is due to the line-height I get of 1.5 (with the default font size of 16px) getting us to 24.

Occasionally, you may have to break this rule. If you’ve added a 1px border to something, this border can throw off alignment by a hair. So you might find yourself using a padding or margin that subtracts that amount. This is something that you do on a case-by-case basis.

You probably want elements to grow and shrink with the content. For general sizing, avoid setting widths and heights unless totally necessary. You can achieve responsive design much easier if you let elements flow to fill the space they’re given in the layout.

Images


File formats

For icons and illustrations, I find using a vector format (SVG) works best for scalability and responsive design. However, if you find yourself needing to use photography, you may need to use a rasterized image format like JPG or PNG.

For most photos, illustrations, and diagrams, you can allow the image to go 100% to the container or viewport and let the height automatically set itself by not defining it. This works best for responsive layouts. You may also want to define some preset widths for images if you don’t want it to go full width (for example, half-width, a third, or a fourth). I recommend setting these as max-widths so that the image can rescale for smaller screens.

Iconography

Before drawing your icons, come up with your guidelines around them first. Will they be filled or outline? What is the line weight? Will they use more than 1 color? What sizes will they be? Is there an icon art boundary set inside an outer boundary?

Figure 17. Oracle Alta UI describes style guidelines such as perspective, strokes, and colors.

You may have different styles for different icon types. For example, utility and action icons (like a notifications bell or a settings cog icon) may be solid and 1 color, while navigation icons may be multicolored and more creative. Clear guidelines will keep your icons unified.

Figure 18. Apple shows the different icon types in their ecosystem: app icons, glyphs, and glyphs used on color.

Illustrations

Illustrations are a great way to add some character to your product. You can use these for empty states, loading screens, modals, and other components that invite visual interest. Shopify went to great lengths to produce unique illustrations for all of the empty states of their platform, which conveyed a strong sense of brand personality (figure 19).

Figure 19. Shopify’s illustration style for empty states.

Similar to icons, it’s helpful to have guidelines for the style of your illustrations (figure 20).

Figure 20. Illustration guidelines by Al Power.

Visual form

Visual form, or the material quality of your UI, is about the background images, gradients, and textures, shadows and elevation (z-indexes), rounded corners, and borders. These are visual qualities that help emphasize and decorate elements to add visual hierarchy and aesthetics. In any case, all are examples of ornamentation that need to be standardized.

Google does a great job indicating how depth and elevation work with layering of components (figure 21).

Figure 21. An example of depth through elevation in Google’s material design implemented through z-indexes and shadows.

Motion and Sound


When you define your visual language, motion and sound might not immediately come to mind. You experience these in a different way. But motion and sound can have a high impact on the experience of your app. You’ll want to have that systemized as well for consistency. I personally haven’t explored these areas as much as I’d like to admit, but there are some great examples in the wild.

Figure 22. IBM’s animation guidelines draw upon their rich history of products and technology.

Figure 23. While not very visually stunning, Microsoft offers guidelines into their sound API in their developer guidelines.

Step 6 - Creating a User Interface library

Before we conducted a visual inventory, which looked at the visual qualities of elements, such as color, spacing, and typography. Now, we will conduct a UI inventory, in which we look at the actual pieces of UI—like buttons, cards, lists, forms, and more. Where visual language is all about the visual approach and how things look on a global visual level, a user interface library (otherwise known as a pattern library) looks at actual components of a UI.

Let’s take a look at each of these design elements and the role they’ll play in your design system. Take stock of all interface elements in production to see just how much design debt you need to address and what elements are most commonly used. Warning! This can get a bit depressing, as most companies have an intense amount of inconsistency in their UIs.

To create an interface inventory simply open all products in production at your organization, screenshot all buttons, forms, various type styles, images, and collect them in a slide deck or on big posters where the whole team can see.

Visualizing design debt
If you have executives or engineers who are skeptical of the need for a design system, showing them your visual inventory can be a powerful way to communicate the design debt in your current products.

You can do this with cut out print-outs or through screenshots. Gather the folks you’re involving (as mentioned earlier in this chapter). Have them conduct this inventory with you, either through a shared presentation or via a hands-on activity. The idea is to gather the different components you’re using and categorize and merge them.

Some like dividing the pieces into elements, components, regions, utilities, and so on. Atomic Design is a great example of this line of thinking, which is a great conceptual model. But when it comes down to it, everything is pretty much a component, so at the end of the day, you could label all as such. But in general, what I see most design systems break things down into are:

  • elements (or basics, or atoms)—these are small, stand-alone components like buttons and icons
  • components (or molecules, or modules)—these are usually an assembly of small components into a larger component like a search form (which includes a form input, a button, and potentially even a search icon)
  • regions (or zones, or organisms)—these are an area of the UI like a left-hand navigation
  • layouts—how the pieces are laid out on the page (like a header region, followed by a sidebar and main content area, followed by a footer)

Figure 24. In From Pages to Patterns: An Exercise for Everyone, Charlotte Jackson goes over ways to conduct a UI inventory.

After you complete the inventory, you can merge and remove what you don’t need (either in a spreadsheet or even directly in a code refactor if you want more immediate change). Also, document what the component is and when to use it. This will become your UI library (or pattern library, or component library, depending on what your organization chooses to call it.).

Figure 25. The US Government agency 18F has one of my favorite UI libraries: the U.S. Web Design Standards.

Most design system documentation includes the component’s name, description, example, and code. Others may show meta data, release histories, examples, and more. What matters most is that you show what’s necessary for your team to get your work done.

Figure 26. The Rizzo component library by Lonely Planet.

ConclusionCreating a design system not only helps your team produce more consistent user experiences, it also builds bridges between design and development. By creating a common visual language codified through design tokens, and a set of components and patterns cataloged in a UI library, you’ll vastly improve designer/developer communication. You’ll also have fine-tuned control of the UI in a way that is manageable, scalable, and robust.

Enterprise Design Thinking


StepContent - https://www.ibm.com/design/thinking/

Introduction

Start learning the theory, history, and language of Enterprise Design Thinking.

Design thinking is for everyone


Learn what design thinking is and why creating experiences matters.

“Everyone designs who devises courses of action aimed at changing existing situations into preferred ones.” - Herbert Simon

Design thinking is the mindset that aims to improve the situation of people through the experiences they have. If you’re interested in solving problems for people, then you can practice design thinking.

So, what is the experience?

It’s more than any product or service

Think of the last time you had tea, coffee, or hot cocoa. Maybe it was this morning. How did it make you feel? Why did you drink it? What else were you doing at the time?

Chances are your answers to those questions are different than anyone else who drank a hot beverage recently. Those answers represent your experience.

Design thinking requires you to consider a person’s experience in order to focus on their human needs. Your customers don’t inherently care about the inner workings of a coffee maker: they seek a quick pick-me-up, a comforting chat, or something warm on a cold day.

experience - "the way a person feels, and what they think while they’re doing something"

A vase is a vase is a vase

Were all those vases similar to yours? The prompt (design a vase) was too narrow for innovation and creativity to flourish...a common problem in the enterprise world.

Let’s take a step back, open the aperture a bit. Why would someone buy a vase? What purpose does it serve? A vase is only one way to enjoy flowers in your home. Try the activity again, but this time think of it as an experience.

https://www.ustream.tv/recorded/120268623

Design thinking isn’t just for designers

users - "the people who interact with the thing, service, offering, system, etc. that you make"

Design thinking isn’t just for designers

Even though it includes the word “design,” design thinking is a mindset that anyone can apply. It simply means that you’re starting to think like a designer—about how you can improve the current experience of the people you serve: your users.

Put the “enterprise” in Enterprise Design Thinking


Learn the framework of Enterprise Design Thinking and why it’s necessary for modern enterprise work.

You aren’t in the flower business

Think back to the vase experiment in the last lesson. Enterprise businesses don’t often face vase-sized problems. We work with problems that shape industries and governments. The nature of these problems requires a special flavor of design thinking that can cover the scale and complexity we face in our daily work.

An Overview of Enterprise Design Thinking

https://www.ustream.tv/recorded/119982334

Watch this video to see what Enterprise Design Thinking is about and why it was created.

Enterprise Design Thinking

a tailor-made approach for large, distributed teams to help them quickly deliver human-centered outcomes to the mark

Our shared language

We all communicate through language. But, communication easily breaks down when we aren’t speaking the same language. Throughout this course, you’ll explore the vocabulary of Enterprise Design Thinking and start to put the words to work. The Framework allows you to speak about design thinking across large teams and companies and stay on the same page.

The Enterprise Design Thinking Framework

Take a minute to explore the vocabulary of Enterprise Design Thinking.

The Principles

The Principles guide your day-to-day work. They ensure you’re keeping your user in mind, collaborating with a diverse team, and continuously trying to improve your solutions.

The Loop

Understand the present and envision the future in a continuous cycle of observing, reflecting, and making.

The Keys

Scalable practices for enterprise team alignment

The Principles guide your day-to-day work.

They ensure you’re keeping your user in mind, collaborating with a diverse team, and continuously trying to improve your solutions.


A focus on user outcomes

Drive business by helping users achieve their goals.

Restless reinvention

Stay essential by treating everything as a prototype.

Diverse Empowered Teams

Move faster by working together and embracing diversity.


The Loop

Understand the present and envision the future in a continuous cycle of observing, reflecting, and making.


Observe

Immerse yourself in the real world with design research. Interview users, watch them work, and test your ideas with the people who matter most to inform your decision-making and understanding.

Reflect

Come together and look within to synchronize your movements, synthesize what you’ve learned, and share your “aha” moments with each other. Decide together and move forward with confidence.

Make

Give concrete form to abstract ideas. The earlier you make the faster you learn. Put your ideas out there before they’re complete and improve them as you go.


The Keys

Scalable practices for enterprise team alignment.


Hills

Align your team around the meaningful user outcomes you want to achieve. Hills are statements of intent written as user enablements. They follow a format of Who, What, and Wow.

Who: Who is your user? Refer to them by name.

What: What will your user be able to do that they couldn’t before? Start with a verb and avoid solutions.

Wow: What differentiates you from the competition? This is measurable.

Playbacks

Stay aligned by regularly exchanging feedback. Playbacks are story-based presentations that share insights, ideas, and updates to a user experience.

Sponsor Users

Invite users into the work and stay true to real-world needs. Sponsor Users are external clients, future clients, or end users that represent your target user, who regularly contribute domain expertise to your team. Relationships with Sponsor Users are typically formalized with an agreement that covers confidentiality and our right to use their feedback.


The Enterprise Design Thinking Framework

Keep these terms top of mind.

Prepare yourself


See examples of teams successfully using Enterprise Design Thinking to solve complex problems and gear up for the rest of the course.

https://www.ustream.tv/recorded/119982034

Watch this team use Enterprise Design Thinking to improve their users’ experiences.

Change is hard

tools - "activities and resources that help your team work collaboratively to yield specific artifacts. Explore them in the Toolkit."

https://www.ibm.com/design/thinking/page/toolkit

Business as usual: a team sitting and listening in a meeting.

Enterprise Design Thinking: a team collaborating around a board.

The team you just saw is doing great things with Enterprise Design Thinking. But this definitely isn’t their first time practicing it. Adopting Enterprise Design Thinking and experiencing the great outcomes that you just heard about doesn’t happen overnight.

Like all of the best things in life, Enterprise Design Thinking is an ongoing journey filled with highs and lows. It takes some effort and commitment, but the results are worth it. This platform is designed to give you the tools and knowledge you need to address the challenges and harness the opportunities you will face as you begin your practice.

Are you ready to dive in?

Your challenge

All Enterprise Design Thinking initiatives start with a business problem, like low employee retention or uncovering a new market segment. In the next few lessons, you’ll work through a business problem by framing it around human experiences and learn the Principles of Enterprise Design Thinking along the way.

A focus on user outcomes

Drive business results by focusing on your users’ needs.


Restless reinvention

Treat everything like a prototype so you can quickly improve solutions

Bias toward action


Learn how viewing everything as a prototype is the key to breaking out of the status quo.

The slow and timid enterprise

Your smart phone updates its operating system seamlessly in the background. Your neighborhood café changes its menu seasonally. So why does it take two years for your team to update your users’ experience? Even when you do get to make changes, they’re small and feel like they might be irrelevant.

Modern expectations

“The last best experience that anyone has anywhere, becomes the minimum expectation for the experience they want everywhere.” - Bridget Van Kralingen

Quick and continuous improvement used to be a luxury, a way for companies to differentiate themselves. Today, people expect to see constant updates. You can inform those updates with easily gained knowledge about the people you serve.

"restless reinvention" - a principle of Enterprise Design Thinking that represents active continuous testing and learning in order to improve the solution to a problem

https://www.ustream.tv/recorded/119982516

Restless Reinvention: Our Work is Never Done

See how the Principle of restless reinvention encourages you to harness the knowledge you have to continuously improve.

prototype - "a first or early example that is used as a model for what comes later"

Horse-drawn carriage

Self-driving car

If you start looking at everything you make as a work in progress, you can begin to shift your mindset from waiting until something is perfect to waiting until it’s ready. This mode of working enables more regular delivery of value to users.

Consider this: We’re still improving the way we get from Point A to Point B. Yesterday’s horse-drawn carriage was a prototype for today’s automobile. Today’s automobile is just another prototype for tomorrow’s transportation breakthrough. We’re really never done and no solution is ever perfect, but people experiment with how to improve this experience daily all over the world.

Give form to ideas

Everything starts as an idea, but you can’t learn much about an idea without giving it some form.

Visualize your ideas, so that your team and users can understand them clearly. Making doesn’t have to be intricate. It can be as simple as a sketch on a napkin—but it does need to communicate the idea enough for someone else to understand it and give you feedback.

Low stakes, big reward

Take the pressure off yourself. Acknowledge that making something quickly and putting it in front of people is the best way to learn if your ideas suit their needs. You can always toss the piece of paper in a recycling bin. This makes it easier, cheaper, and faster to challenge the status quo with new ideas, and iterate on them until they’re ready for the real world. This way, you can meet your users’ expectations and your market deadlines.

iterate - "to change something existing (an idea, a product, a service, etc.) in small or big ways, gradually, as to improve it"

Try it today

The next time you have a new idea to share with your team, before you tell them about it, draw it on paper. Think about how a diagram or visual representation might convey something that words couldn’t. After all, a picture’s worth 1,000 words.

Kiến thức về UX Design


Nội dungURL

Group:
UX Metrics Framework
Tips:
UX Team
Guide to Product Prioritization Frameworkshttps://medium.com/pminsider/epic-list-of-every-product-prioritization-framework-1e213d264c7a?fbclid=IwAR0XJd3xjmZfVrbUtjiV5SsGD5UE3a_ykW61s0YbVX7-zDzYTN9fR1rUiV0

SaaS Metrics:


  • No labels