Design Process Best Practices: Documentation for Driving Design Forward — Part 4

This is the UX Design Process Best Practices ebook, written by Jerry Cao, Ben Gremillion, Kamil Zięba, and Matt Ellis, and originally published on

UXPin ebook
UXPin ebook

Design as Documentation

During the actual design process, documentation becomes more than just pieces of paper to pass around — they become the design itself.

For starters, they are concrete forms of previously abstract ideas. With every new iteration — every new document — your ideas become more and more tangible, up until the finished product. They also allow easy backtracking. Each stage is recorded so you can revisit an earlier version, which comes in handy with constant usability testing proving what works and what doesn’t.

Not to mention, design documents ease collaboration, both as physical representations for explaining ideas, and as sharable documents that can be edited across a team.

All of these documents bring something unique to the design process, but that doesn’t mean every product design needs them all. Aside from wireframing and prototyping — which can benefit any project — the rest can be decided based on the project’s individual needs. For example, a site map might not be necessary for a long-scrolling one-page site, but essential for a 100-page site with complex taxonomies.

Read our advice below to see which ones can help you most.

There’s no simpler way to document an idea than to simply draw it. In fact, this was how UXPin CEO Marcin Treder jump-started the (re)design process of the Yelp site as part of an exercise, which you can read in its entirety in our free User Testing and Design: Improving Yelp’s website.

UXPin ebook
UXPin ebook


The basic simplicity of a pen-and-paper sketch is its strongest advantage. Sketches allow for quick and easy sharing of ideas since their rough nature invites honest feedback.

Because they’re so easy and noncommittal, they’re a great way to get the creative juices flowing at those crucial early stages when no other designs documents exist. Sketching is ideal for brainstorming sessions and design studios (see below), where ideas should be proposed, trashed, and recycled rapidly.

Moreover, anyone can make a sketch, so “less artistic” specialists like marketers or executives can still illustrate their suggestions with less fear of judgment.

Best practices

The important guideline for sketches is to not focus on how good they look. The point is quick and easy, so don’t get bogged down on details that will likely be changed later.

In fact, during collaborative sketching sessions, rough sketches are actually better: they leave details open-ended, which helps generate more ideas from the team — this is known as “divergent thinking,” which we describe in our Design Collaboration in the Enterprise.

In the same ebook, we also recommend design studio exercises as a way to generate ideas in the early phases. These are regulated design activities that facilitate both brainstorming and interdepartmental collaboration through sketches. For the specifics of the process, watch Todd Zaki Warfel describe his method.

UI designer Jake Rocheleau recommends what he calls “thumbnailing.” This is simply sketching images as smaller than their actual size in order to speed things up and keep from getting sidetracked with the details. Focus less on the details and more on structural items like the navigation, column sizes, and column positions.

User flows chart the actions a user takes with your product. While user scenarios focus on the context of use (e.g. the user’s situation, mindset, etc.), user flows focus on how that user actually progresses through the design to complete tasks.

Starting with objectives and the common points of entry, you can map out how a user achieves their goals. For example, a user flow for an user looking to buy toasters will likely differ depending on how they enter the site:

Direct Traffic:

  1. Enters through direct URL.
  2. Types “toasters” in the top search bar.
  3. Scrolls through results until finding “Cuisinart 2-Slice Toaster” and clicks on it.
  4. Clicks on “Add to Cart.”

Organic Search Visitor:

  • Searches for reviews of different toasters
  • Enters
  • Uses search bar to find a listing of toasters
  • Clicks on “Cuisinart 2-Slice Toaster” to read review.
  • Returns to search listing
  • Clicks on “Hamilton Beach 2-Slice Toaster” to read review.
  • Returns to the Cuisinart product page
  • Buys Cuisinart toaster.

We’ve greatly simplified the comparative online shopping experience here, but you start to see how just the point of entry defines great differences in user behavior. To account for that, you must invest in creating a thorough user flow.


User flows help you improve the efficiency of your design. As you plan out the steps within a user path, you begin to understand how to resolve points of friction. They help you visualize your prototype without needing to jump into a design tool just yet.

Best practices

User flows revolve around objectives: both the users and your own.

User flows can be as detailed or simplistic as you want. Try a shorthand technique (shown below) to make things easier.

UXPin ebook — design process
UXPin ebook — design process

