Monday, April 01, 2013
When do screenshots become a documentation worst practice?
It is common for modern computer documentation to be filled with screenshots, demonstrating how to use every field and control of every window provided by an application. This leads to thick documents with little long term useful information...
There is a significant cost related to keeping documents in sync with the software they describe. If the documentation is being developed at the same time that the software is being developed, it is possible that screen layouts will be changed at the last minute, requiring last-minute changes to the documentation. When a new version of the application becomes available, a whole new set of screenshots must be generated and inserted into the document. This leads developers to avoid improving screen layouts or adding valuable features due to the cost of updating the documentation.
In many enterprises, there are review processes for pretty much everything that gets created, including documentation. Whenever we go down the path of focusing on screenshots, we get drawn into a trap of then also worrying about whether we are using the right icons or other aesthetic considerations while ignoring substance.
Does someone truly benefit over the long haul in having documentation that shows a First Name field should be populated with a first name? I have observed that if user interfaces require documentation then it tends to point to a lack of focus on usability while developing the application. What if we decided to do the exact opposite and find ways to make documentation history?
Should screens for enterprise applications be self-documenting? Many screens tend to mirror the needs of the data to be captured vs focusing on what is the outcome the user wants to accomplish. Think for a moment about your most favored enterprise time tracking application. Does having a box of rows and columns where the user has no freakin clue as to what to put where feel like a request for documenting screenshots or does it feel more like an opportunity to do things differently?
An outcome focused timetracking application would have a totally different interaction. Consider the scenario where a team of people are assigned to a long-term project and for the most part do the same activities on a weekly basis. Imagine a timetracking application that upon signin knew who you were and started with a simple question of: Did you do the same activities this week as last? and simply copied them using whatever logic is appropriate...
| | View blog reactionsThere is a significant cost related to keeping documents in sync with the software they describe. If the documentation is being developed at the same time that the software is being developed, it is possible that screen layouts will be changed at the last minute, requiring last-minute changes to the documentation. When a new version of the application becomes available, a whole new set of screenshots must be generated and inserted into the document. This leads developers to avoid improving screen layouts or adding valuable features due to the cost of updating the documentation.
In many enterprises, there are review processes for pretty much everything that gets created, including documentation. Whenever we go down the path of focusing on screenshots, we get drawn into a trap of then also worrying about whether we are using the right icons or other aesthetic considerations while ignoring substance.
Does someone truly benefit over the long haul in having documentation that shows a First Name field should be populated with a first name? I have observed that if user interfaces require documentation then it tends to point to a lack of focus on usability while developing the application. What if we decided to do the exact opposite and find ways to make documentation history?
Should screens for enterprise applications be self-documenting? Many screens tend to mirror the needs of the data to be captured vs focusing on what is the outcome the user wants to accomplish. Think for a moment about your most favored enterprise time tracking application. Does having a box of rows and columns where the user has no freakin clue as to what to put where feel like a request for documenting screenshots or does it feel more like an opportunity to do things differently?
An outcome focused timetracking application would have a totally different interaction. Consider the scenario where a team of people are assigned to a long-term project and for the most part do the same activities on a weekly basis. Imagine a timetracking application that upon signin knew who you were and started with a simple question of: Did you do the same activities this week as last? and simply copied them using whatever logic is appropriate...
