4

The mise en place of product design

 1 year ago
source link: https://uxdesign.cc/the-mise-en-place-of-product-design-e1b5050f528b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

The mise en place of product design

How to organize your design files in a way that mirrors the design process, creates visibility into our work, and highlights the strategic value of product design.

A birds eye view of an organized desk and workspace

Photo by UX Store on Unsplash

At the start of each work day, I clean my immediate physical space. It’s my version of ‘mise en place’; a French culinary phrase which means “putting in place” or “gather”. Professional chefs use mise en place because it optimizes their work for speed and efficiency. It’s also a term used by psychologists and refers to:

“how a given environment places constraints on what one feels able to do within that environment, and how these assessments and predispositions impact the process of preparing to act.” Wikipedia

Organizing my physical space helps me mentally and physically prepare for the day’s work. The same rule applies to the digital spaces I work in.

When I first started out in design I was curious about what other product designers’ art boards looked like. How did they organize their digital workspaces? In the spirit of helping others just starting out or those with small design teams, I’m sharing how I break down my design files and what I’ve learned after 5 years working as a designer within a UX design and research team of over 300 people.

General layout

At the onset of every project, I organize my artboards in Figma according to the general design process. This helps keep my workspace clean, and illustrates the thinking and decisions that went into the final solution. This also makes navigation easier. How you label your pages and frames is important.

Frames and artboards arrangement inside a page can give an idea of the relationship between screens, if it’s used in a consistent manner between pages and pages. — Design Good Practices

My design files are shared with other designers, engineers, and product partners and they will reference a specific frame in a specific art board. Just like a book, it’s easier to be on the same page (literally) if the chapters and page numbers are unique. This naming convention was adapted from Nick Smith, a senior principal designer at LinkedIn.

The art boards are organized as follows:

  • 0.0 Cover
  • 1.0 Thoughtwork
  • 2.0 Block models & wires
  • 3.0 Screens
  • 4.0 Deck
  • 5.0 Explorations
  • 6.0 Appendix
A screen shot of Figma page organization

Each frame within a page is numbered in reference to the parent page. For example, if the parent page name is “6.0 Appendix”, the first frame of the appendix will be 6.0. The second frame is 6.1, and so on.

To make this easier, I use a plug in called Rename It which automatically names your frames.

Screen shot of a Figma board and the Rename It plug in.

Thoughtwork

Before touching high-fidelity screens or wires, I do thoughtwork. At this stage, I wrap my head around the project. This page is where I articulate the goal of the project, the problem, visualize any quant and qual research, and any competitive or comparative audits. As the project progresses, I may come back and add to this as I develop visual diagrams, information architectures, or systems maps.

Thoughtwork can be difficult to justify in a timeline with cross-functional partners who are not familiar with the design process, but it is integral. Think of thoughtwork as the foundation of a house; you want the foundation to be solid. If you build a house on shaky foundations, the beautiful paint job won’t matter because your house is falling apart. A contractor will have to rework the foundation and subsequently the paint job. You see the metaphor there? If you jump into high-fidelity designs without adequately understanding the problem space you may need to rework your high-fidelity designs later on.

As a designer, you have a superpower; you can visualize complex systems in a simple way that can be quickly understood. Thoughtwork is for your benefit and the benefit of others. On past projects, I created diagrams to help me understand the problem space, which continue to be shared and utilized by the team.

As an example, I worked on LinkedIn audiences. There are many different types and I wanted a way to easily communicate the different audience types, their make up, and their relationship to one another.

Figure 1 is a concept map illustrating the different types of audiences similar to a family/genus/species model.

A systems map illustrating the make up of different audiences and the relationship between each audience.

Figure 2 illustrates the makeup of each audience. Audiences is the parent category, under which there are saved, matched, and LinkedIn templates. Saved audiences always have at least one geographic location and at least one other attribute. Matched Audiences can contain companies or contacts. A LinkedIn template contains attributes.

A systems map illustrating the make up of different audiences and the relationship between each audience.