You can also try the writing-first approach, which Jessica Downey writes about in her article Jumpstarting Your App Conception Without Sketching UI. This outlining method helps flesh out ideas and build a “common understanding” of each page of your app or site.

Let’s create one for, say, a banking app. The scenario: someone wants to turn on auto deposit. Note in the outline below, content in [brackets] represents action buttons/links.

Step 1: Would you like to set up auto deposit?

[Set auto-deposit]

Step 2: Select Deposit Frequency

[Once per month][Twice per month]

[Every other week][Every week]

Step 3: Deposit Once per Month

[Select calendar day]

Step 4: Set Amount

Display amount field

[Set auto-deposit]

Don’t forget to test your flows. Tree-testing is a good start for this — it tests a preset information architecture to determine if users can clearly navigate your product.

While sitemaps and user flows are related, the two are not interchangeable. As Dan Brown explains in Communicating Design, the differentiating factor is user behavior: site maps represent your content structure, while user flows show different ways of navigating through it to accomplish various tasks.

Sitemaps live up to their name — they are the maps on which the user flows are plotted.


The point of a sitemap is to improve a product’s information architecture.

A site’s IA should be as logical and self-evident as possible The larger the site, the more you need to create a sitemap so you can contain the complexity as much as possible.

The purpose of sitemaps — UXPin ebook
The purpose of sitemaps — UXPin ebook

Best practices

Traditionally, sitemaps are static. You want to show every single layer of the site (down to each subpage) with clear labels. The homepage sits near the top with the main navigation clearly illustrated. Every site is different, so there is no “magic number” of pages to include — that being said, always simplify when possible.

But because clients and stakeholders often question how people might progress through the site, we’ve found that clickable sitemaps are actually more helpful.

The clickable sitemap can either supplement or replace the static site map entirely. Either way, you won’t be doing any extra work since the clickable sitemap is essentially the “shell” of a low-fidelity prototype. Here’s a quick process we found helpful when using UXPin:

  • First create the primary navigation
  • For each item in the primary navigation, create a new page
  • On each page, draw boxes to represent all the clickable links. It’s best to arrange them in a visual hierarchy that makes sense.
  • For each link (like “Programs and Events” or “Advocacy Efforts” in the above screenshot), create a shell page.

Once you’re done, you’ve created a rough outline for multiple user flows. As design agency Barrel shows in this video tutorial, clickable sitemaps are fast ways to help others understand how the design might work.

Of course, don’t leave the users out of the process. Before you start sitemapping statically or interactively, make sure you conduct some card sorting. These simple test allows users to show you how they naturally categorize information so that your IA takes the path of least resistance.

In the same vein as sketches, paper prototypes allow for quick validation and iteration. Paper prototyping has been around since long before digital products even existed, but their practicality makes them still useful today, though with some modern tweaks.

Paper prototyping — UXPin ebook
Paper prototyping — UXPin ebook


Paper prototyping allows designers to test and/or share ideas without creating digital systems that might be scrapped later. Cheap to make and quick to create, paper prototypes are time-savers — it’s easier to throw out a prototype that took 15 minutes than one that took 5 hours.

Paper prototypes can also be a good team-building activity. The crafts aspect can be as fun as it is useful, especially if conducted as a group. Moreover, paper prototypes fulfill the role of actual documentation well — past prototypes can be readily examined and annotated.

Paper prototypes are most applicable in the early stages of design. Their main drawbacks are their visual limitations: they’re able to communicate basic ideas, but they certainly cannot accurately represent the product experience. With a paper prototype, the most helpful feedback will be on design efficiency — how clear and easy was it for users to accomplish their tasks? For later stages, more advanced prototypes are more helpful.

Of course, design is rarely a linear process. Even if you already have a hi-fi prototype, it’s not uncommon to test a new idea with a paper prototype before incorporate it digitally.

Best practices

Remember that, like sketches, simplicity is the main appeal. Don’t get too involved in the details of the images or the mechanics of mimicking an interface.

… But don’t make it too simple. Sketch out each page individually on different sheets of papers to make switching between them easier. When your prototype is ready, find a partner to act as the “human computer” who will operate the prototype. Walk them through the functionality, and remind them to not give suggestions or hints to users when you test the prototype.

Paper prototypes are great for “over-the-shoulder” sessions with stakeholders, but they might confuse people in a formal review. If you present a paper prototype, provide plenty of context by explaining which areas still need to be built, and the specific areas for which you’d like feedback.

