{"id":10539,"date":"2015-12-08T20:43:36","date_gmt":"2015-12-09T04:43:36","guid":{"rendered":"http:\/\/proxystudio.uxpin.com\/?p=10539"},"modified":"2024-09-09T19:42:38","modified_gmt":"2024-09-10T02:42:38","slug":"stop-busywork-the-guide-to-strategic-ux-documentation","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/stop-busywork-the-guide-to-strategic-ux-documentation\/","title":{"rendered":"Stop Busywork: The Guide to Strategic UX Documentation"},"content":{"rendered":"

Documentation must be actionable. It must have a purpose beyond creating a paper trail.<\/p>\n

The best design documentation enhances the design process and communicates design thinking to others. If a UX document accomplishes this, it drives the strategy rather than acts as a lagging indicator.<\/p>\n

Design documents should complement, not supplement, the design process.<\/p>\n

In this piece, we\u2019ll explain how to approach UX documentation as a strategic exercise. We’ve included links to some of our favorite resources, as well as described processes that worked well during our own product redesign. <\/p>\n

The 3 Stages of UX Design<\/h2>\n

Despite its creative points, all design boils down to a methodical, almost scientific approach. While everyone\u2019s design procedure varies according to their own personal tastes or constraints, in general the process must cover three essential stages, with plenty of iteration in between. <\/p>\n

\"Diagram<\/p>\n

Photo credit: Rosenfeld Media<\/a><\/p>\n

1. Research & Define \u2014<\/b> Analyze what your users want (\u201cbuild the right product\u201d), then start ideating the appropriate solution. <\/p>\n

2. Design \u2014 <\/b>Create ways to give them what they want (\u201cbuild the product right\u201d).<\/p>\n

3. Usability Testing \u2014<\/b> Confirm your results with users, or discover what you need to change.<\/p>\n

You’ll repeat this cycle multiple times with each iteration bringing the product closer to perfection. While the stages aren’t always one after another, testing should always occur at least twice in your design process (one for the lo-fidelity prototype, one for the hi-fidelity prototype).<\/p>\n

And as for research, ideally you\u2019ll want to know as much as you can before you start, so it should be the first step\u2026but that said, it\u2019s never a bad time to learn more about your users.<\/p>\n

We actually kicked off the UXPin<\/a> redesign process by interviewing 15 UX designers from multiple industries. Once we consolidated the insights, we created a quick UX strategy document to help shape the core product experience. The strategy document serves as a guideline rather than requirements document since we only described the basic design principles. From there, we created and tested a lo-fi prototype, then created and tested a hi-fi prototype. As we entered beta testing, we also interviewed 7 more designers.<\/p>\n

1. User Research<\/h2>\n

Now that we\u2019ve outlined the process, let\u2019s talk about where documentation fits in.<\/p>\n

If you\u2019re creating a document just to have proof that you did something or because that\u2019s the \u201cstandard process,\u201d then you\u2019re wasting your time.<\/p>\n

While the Waterfall Model of design is outdated, there are some lessons we can take from its linear roots.<\/p>\n

First, the research phase is where you make sure you\u2019re going in the right direction instead of blindly sprinting ahead. Being prepared and having a solid plan means you won\u2019t have to backtrack as much later, so a little extra work at the beginning saves you a lot of time and effort at the end. <\/p>\n

This is the point of the design process where you really come to understand your users. Collecting data through user research (interviews, field studies, etc.), mixed with some old-fashioned empathy, will give you a good idea of whom you\u2019re designing for, and what they want.<\/p>\n

\"Screenshot<\/p>\n

Our UX Researcher Ben Kim tests the redesigned UXPin<\/a> with Designer Jessica Tiao of KissMetrics<\/a> <\/i><\/p>\n

Additionally, you\u2019ll want to understand the needs of the stakeholders, just as important as the end-users. You could design the greatest product in the world, but it would never see the light of day unless the stakeholders are satisfied.<\/p>\n

Strategic documentation for this stage<\/h3>\n

The research-stage documentation can be broken up into two sections: collecting the data and what you do with it.<\/p>\n

Collecting the data:<\/h4>\n

i. Stakeholder interviews<\/a><\/b> \u2014 The first thing is understand business needs and technological parameters, and the best way to do this is to ask the sources. Both the questions you ask and the notes you take on the answers will determine how close to the mark your final product hits. Since we’re a startup, our researcher Ben Kim held 30-minute stakeholder interviews with our heads of marketing, product management, UX, and our CEO Marcin Treder. He learned everyone’s preferences, concerns, and goals for the redesign. <\/p>\n

ii. User interviews<\/a><\/b> \u2014 Just like stakeholder interviews, you need to ask the right questions to get the most helpful answers. User interviews prove invaluable for understanding the people you\u2019re designing for, which is the cornerstone of the design process. Other options for collecting initial user data are field studies<\/a> and diary studies<\/a>. <\/p>\n

iii. User surveys<\/a><\/b> \u2014 While not as personal as user interviews, user surveys are easier to orchestrate and can cover more people \u2014 plus they are natural documentation that are easily forwarded to teams. Surveys are great for taking a quantitative approach to qualitative data. You can create these quickly with Google Forms<\/a>, or use SurveyMonkey<\/a> for something more complex. Surveys are especially useful during later-stage beta testing. <\/p>\n

iv. Competitive Audit <\/a><\/b> \u2014 Examine strengths and weaknesses of your competitors using an overlaid heuristics diagram. Evaluate areas such as ease of form completion, clarity of navigation, accessibility, trust factors, etc. <\/p>\n

Showcasing the data: <\/h4>\n

i. User personas<\/a><\/b> \u2014 Once you have adequate data on your users, you can build fictional user personas. These act as stand-ins for the actual user during the design process, focusing more on behaviors rather than demographics. At UXPin, we use lightweight personas informed by user interviews and in-app data. We define the person’s role, daily responsibilities, and motivations. <\/p>\n

ii. User scenarios<\/a><\/b> \u2014 These logic exercises take personas a step further \u2014 they outline how a persona would act in a specific situation, including what pages they visit and why. In the below example created during our redesign process, you can see how we tried to imagine a realistic scenario for a marketer collaborating with a designer in UXPin<\/a>. The thought exercise helps us understand that speed and ease-of-use are the top priorities when commenting on designs. For fast user scenarios, Google spreadsheets works quite well since you can also collaborate with other product team members. <\/p>\n

\"Chart<\/p>\n

iii. Customer journey maps<\/b> \u2014 The ultimate document for understanding your user, journey map out the personas and user scenarios at each step of the experience. User emotions, quality of experience, product weaknesses, and other factors can all be documented. Moreover, they cover customer touchpoints before, during, and after service so so you can gauge the lasting effect of your design. For the sake of speed and collaboration, we created our template in Google spreadsheets (see below example). <\/p>\n

\"Customer<\/p>\n

iv. Product documentation<\/b><\/a> \u2014 While optional in the age of prototyping, documentation like product requirement documents and functional spec documents consolidate market and user research into a unified vision. ProductHunt\u2019s documentation<\/a> is a fantastic example. Meanwhile, style guides<\/a> help ensure consistency and adherence to best practices during the design stage. <\/p>\n

For our redesign, a simple strategy document outlining our design principles worked just fine. <\/p>\n

\"Screenshot <\/p>\n

2. Design<\/h2>\n

As shown in the free guide UX Design Process Best Practices<\/a>, the best design documents are often some form of the physical design itself. They change in both form and complexity as the design process advances, and the types of documents, including their fidelity, vary greatly. <\/p>\n

UX strategy is a fluid exercise, which means your main documentation must be the design itself. Otherwise, you’ll get bogged down in paper trails.<\/p>\n

While there are many advantages to designing quickly and creating a final product as soon as possible, that\u2019s no excuse to cut corners. Some of these documents may feel like extra work, but each of them brings something unique to the design process. <\/p>\n

Strategic documentation for this stage<\/h3>\n

i. Sketches<\/a><\/b> \u2014<\/b> Classic sketches on paper are one of the quickest and easiest ways to get your ideas down and share them with others, especially if you\u2019re brainstorming.<\/p>\n

ii. Site maps<\/a><\/b> \u2014<\/b> Outlines of your information architecture, showing how your pages are connected to one another. <\/p>\n

\"Site<\/p>\n

Photo credit: Interactive site maps created in UXPin<\/a> by design agency <\/i>Barrel<\/i><\/a><\/p>\n

iii. Wireframes<\/a><\/b> \u2014 <\/b>These are the barebone structures of your product; dedicating time to building one allows you to flesh out your sitemap without more complex details distracting you. <\/p>\n

\"A<\/p>\n

iv. User Flows<\/a><\/b> \u2014 Once you\u2019ve done enough user research, you can start outlining how the pages in your design correspond with user actions. User flows are fast shorthand notes that help you improve the efficiency of your design. You can evaluate the amount of friction at each step and minimize steps when possible. You can also try Ryan Singer\u2019s shorthand user flows<\/a>.<\/b><\/p>\n

\"User<\/p>\n

v. Interactive wireframes (lo-fi prototypes)<\/a><\/b> \u2014 <\/b>Adding a little interactivity into your wireframe allows for early product testing. As advised in the free guide UX Design Process Best Practices<\/a>, the earlier you can get feedback, the easier it is to implement. No need for complex interactions (save those for a hi-fi prototype), just make important elements clickable so people can actually use the design. <\/p>\n

\"Screenshot<\/p>\n

vi. Paper prototypes <\/a><\/b>\u2014 <\/b>The most basic form of prototyping to explore the efficiency and usability of your design. Good for brainstorming and inviting feedback from others due to its simple format. Requires a coworker act as the \u201chuman computer\u201d to operate the prototype for usability testing. We don’t prototype on paper as much anymore since our product team just starts within our tool. <\/p>\n

vii. Mockups<\/a><\/b> \u2014 <\/b>These allow you to focus solely on the visual details of your product, creating a hi-fidelity reference for how it should look. We’ll test the lo-fi prototype first, iron out usability issues, then move to visual design in a mockup with tools like Photoshop and Sketch. We can then import the Sketch or Photoshop file right back into UXPin<\/a> to create a hi-fi prototype. <\/p>\n

\"Screenshot<\/p>\n

Hi-fi prototype of our new editor interface. Created by importing a Photoshop file into UXPin. <\/em><\/p>\n

viii. Hi-fi prototypes<\/a><\/b> \u2014 <\/b>The last iterations of your product before the live version. Hi-fi prototypes are ideal for fine-tuning the interaction design and animations. If you use UXPin, the custom animations editor<\/a> lets you map out animated prototypes step-by-step without any code.<\/p>\n

\"image11\"<\/p>\n<\/section>

Grab design ebooks created by best designers<\/h3>

All for free<\/p>