Boxes And Arrows : The Design Behind the Design

I think there is a rich area for research, theorising and guidelines here. In my experience, very very few users/customers will bother to report an error or inadequacy with doc, compared to the many who would report an error or inadequacy with the software. In many cases, I think that’s because most users don’t bother reading the doc. And that raises the question of why we bother to write doc for software users?

Has much been written about how doc impacts software usability? What type of doc helps people use a software product? When is it better to focus on a user interface that is self explanatory, and when do you have to accept that the UI will be so complex that it needs to be augmented with doc? Is the primary role of doc to teach people how to use the UI, or as a reference guide to fill in gaps for people who already know how to use the software?

On another angle, has much been written about the usability on online doc?

—Matt.

Hi Matthew,

Thanks for the request and the thoughts.

The last question you raised in the first para is lingering in my mind from quite some time now. Moreover, you are right in saying that usability of technical docs is not explored as of yet.

Hope to write this story and have your inputs on it.

Cheers,

Manoj Potdar

I would be interested in seeing how documentation can grow beyond just being a separate document that’s often disjointed from the application itself.

More specifically, I’d like to know how things like Darwin Information Typing Architecture (DITA) can help us UX designers more tightly integrate “help” into the UI—beyond the “Help” menu item. Any thoughts on how to develop a “help” architecture are much appreciated.

Hi Todd,

Thanks for your inputs.

While exploring DITA principles to integrate Help better is a great idea, I could not understand your views, when you considered User Documents as ‘disjointed’. If you can explain it, I would be in a better situation to handle it.

Regards,

Manoj Potdar