Home  >  Posts  >

Last month, I wrote about how our team started raising the bar of our user experience design efforts over the last two years. From those efforts, we identified and shaped a new UX design deliverable that’s become core to our process—the UX Plan.

This week, our lead senior product designer, Noah Stokes, posted an article about UX Plans called How I Design with Dropbox Paper or How the UX Plan was Born. It captures what the UX Plan is, why we created it, and how it’s helped us improve our process, collaboration, and user experience work in our product design.

This article is a technical onboarding document that can help you write your own UX Plan. It captures the detailed structure and syntax that we use.

If you’re interested in adopting this deliverable for yourself or your team, open the two reference documents below and read on!

Documents for use and reference:

• UX Plan Template — Copy this Dropbox Paper template when you need to start a new UX Plan from scratch.

• UX Plan Example: Following Feed Page — Use this example document as a reference for putting together a Page State that has multiple User States underneath.

Inline vs. Separate UX Plans

• For smaller product projects and a/b tests in which you intend to tackle only one page and/or user states, we recommend keeping a lean version of the UX Plan inline in a Project Scope.

• For medium and large product projects, we recommend creating UX Plans as a stand alone Dropbox Paper document.

Setting Up A New Doc

• Open the UX Plan Template.

• Start a new Dropbox Paper document.

• Copy the template to your document

• Create the title for your UX Plan using the following format: “UX Plan: ProjectName V#”

• The project name should reflect the name of the feature or experience that you intend to work on.

• The version number defines if it’s the first or subsequent one. You may version beyond V1 if you’re UX Plan receives too much feedback that requires reworking or if it’s a feature in a later round of updates.

Using Emojis

• At the top of every UX Plan is a key with 5 emojis that are used in the UX Plan. The purpose of the emojis is to serve as a quick visual label inline in the document in order to flag the viewer of supportive project needs.

• Placement: The heart emoji is placed at the end of the Page State or User State. The other four emojis are placed in front of the content that they impact.

• The heart emoji is used to flag Page or User States that the designer intends to produce a wireframe or comp for (depending on the phase of the project). It can be added by typing in “:heart” inline in the document.

• If it’s placed at the Page State level (“1. Page Name”), then it indicates that the entire page will be wire-framed or comped.

• If it is placed at the User State (e.g. “Signed-In Customer”) or Content State (e.g. “Post Editor”) levels, then it indicates that an additional wireframe or comp variation will be produced as a separate deliverable. This additional deliverable could be either a variation of the work within the frame of the entire page, or isolated as a standalone content or element design variation.

• The sparkles emoji is used to identify a supportive visual that the product designer would like to request the help of a brand designer to produce. It can be added by typing in “:sparkles” inline in the document.

• Examples of brand visual requests are as follows: spot icons, spot illustrations, hero illustrations, unique background treatments, and other similar visual design needs.

• Brand visual requests should be submitted to the product or project manager, who will find and schedule a dedicated brand designer to collaborate with the product designer on the request. They will work with the brand designer to define the scope and a timeline for the work requested, too.

• The memo emoji is used to identify places where copy support is needed. It can be added by typing in “:memo” inline in the Dropbox Paper.

• If copy needs are minimal (e.g. headlines, short descriptions, etc.), it is preferred to keep iterations inline in the UX Plan. Identify which pieces are final by striking-through or deleting the past variations.

• If copy needs are extensive (e.g. long paragraphs), then is is preferred to move all copy to a stand-alone document and only port over the final versions to the UX Plan once they are locked in.

• Copy support should be submitted to the product manager, who will schedule with the copywriter to create and refine variations of copy for the product designer to roll into the UX Plan, wireframes, and comps.

• The chart emoji is used to identify conversion points that the team wants to track on this page state. It can be added by typing in “:chart with upward trend” inline in the document.

• The chart emoji is added to primary buttons, links, and tools that the product designer and product manager select as needing tracking to be added during the development prototype phase.

• The tool emoji is used to identify areas of the product experience that the product team wants to include in a quality assurance (QA) or user testing phase. It can be added by typing in “:hammer and wrench” inline in the document.

• Adding this emoji to call to actions, buttons, links, and more will let the product team know which points of the experience are required to be tested thoroughly after the build is ready for review.

Writing the Summary

At the top of every UX Plan is a project summary. Each piece of information provides updates on what the deliverable is and where it was left off. This makes it easy for anyone to jump in, get some context, and understand the design intention of a product project.

• Last Update: This defines the last date that someone updated this UX Plan. The initials (e.g. "NS")) identify which team member (e.g. "Noah Stokes") made the last update.

• Asana Task: This is a quick link to the (parent) project or task related to this UX Plan. (Note: Our team uses Asana for project management.)

• User Flows / IA: If you produced UX deliverables such as user flows or information architecture, link them up for reference here.

• User Stories: Capture short-hand user stories here. They should be in the form of “As a [user type],..”, and we encourage capturing 4 to 8 stories depending on the scope of the project. Don’t keep “users” as the label for the user. Narrow in on the type of user (shop, customer, visitors, etc.). Focus on the primary KPIs first. For example: “As a Shop Owner, I use the composer to post content updates to attract new customers in the Shop Updates feed about my new products after I launch them.”

