A See | Do is a visual way to capture actions a user will take when using an application. A See | Do literally maps out what users "See" in each interface and what each component needs to "Do" — or what the expected outcome will be.
Why not just build a sitemap?
Sitemaps are useful for determining the page structure of an application. A See | Do is less of a sitemap and more of a user experience map, visualizing key actions a user will take in an application or key feature.
A See | Do follows the atomic design methodology, which is based on atomic theory. If you slept through high school chemistry, don’t worry – here’s what you need to know:
- Atoms: The basic building blocks of any system, such as inputs, buttons, images and links. At this level, we define how these parts are presented in active and inactive states, their animations, workflows and interactions with other parts,
- Molecules: Natural groupings of atoms are defined as molecules. A common molecule is an address form.
- Organisms: A collection of molecules creates a whole component, defined as an organism. While molecules are smaller parts — such as a login form or a navigation menu — organisms are whole sections.
- Pages: Real content, placed in a template for testing. Includes images and copy, with the goal of providing a solid feel for how the component work together.
- Templates: A first look at "screens." It's good practice to envision a desktop/phone/tablet template for the same "screens" or component sets.
- Project DNA: Commonly known as a Living Style Guide, the Project DNA contains every element of the Atomic UX Design Process including colors, fonts, CSS and HTML. Changing elements within the Project DNA are reflected over the whole project.
A See | Do shows both happy paths and sad paths. Happy paths are what happens when something happens the way it was intended; sad paths are what happens when an error occurs.
Why Use a See | Do?
A See | Do is a great way to show what an application needs before starting on the wireframes, and it facilitates key conversations early on in the process. See | Dos can help us determine the the tech stack we use, the APIs we need to connect with, user flows, core pathways and components — giving designers, engineers and product owners a shared orientation to the project from the from the very beginning.
While See | Dos focus on UX and core pathways, Component gathering allows us to map every interface element on a page or feature.
Components and See | Dos have similar structures, but components are designed with a full gray background instead of a gray border.
The Development Process
When we start a new epic for a project, we begin build out a high-level See | Do.
Once complete, the See | Do is placed in InVision and linked to that epic card in our project management tool. After the core pathways are established, the component gathering will take place for each of the job stories defined in that epic. The component map will be placed on each job story card. From there, an engineer can begin building the scaffolding for the application, while the designer works on wireframes.
There are many ways to approach a See | Do, and every project is different: some may call for a deep dive into a specific use case, while surface level may be sufficient for others.
Finally, keep in mind: See | Dos are not meant to be final. They aren’t the end-all, be-all for a feature or epic. They exist simply to help us better understand what we’re building before we build — and to help clients visualize the product before they actually see it.