Modeling User Experience Scenarios

I’m working on modeling some requirements for a document management system.  I’m a big fan of using models to represent every element, from goals and strategies through to business processes.  From there, I model use cases and requirements and on down to system components that fulfill those requirements.  Just call me a traceability hound.

I find that the effort to develop requirements in this way is, if anything, substantially less than the traditional “text first” method, and I can always output text documents for those times when people need their Word Document.

User Experience Scenarios are not, however, an easy fit with our current modeling languages.  We have models for business processes (which are excellent for illustrating activities in the scope of roles), interaction diagrams (which are excellent for illustrating component lifecycles, timing, and information flow), and activity diagrams (which are excellent for illustrating the activity of a single module).

I am not completely comfortable illustrating a user scenario in any of these three visual languages.   They really capture the wrong information, and fail to illustrate the things I care about.

For a user scenario, I want to know what persona is involved, what motivation that persona has for interacting with my business service, and what information they will have before the scenario starts.  I also want to know what constraints they will expect of the scenario: what is their level of commitment to my business service?  How frequently will they be interacting, and what is their understanding of the underlying information?  While I can annotate one of the UML models above with this information, I cannot truly model this information in the UML diagrams described.

I’m using the following diagramming “language” to describe the connection between people, motivations, scenarios and use cases.  To see this sample full-size diagram, click on it.  The model attempts to show the people involved in creating and using architectural standards. 

Using a UML-derived diagramming language, I can document the scenario (labeled “<<Scenario>>” in the diagram) as a sub-activity diagram.  That activity takes on a sense of reusability, since it can be from the perspective of any involved actor while keeping the actor itself outside the scenario.  This allows a single scenario to apply to different people (Object Oriented Encapsulation, as applied to workflow).

On a different view (a different diagram), I can illustrate each of those scenarios with links to the constraints that I mentioned above (frequency, information objects, level of commitment. etc). 

The advantage of creating a model of this kind is obvious to me, because I’m a modeler.  But for many folks, the benefits may not be clear.  Let’s put it this way: if you change any one object or line, there is the potential for impacting other objects.  With a model of this kind, you can SEE those potential impacts before they happen.  By developing a model, the architect develops clarity of thought, and in doing so, reduces mistakes in the design.

I’m curious if others find this kind of model interesting.

Comments

• Anonymous
  November 10, 2009
  Hi Nick, a nice post again. One remark: The image is not clickable, and I thus can't really see the whole idea. Regards, Robert

• Anonymous
  November 10, 2009
  Clicking the diagram isn't working for me

• Anonymous
  November 11, 2009
  My apologies for the glitch that prevented the image from appearing when clicked.  I've republished the blog post so you can (now) click the image and see it full size.

• Anonymous
  November 23, 2009
  What we can't see in your diagram is how the user motivations and scenarios are joined-up into a coherent multi-person user process. How do the actions of the Team Project Manager affect the experience of the Project Team Implementor? Do you not think it would be useful to have a way of paying attention to this kind of thing? Ultimately, the document management system is being positioned (for this set of users) as a subsystem of some larger system. So we have a lot of interoperability issues that critically affect user experience. Surely this must be relevant to the requirements engineering task?

• Anonymous
  December 02, 2009
  The concept is great. The "stimulus >> action" approach is intuitive. The use of a diagrams help the reader see the context. I assume such diagram would be complimented by a narrative and a legend to help navigate. I use a similar approach and later map scenarios to functional requirements and quality attribute scenarios. This package evolves with architecture design. This approach definitely helps with traceability downstream. Developing these scenarios also helps the author think through the process. Like you mentioned in the post picking a modeling approach and proper notation (or designing your own) is hard and largely depends on the required analysis granularity and the audience.