Famous designer Yves Saint Laurent once said: “Trends come and go, but style is eternal”. Although the quote is exclusively about fashion, I cannot but extrapolate it to the world of user experience.
Fellows – Information Developers, Technical Communicators, Information Experts – lend me your ears.
When designing knowledge bases, creating documentation portals, or documenting complex interrelations, one forgotten requirement may result in multiple very memorable working evenings.
Consider this precious advice from Peter Morville and Louis Rosenfeld and always pay heed to these crucial areas.
In short, we need to understand the business goals behind the web site and the resources available for design and implementation. We need to be aware of the nature and volume of content that exists today and how that might change a year from now. And we must learn about the needs and information-seeking behaviors of our major audiences. Good information architecture design is informed by all three areas.
Explore their book Information Architecture for the World Wide Web Peter for more useful tips!
Warning! I come bearing no answers. Just putting some questions you may find not comfortable facing.
Problem statement: you know all the best practices. But your result is far from being best.
Searching for ways to improve the usability of your documentation? Consider developing a glossary!
Already have one? Look for ways to enhance your glossary in this post.
This question occurs every time an InfoDev embarks upon a new project. Quality requirements actually reflect what the target audience wants you to deliver. Hence, it is vital to determine the relevant quality measures before you start and follow them throughout the document development life cycle.
In my previous post I presented my findings about how one should write content for web, including simple writing optimized for scanning, using the inverted pyramid technique, and more.
Updating the content on my current project’s site, I found the problem pulpitating through the text. Trying to formulate it, I came up with the following questions:
Information developers are professional users of all sorts of technical documentation, and our experiences inevitably range from genuine pleasure to absolute disappointment.
Our trained eye immediately picks out the obvious typos or inconsistencies. But how come that some texts, though technically and grammatically correct, just do not work the way they are intended to? With all the rules and guidelines, we often forget about the most important focus of technical documentation – the user. So, what is this usability factor that makes a document easy to understand and work with?