Hugh Dubberly of Dubberly design is “known for excellence in information design, especially for using concept maps to represent complex topics and processes”. Dubberly was my professor in graduate school at California College of the Arts and taught a systems thinking course. He explained that a systems map is a design artifact that can be built with and refined in partnership with your cross-functional team. Many designers learn by doing and the creation of information maps helps designers understand a problem space. Maps are also a tool to gather more information from stakeholders. After creating the first draft, I’ll share a systems map with my team to make sure my understanding is correct. New information emerges in these review sessions. Sometimes these maps are being built as the team is building and defining a product or model, so they evolve over time and can help the team more deeply understand the system.

To give a concrete example, Dubberly mapped a model of Alzheimer’s disease “to start a conversation about design opportunities in the world of Alzheimer’s. The large circles in the diagram — education, community, clinical, environment, caregiving and research — provided jumping off points for brainstorming solutions to AD.”

A systems map of Alzheimers

As you go through a project, systems maps will evolve and become more specific. The following illustrates that ‘audiences’ is the parent page, which contains children and grandchildren pages. Each grandchild page has its own ‘details’ page.

An object oriented model framework with ‘audiences’ as the parent, their children, and grandchildren objects.

These high-level systems maps later inform user flows and wireframes, which I’ll cover in the next section.

User flows and wireframes

The goal of a user flow and wire is to communicate, in broad strokes, how a product will work. Working with block models and low-fidelity wires allows one to iterate quickly and have strategic conversations. It’s important to work in low fidelity first because it focuses your work and stakeholder feedback. For example, if you share high-fidelity designs when you are looking for feedback on the general direction of the product, you’ll spend time discussing visual design, which isn’t valuable at this stage.

To start, I’ll write out in hand an ideal user flow in plain language and will translate that into a block model. The block model shows an ideal state flow, highlighting the key screen and any actions the customer takes.

A block model or ideal state user flow

Next, I’ll get into wires. The wires are a higher fidelity version of the block model and highlight only what is necessary. No emphasis is placed on visual polish.

A wireframe

In some instances, wires can be used to generally communicate the layout and functionality of a page. This is useful when a page scales to support different types of content.

A template of a page in wireframes, with annotations

Screens

By this point, you should have a really solid idea of what you’re building, so this step shouldn’t take too long. The stakeholders have seen the thoughtwork, wires, and user flows and have (hopefully) bought into the product. As a result, this stage can go quickly. This is where you can get into the finer details, such as information hierarchy, padding & colors.

A high fidelity page to create a new account in campaign manager on LinkedIn

Specs

My design files are viewed by marketing partners, product, other designers and engineers. The following topics outline what I typically provide to my cross-functional teams.

Clean design

A design with no mark up used by marketing partners for decks, sales onboarding, and marketing materials. The design above is an example of a ‘clean’ mock-up.

Design anatomy

This outlines the governing rules, layout, and functionality of a page or elements on a page. The following design outlines the layout of a row of data in a table.

A row in a table with each field annotated

States

Outlines what designs look like in a populated or empty state, or any errors. The following is an example of an empty state.

An empty state in campaign manager on LinkedIn

Red lines

Outlines design details such as font, weight, typeface, spacing, and color. Some designers prefer to ask their engineering partners to use the ‘inspect’ feature of Figma to save time, but I prefer to create my own redlines because it helps confirm that my designs adhere to LinkedIn’s design system.

A module with specs outlining spacing between elements
A module with specs outlining corner radius, color, type face and components

Explorations and Appendix

Finally, it’s worth having an exploration and appendix section. Keep your work in progress. I will often revisit past design work in my explorations page to leverage later.

Conclusion

Your design files should reflect the overall design process to guide your work, help cross-functional partners navigate your file, and finally illustrate the thinking and decisions that went into the final solution. Partners not familiar with the design process may wonder what we do all day (actually many family members wonder what I do all day). Organizing your design files in a way that mirrors the design process creates visibility into our work and highlights the strategic value that product designers bring to the table.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK