This window is the real meat of the application, the detail window of an individual course material. This is what gets made into adoption sausage.


There are numerous toggles on this primary tab alone, and working in a vacuum I might have pushed a lot of this functionality off to other tabs, detail response windows, or fly outs. However, in the legacy application the Title Detail tab was actually two separate tabs and this data was split between them. The mashing of them together into a single tab viewable all at once was the result of my previous experience in support watching users attempt to cull information from the original window. When questioned about item attributes during troubleshooting, they would nearly always open this window and click back and forth between the two tabs several times before answering the question. It was clear that in their mind these tabs and their contents were indistinguishable with no clear mental delineation between them.

In this case I had previous experience with users interacting with just this app. That was pure luck and one cannot rely on luck in software development or any other business. This is why one of my preferred methods for gathering user requirements and business rules is shadowing users in their daily routine, it gives just this type of insight. This kind of observation is especially useful for users that don’t really know what they want, only that they want something better. They can’t articulate what it is they dislike about their current implementation or activity system, but an engaged but unobtrusive technical writer can learn much from simply watching for these types of frustrations.