Last, you don’t need to build it from scratch. Sites like Sneakpeekit provide downloadable templates to get started. Sheets of paper with images of iPhones or iPads, along with extras like grids and notes, help keep everything organized.

In the past, wireframes acted as a bare-bones structure for content. They were traditionally static, with no interactivity or use beyond the basics. Some designers even treated them as specs documents, annotating details in the margins.

Unfortunately, static wireframes are dead-end deliverables since you need to completely rebuild your prototype.

Wireframe — UXPin ebook
Wireframe — UXPin ebook

However, as with the other documents, technology has enabled wireframing to evolve into something more useful. Today’s wire-frame allows for interactivity. This makes it less of a wireframe, and more a low-fidelity prototype.


Interactive wireframes still retain their original purpose of solidifying the information architecture. Some designers may think wireframes are a waste of time, but we think that’s a bit extreme.

Interactive wireframes allow you to simultaneously test a site’s content structure and page flow (the two most important ingredients of any design). They force you to focus on the foundation without being worried about the interior design.

Adding interactivity to these outlines makes them even more advantageous. For one, this permits early usability testing, which helps facilitate Lean and Agile UX processes. You always want to test your designs as early and often as possible.

Furthermore, these lo-fi prototypes are quick and easy to make. This means that, during the early stages, designers can build and test multiple versions and keep the one that performs best. This is a great aid in rapid prototyping, which we’ll explain below.

Additionally, interactive wireframes save time on building the wireframe itself. The interactivity speaks volumes about how a product’s functionality works, saving you time spent annotating.

Best practices

Build your interactive wireframe with a prototyping tool that allows you to integrate it into later, more advanced designs.

Tools like UXPin allow designers to build on top of the initial wire-frames instead of recreating them. Interactive wireframes evolve into higher fidelity prototypes, thus the work put into them is not lost. The documentation becomes the design, not just supplementary material.

With these advantages in mind, we can see how interactive wire-frames are the natural offspring of the growing Lean UX and Agile UX methodologies, both of which favor less deliverables and more user-informed iteration.

Use common elements — Interactive wireframes only need to be “good enough”. Don’t worry about unique visual design. The goal is to illustrate your ideas and flows as quickly as possible. Use element libraries as much as possible.

Embrace mobile-first design — As recommended in the Guide to Interactive Wireframing, start with the smallest device first and then scale up. The alternative approach of “progressive degradation” makes mobile design an afterthought rather than a priority. To help facilitate the process, our app comes pre-loaded with multiple breakpoints.

Focus on light interactivity — Interactive wireframes only need to be clickable. Leave the fancy animations for hi-fi prototyping. For now, just make sure you’ve linked all the important design elements to their respective pages. Focus on navigation Items, calls to action, popup windows or modals, and alert or dialogue boxes.

Mockups are a visual document that showcases what the product will look like. They are static documents for fine-tuning the visual design.

Image for post
Image for post


While wireframes focus on structure and prototypes focus on flow, mockups focus on fidelity.

Mockups act as visual specifications for developers The earlier the developer critiques the mockup, the better, so that designers don’t waste time on plans that simply can’t be done.

Best practices

As explained in The Designer’s Guide to Collaborating With Developers, make sure you create mockups as collaborative docu.

  • Use proper naming conventions — Use a clear organization system and straightforward names for folders, files, layers, icons, etc. Using a version control system, too, will keep things tidy and come in handy if you need to backtrack.
  • Use a grid system — Grids maintain structure, enable pixel-perfect designs, and prevent needless tweaking.
  • Keep backup typefaces in mind — Since typography is a large part of mockups and visuals in general, keep an eye-out for web-safe backups in case your first choice is rejected by developers.
  • Responsive design is mandatory — Design separate mockups for different screen sizes to make everything crystal clear. We suggest a new mockup for every breakpoint.

Most designers prefer to use specialized graphic software, especially Photoshop and Sketch. Each other these programs, though, have their own best practices. Read the Guide to Mockups for best practices for both.

Whether you use Photoshop or Sketch, you’ll still be able to import your mockup into UXPin for prototyping. As we said when discussing wireframes, the best documentation evolves with the process instead of being thrown away like a deliverable. We allow drag-and-drop prototyping from PS and Sketch, so your mockups don’t become another dead-end document.