Building Page & User State Sections

Now, let’s begin building a new UX plan. Start by listing out all of the Page States and User States that a project intends to impact or needs to have designed. Whether it’s new feature or an update to an existing page or flow, capture the hierarchy of your states using a simple numbered list using the following format pattern:

Page States

• This is the page experience (state and type) that you’ll be designing from scratch or making improvements on. Use the Page State label to capture the page title (and type if it’s useful).

• Here are a few examples: “Following Feed Page”, “Single Product Editor”, “Sitewide Navigation”, and “Keyword Category Directory”.

User States

• User States allow us to define contextual experiences of the same Page State for different users and their journey in the product.

• Users have logged states, transition states, and account permissions that should be considered as you build your UX Plan.

• You can pair the user type and user state with this label, but the minimum requirement is to capture just the user type(s) with the User State label.

• Here are examples of the options that you might have available to pick from: All Users, Signed-In Users, Signed-Out Users, Customers, Vistiors, Affiliate Members, Admin, etc. To be more clear, here is what your User State might look like underneath a Page State: “All Signed-In & Signed-Out Users”, “All Signed-In Users”, and “Signed-In Shop Owners”.

• Here’s an example of the Page State and User State together:

User State Summary Table

• Before you list out the Content States, add an inline table that summarizes the important information for each User State inside of the Page State. This will help you create simple high-level context for deviations if different users have various experiences on the same Page State you’re designing.

Definition and options for each row are as follows:

• Page Type: This is where you define the type of page experience. Options available might look like the following: Normal (web page), Email, Modal, Inline State, App, Other: _____.

• User Types: This is where you define which of your users will have access to and engage with the page state. Options available might look like the following: All, Shop Owner, Customer, Member, Visitor, Affiliate Partner, Admin.

• User States: This is where you define the unique status, permissions, and activity level of the users as needed. It’s most useful when user state deviations are created under page states (e.g. a) Signed-In Shop Owner, b) Signed-Out New Approved Shop Owner, etc.). Only add what’s useful. Too many user states complicates the table information. Combine status, permissions and activity as needed.

• Options for status might look like the following: new, onboarding, existing, signed-in, signed-out, signing-in, signing-up, signing-out, exiting.

• Options for permissions might look like the following: approved, waitlisted, disabled, author (blog), ghosted (admin only), private, public, owner view, other: _____.

• Options for activity might look like the following: active (various levels), inactive (various levels).

• User Flow: This is where you define the user’s experience based on the User State within this Page State. It’s not meant to be a place where the entire user flow is capture — that should be capture in a formal User Flows deliverable. Use this to define the previous location the user came from using the label “(prev)”, and the primary location (via primary CTA or KPI) that you want to help them go to next using the label “(next)”.

• Devices: This is where you define what your target devices are. Options might look like the following: Desktop, Tablet, Mobile, App, Other: ___. If all devices are listed in this area, the Page State, User States, and Content States should all be designed and implemented across them. If there are contextual variations (e.g. hide this stuff on mobile or add this back to top button on mobile), then separate Desktop and Mobile into their own Page States with the device label at the Page State name level, and call out the differences on the Mobile version beneath the Desktop version.

• Reference: This is where you provide quick, relevant links to individual Page States and User States that you produce deliverables for. As you iterate on variations, continue to update these links to the latest variation that is approved and moving forward. This simply looks like updating the link and the label at the end of the link title (e.g. adding “V1, V2, V3, etc.” to each link). Options for this might look like the following: InVision Prototype, InVision Board, Dropbox Files, Live HTML Page, User Flows, Other: ____.

Filling in the Content States

Ok. Now comes the most important step: filling in the Content States. The goal of adding information into the Content State under each User State is to be as prescriptive and simple as possible.

You’ll be planning all content that you intend to produce wireframes and/or visual comps for by listing them out as you intend them to display on the page in a top-left to bottom-right hierarchy. Simple, right?

The Approach

• New Page States: If you’re going to be designing a new Page State, then list out all visible and hidden content that you plan to design.

• Editing Existing Page States: If you’re only editing one or more individual elements or content areas on an existing Page State and leaving the rest of the content intact, add a simple note that defines where each Content State should be placed in the page hierarchy. (e.g. “Note: Insert this between the site-wide navigation and product title.”).Avoid listing out all the content on the page to avoid redundancy and clutter.

Building the Bullet Lists

Allow for up to 4 tiers deep of bullets. If you can’t prescribe and define everything in under 5 tiers of bullets in your list-making, then try to scale back the level of detail in the Content States area.

Content Features Level

In order to make the bullet list syntax easier to consume, begin with listing and underlining the primary Content Features (think modules, divs, tools, or sections) on the page at the first level of the bullet list. Add all of them that you can think of in order to create an initial outline for the page. You may miss some of the hidden interaction states, but they’ll reveal themselves as you dig in and build your UX Plan.

For projects in which you’re only adding or editing existing page states, it’s recommended to put an inline note at this level to ensure that the content is located on the page in relation to other pieces of content around it.

