Defining User Assistance Architecture
I have avoided the job title of architect for several decades now, but it has eventually overtaken me. So now I must ask myself what do I do that's different from being a technical communicator? In a classic sense of architecture (as in designing buildings) architecture means defining the structure and form for places that accommodate human activity. OK, that seems like a good starting place. So a User Assistance Architect is someone who defines the structure, organization, and delivery methods for presenting user assistance, i.e., information and instruction that supports user activity within an application.

As an architect, I need to be less concerned with the detail of the content and more concerned with the types of information that content must contain, when to present it, and how to best let the user access it.

So how does one go about doing this? The initial methodology I am using in my current task is based on use cases. Bear in mind that I have been brought into an environment where there are mature products with lots of user assistance in a variety of forms and locations already in existence. My chosen role right now is more of User Assistance Anthropologist, i.e., discovering and cataloging what exists. Even though this puts me more in a deconstruction mode, I think the approach would work equally well in a construction mode, i.e., where a product or product suite were being built from scratch. I say this, because use cases are primarily design tools anyway, and my use of them to analyze an existing product structure is more the exception.

I have chosen a representative product and I am populating a four-column table with:

Use Case * Scenario * Information Requirements * UA Channels/Patterns

I am in the process of reviewing product documentation, interviewing SMEs and writers, and then trying to fit what I am learning into this table. Although the initial purpose is to capture current state, I imagine that the same structure will be useful to define future state as well.

So far the approach is working well for me--it provides a structure to help me start to unpeel the onion in manageable layers. Best of all, it lets me collect information in the random way information likes to emerge but store it in a way that lets structure start to emerge.

I will discuss this methodology in more detail in later blogs.