- avoid wasting time writing help no one ever has a need to read
- avoid “documenting features” for the sake of it
- link help to the points at which users actually need it
- develop context-specific help that users actually use — and appreciate.
A process for developing user-centric helpTo create user-centric help, you need to get your writer (or the person who’ll be creating your self-help content) involved early in the UX design process, before user testing begins. They’ll be able to help identify potential sticking points in interactions, and provide verbiage that effectively provides users with doorways to help — calls to action, if you will. Depending on your app, that text could take the form of:
- error messages
- tour content
Common objectionsLet’s wrap up with a few of the most common objections I hear to this approach to self-help.
But where will our product documentation be?If you want product documentation, make it. Just don’t call it user help, or make it users’ first port of call on your self-help site.
But how will users get an overview of the whole process?There are definitely cases where users will want an overview of a process, as in the example I mentioned above. But it’s important to know where to draw the line. In the example above, a user who receives Java errors may stop doing what they’re doing, ignore the in-app help link, and go to the support site to search for something like “Java error.” Of course, you don’t want to only offer self-help content that assumes they’re in the middle of a specific procedure within your app. You want to give them a solution that will work outside of very specific use-cases, too, and in this instance, that required a step-by-step how-to. What we didn’t do, though, was document every error the user may or may not receive from our app. Again, providing useful self-help is about knowing where to draw the line.
But how will we tell everyone about these great features?This isn’t what your self-help site is for. There’s no point documenting the nuances of every element of your new feature just for the sake of your ego. Instead, document what needs to be documented as user-centric information that can be delivered in appropriate parcels as and when it’s needed. And save the hype for your marketing communications.
Frequently Asked Questions on UX Design Documentation
What are the key elements to include in UX design documentation?
UX design documentation should include several key elements to ensure it is comprehensive and useful. Firstly, it should include a project overview, outlining the project’s goals, target audience, and key stakeholders. Secondly, it should include user personas, which are fictional representations of your target users. Thirdly, it should include user flows, which are visual representations of the user’s journey through your product. Fourthly, it should include wireframes, which are low-fidelity representations of your product’s layout. Lastly, it should include prototypes, which are interactive mockups of your product.
How can I make my UX design documentation more user-friendly?
To make your UX design documentation more user-friendly, consider using visual elements such as diagrams, flowcharts, and screenshots. These can help to break up large blocks of text and make the information more digestible. Additionally, use clear, concise language and avoid jargon where possible. It’s also helpful to include a table of contents at the beginning of the document to help users navigate the information.
What tools can I use to create UX design documentation?
There are many tools available to help you create UX design documentation. These include wireframing and prototyping tools like Sketch, Figma, and Adobe XD, as well as documentation tools like Confluence and Google Docs. Additionally, tools like Miro can be used for creating user flows and journey maps.
How often should UX design documentation be updated?
UX design documentation should be updated regularly to reflect changes in the product, user feedback, and new insights from user research. This ensures that the documentation remains relevant and useful for all stakeholders.
How can I ensure my UX design documentation is effective?
To ensure your UX design documentation is effective, it’s important to involve all relevant stakeholders in the process. This includes not only designers and developers, but also product managers, marketers, and even users. By involving all stakeholders, you can ensure that the documentation meets everyone’s needs and expectations.
What is the role of UX design documentation in the design process?
UX design documentation plays a crucial role in the design process. It serves as a reference point for all stakeholders, helping to ensure everyone is on the same page about the product’s design and functionality. It also helps to facilitate communication and collaboration between different teams and departments.
How detailed should UX design documentation be?
The level of detail in UX design documentation can vary depending on the project and the audience. However, it’s generally best to include as much detail as possible to ensure all stakeholders have a clear understanding of the product’s design and functionality.
Can UX design documentation help with user testing?
Yes, UX design documentation can be a valuable tool in user testing. It can help to identify potential issues and areas for improvement, and it can also serve as a reference point for testers.
How can I make my UX design documentation more engaging?
To make your UX design documentation more engaging, consider using storytelling techniques. This could involve presenting the information in a narrative format, using case studies or examples, or incorporating visuals and interactive elements.
What are some common mistakes to avoid when creating UX design documentation?
Some common mistakes to avoid when creating UX design documentation include neglecting to involve all stakeholders in the process, failing to update the documentation regularly, and using jargon or overly technical language. It’s also important to avoid making the documentation too lengthy or complex, as this can make it difficult for users to understand and use.