The next best thing to final product itself, high-fidelity prototypes are the ultimate design document. As documents you can interact with, hi-fi prototypes (along with interactive wireframes, which are really just lo-fi prototypes) do more than just document, they allow testing and analysis on a level like no others.

Ian Schoen even proposes having prototypes of varying fidelity replace all documentation. While we don’t think it’s as simple as that, the prototype certainly excels at being “living documentation”.

Instead of revising spec documents to keep up with the design, a prototype represents the latest iteration.


Hi-fi prototypes are the most refined collaborative design tool. Developers understand the language of interactions so they can provide accurate feedback on the feasibility of the entire system. Non-design stakeholders can also play with your design as if it’s

a final product.

While a hi-fi prototype might require more design work, you end up saving time in development. Developers can misinterpret specs documents, but they’re less likely to misunderstand if they can interact with a realistic representation.

The learnings from testing hi-fi prototypes are incredibly valuable. If you find critical errors, you’ve just saved a ton of headaches (and money) versus fixing them in code. If you find the prototype performs well, the whole team now has a better vision of what the final product should look like.

Best practices

When building your prototype, keep usability testing in mind. That means, among other things, filling in as many gaps as possible to bring the prototype as close to the finished product as possible. Apply the same user-focused design thinking — targeting personas, interdepartmental collaboration, etc. — to your prototype for the best results.

1. Avoid using placeholders such as lorem ipsum text or unrelated images — While lorem ipsum text can be acceptable for interactive wireframes, try to use as realistic content as possible. Rough is fine, but fake is not. If you are absolutely unable to use the final content for whatever reason, the next best choice is related content — such as text from an older version or competitor’s product.

2. Avoid using celebrity names, jokes, or even Xs in place of contact data — These are distracting and, like lorem ipsum, will destroy the immersion. The more your user has to think about external factors, the less accurate the testing results.

3. Simplify the steps — Fewer clicks mean less friction, which means better user flow. But don’t let the 3-click myth restrict your design decisions. You could theoretically create a site with all of its pages accessible in one click from the site’s front page, but that would increase the cognitive strain due to all the information sifting. Instead, make each step feel as effortless as possible.

4. Don’t skimp on animations — If you’re using UXPin, try the custom animations editor to create interactions step-by-step without any code. When you can test your animations in a prototype, you prevent developers from sinking time in jQuery or Javascript only to discover feasibility or usability issues.

5. Know when to stop — Because hi-fi prototypes are so advanced, it’s easy to get so caught up in the details that you forget it’s not the final product. Remember that prototypes are just a means to an end, not the end itself. Even the highest fidelity prototype will probably only represent 75–80% of the final product.

Coding debate

There is debate among the designers about whether or not it’s worth it to using coding in prototypes. This technique takes “living documentation” a step further, and blurs the line between prototype and product.

Their thinking is logical: prototyping in code reveals definitively what you can and cannot do in the final product, which saves you time backtracking in the end, and hastens the iteration process. Ash Maurya even takes this to the next level by building mock-ups in code. Designers who use code early on are of the school of thought that any documentation not in code will ultimately just be thrown away, so not prototyping in code is a waste.

However, there are several counterpoints. First, a lot of designers don’t understand code, or have a limited knowledge of it. Designing in code inhibits their creativity, preventing ideas that developers would know how to bring to life even if they do not.

Second, coding this early impedes rapid prototyping — the coding makes multiple prototypes take longer and require more work, and in the end creates more waste when some designs are proven ineffective by testing.

Image for post
Image for post

The conclusion we come to is this: don’t code unless you’re extremely proficient technically. Some designers can speak both languages, but coding is usually the responsibility of the developers. The beauty of collaboration is combining the strengths of each member of the team to mitigate the weaknesses.

Unless the designer is well-versed in code, having them think in this language will just restrict their design thinking.


Each of the above documents offers a unique perspective not just for the design process, but for the designer as well. Different designers with different strategies and ways of thinking will find some documents more helpful than others. They feed on certain strengths, but come with their own drawbacks. With the exception of wireframing and prototyping, not all are necessary for every project.

Before you even think about which documentation to use and which to skip, the most important step is knowing your team’s personal design process.

Sign up for uxpin
Sign up for uxpin

Written by

The design tool for teams and professionals. From UI design and prototyping to collaboration and handoff. Speed it up with UXPin. •

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store