We use titlecase and underlining for these Content Features. You’re allowed to use parenthesis or a colon if you need to add more label clarity about the Feature you’re describing. If there’s something unique to call out, make sure it’s in the label. As you list all of your Content Features, they should be in the same hierarchy order that you intend to place them in the page layout. You can use labels such as “Grid”, “Module”, or “Tool” to define the type of content that might be defined in each Feature section.

Here’s an example of what a few Content Features looks like in hierarchical Page State order:

Content Element Level

Then, fill in the next level of bullets with Elements such as copy, click triggers, brand visuals, product thumbnails, and more. At this level, the goal is to truly define and prescribe the actual user interface content (read: Content Elements) on the page. If you require brand, copy, tracking on any element, add in the corresponding emoji at this level. This will flag the project team on additional needs inline so that work can be requested and begin as soon as possible.

Element Writing Syntax: Particular elements have style and functionality considerations that yoy may define require subtle text treatments to subtly stand-out in the outline. Here are the most commonly used conventions:

• Copy: We use quotes to surround written copy. (e.g. “Copy goes here.”)

• Buttons: We use brackets to prescribe a clickable trigger link. It usually denotes a button, but we follow the brackets with the copy “button” (if available) to prescribe button UI. (e.g. [“Follow This Shop”] button)

• Type Styles: We call out type styling using parenthesis. (e.g. (H1), (body copy), etc.)

Using one of the Content Features from section above, here’s an example of adding in Content Elements with emojis looks like:

Content Interaction Level

Next, add in Content Interaction at the next level deeper of bullets. At this level, you should prescribe functionality and interactions with buttons, controls, etc., and start to unpack the experience behind the user interface.

There are two commonly used conventions, which are as follows:

• Em Dashes: Help you to flag hover and click interactions (e.g. “On Click — Select this product and highlight the border yellow”).

• Notes: Use “Notes:” or “Dev Notes” to capture additional insights about interaction functionality, hard requirements, error validation, and other contextual instances based on user actions and product variations.

Using our same example, here’s a look at the next tier of bullets that capture interaction states:

Four tiers deep of bullets within your Content States details should be sufficient. If you have to go to a fifth depth of bullets, then you might be providing too many details. Use what you need, but if you have 12+ interaction bullets for each Content Interaction bullet, you might be using the framework poorly by over-detailing the work.

About Complex Content Interaction Variations

If you find yourself creating one or more contextual variations at the Content Element or Interaction levels, it’s a good idea to break them out into their own User State section. It’s not ideal to tech-tree lots of User State variations at the Element or Interaction levels that require design deliverables.

• Allow for up to one bullet list deep of possible contextual variations that you intend to flag with a heart inside of the Content Interaction level. This usually looks like one variation. If more complexity persists, break it out into its own section.

• If you need additional contextual variations broken out, make sure to spend more time unpacking what is really happening in the user experience for these. Provide additional clarity and UX oversight as needed.

Feedback

As you collaborate with the product manager, product team, design team, etc. in building the first (and subsequent) version(s) of a UX Plan, it’s a good idea to solicit for and roll in approved feedback inline in this document. We encourage collecting feedback through two approaches.

Approach A: Inline Comments

• As the project team starts to review a UX Plan, they should supply inline comments for you to review.

• You may respond with an answer that clarifies and resolve the comment.

• You may respond with a question to get more information or call for a meeting discussion.

• You may respond with an agreement, roll in the edit live in the document, and resolve the comment.

• Repeat this process as needed.

Approach B: Meeting Feedback

• For feedback collected during a meeting, we recommend building a section at the bottom of the UX Plan that’s labeled “Feedback”. Place a divider above the label to separate it from the plan.

• Then, add a sub-section for each round of review. Here’s an example of that label: 2/3/17 Meeting Notes 2/3/17

• Identify if a facilitator or you will capture notes. List them out in simple bullet list format. Keep the writing as concise as possible.

• If an individual gives insightful feedback that you want to dig into more after a review, add their initials in brackets next to those items (e.g. [NS]). This can help you remember who to contact after the review for follow-up.

• After capturing notes, collaborate with the product manager to determine which pieces of feedback should be rolled into the UX Plan. Move these bullets out of the meeting notes into a section below and transform them into checkbox bullets instead. Check them off as you make changes to the UX Plan.

• Repeat this process as needed.

[Optional] Post Project Visuals Archiving

Lastly, if it’s helpful to the project team, it’s ok for a product manager or designer to post the latest visual comps that we built and shipped against this UX Plan inline at the bottom of each User State area. The comps should be scaled down to thumbnail size and still be clickable to zoom to up to 100%. This visual comp inline archiving can help viewers visualize complex bullet lists within the Content States more quickly and easily.

[Optional] Post UX Plan Creation QA Test

After the UX Plan, visual comps, and design/dev protoype has been created, you can come back to the UX Plan and add QA emojis to create a quick QA plan for the team.

If you aren't familiar with UX Plans and want to learn more, head over to Noah's post How I Design with Dropbox Paper or How the UX Plan was Born.

I hope that you found this UX Plan Rules document helpful! If you have questions or needs, feel free to reach out to Noah or I for help.