Re: Task model => User Interface ... Through task (esential use) cases?
- Object oriented designers describe a process where they might read a
narrative describing a business process circling nouns and
underlining verbs. Nouns become objects, verbs services the object
offers. The process described below "feels" similar to that for me.
In practice when I look at the essential use case I'm looking for
things on the screen: containers that hold information and actions
that need to be buttons, links, or gestures. And, in practice I
really do write essntial use case large on whiteboards or poster
paper. This makes it easy to stick post-its on the EUC marking
containers and actions. I can then easily transfer those post-its to
another sheet of paper and arrange them in a way that best supports
the workflow expressed in the essential use case. I do this
stuff "in the large" collaborating with others. Never design alone
if you can help it. It's kinda like pair programming - without the
Of course the devil is in the details. An interaction context often
supports multiple tasks - so you'd need to do this process a few
times and merge results into one visual context. Just as circling
nouns and underlining verbs trivializes the skills of a good OO
designer, this technique suggests UI design is a simple task of
mapping. There's more to it than that. But this technique is a good
starting point. Try it, you'll get useful results.
--- In email@example.com, "aacockburn" <acockburn@a...>
> Jeff Patton contributed a section on essential interaction design
> the book "Crystal Clear: A Human-Powered Methodology for Smalltechnique
> Teams." In that there are few paragraphs on this subject:
> ----- begin extract -----
> Deriving the UI
> When it comes time to develop the UI prototype, consider a
> described by Constantine, Windl, Noble, and Lockwoodand
> [http://www.foruse.com/articles/canonical.htm%5d, which I [Jeff] also
> practice and have slightly modified to suit my personal style.
> Do the following for each user task, on poster sheets:
> * Write in two columns a synopsis of the dialog between the user
> the system. Put the User Intentions in the left column and theareas
> corresponding System Responsibilities in the right. This is what
> Constantine calls an 'essential use-case.'
> * Place sticky notes next to the user intentions and system
> responsibilities that will be UI elements. Put those for input
> and user actions on the left side and those for informationsuggests
> containers on the right side.
> For example, a user intention such as 'user identifies self'
> two input areas and one action (name, password, some sort of "GO"frame"
> button). Write "username" and "password" on two sticky notes.
> Write "action" on a third, or just use one with a different size or
> color to indicate its presence. Stick all three next to the
> phrase "user identifies self."
> For a phrase such as 'system displays open orders,' you want a
> component showing a list of orders. Write "list of orders" on a
> sticky note and put it next to the phrase 'system displays open
> When you're done, the use case should be spotted with sticky
> * Transfer the sticky notes to another flip chart, representing
> screens the user will see, placing them in areas that seem
> appropriate for the user interface of the system. When you're
> comfortable with the placement, replace each sticky note with a
> simple line drawing of the component drawn approximately the size
> you'd expect the component to appear on the user interface. Do
> this with each component. You now have what is called a "wire-
> drawing of the user interface.case.
> Test the wire-frame user interface by referring back to the use
> One participant plays a user role performing the task, the other
> plays the role of the system. Make sure the user interface you've
> designed supports easy performance of the task.
> ----- end extract -----
Alistair wrote in a past message that you have documented some real examples
about this process
"Jeff Patton" <jpatton@...> escribi� en el mensaje
--- In firstname.lastname@example.org, "Agust�n
> Hi!as "essetial
> Conantine & Loockwood proposes that tasks must be described
> use cases". Well... when I try to apply this format of use cases, Iwas
> quickly involved in an endless loop of refining the redaction ofthis use
> cases... Thinking about it, I realized that he problem is that Ireally
> don't have a good understanding about when an esential use case isgood
> enough to begin the user interface design based on itThe essential use-case is a handy variation of a conventional use
case. The two column format limits the use case to a discussion
between a single user and the system - ideal for considering the
user's interaction with the system. The column headings "user
intention" and "system responsibility" suggest thinking about what
the user intends to do with the software rather than specific UI
solutions to the problem. But, moving from the abstract nature of an
essential use case to UI design is an act of design. The essential
use case indicates what the user intends to do - it's up to you to
determine what user interface might best help the user accomplish
their goals - and the system accomplish its responsibilities.
The EUC is only a small part of the picture though. The EUC
describes, abstractly, the interactions. The use case is executed by
a user role with a specific goal and operating from a specific
context of use. Information about that role helps.
The EUC describes interactions for a user task. I've found
clustering tasks by affinity [in a task model] helpful for finding
interaction contexts. Task performed by like people at similar
points in time cluster close together. This usually suggests a place
in the UI where several tasks might be performed. Knowing the
interaction contexts lets you think about navigation from context to
Constantine & other's approach using canonical components
[http://foruse.com/articles/abstract.htm%5d helps to bridge the gap
between a the EUC and a paper prototype. Paper protyping [I like
Carolyn Synder's book on the subject] is critical for validating a
proposed user interface. Try using the essential use case as a
script for validating the UI.
If I had a point in all this rambling it would be that the essential
use case doesn't stand alone. You need all the models from usage
centered design to help, along with lots of other techniques worth
borrowing from other UCD approaches. The Cooper people talk
about "jumping the spark gap." Basically crossing from the essential
use case and all the other models you prepare to an appropriate user
interface is a jump - like a spark crossing a spark gap in a spark
plug. You need a concise useful set of models expressing your
understanding of the user, their goals, context of use and tasks to
help close that gap - make the jumping easier.
Have you combined the essential use case with some of these other
techniques? If you're interested in working through a specific
situation, consider posting an essential use case here. I and the
group might likely be able to ask you questions to fill in the
context needed to suggest appropriate user interface.
Thanks for your post,
> Well, is the "esential use cases" the only way to map tasks toUI
>Yahoo! Groups Links
> Any advice?
- Hi Larry!
The problem that I faced when trying to apply U-CD (in the Larry way) is
that Is really dificult to know when the esential use case is "ready".
Thnking "a la" Test Driven Development: what tests the essential use case
should pass to be considered "ok"?
Of course, there is no simple algorithmic test, but here is how I view it.
An essential use case is "ready" when four things are true.
(1) It is expressed at an approprate level of abstraction. It is abstract
and generalized but still specific to the particular task case and the
application being designed. In other words, it is not "unsuitably vague."
("Expressing needs" as a user intention is unsuitably vague; "specifying
kinds of entertainment is of interest" is not.)
(2) It is technology- and implementation-independent. It has been purged of
all technological or implementation terms and of all references, explicit or
implicit, to specific solutions. This includes hidden assumptions in such
technology-oriented words as "list" (implies a list of items). Seemingly
innocent common words like "search" often carry implied baggage. (A user may
intend to "find" or "get" or "identify" something, but "search" is a
specific technology solution, not a user intention. The moment you use the
word, it becomes all but impossible not to visualize a search box with a
(3) It is expressed in terms of ordinary user language and the defined
vocabulary of the subject matter or application domain. Elements of the
subject matter or application domain are correctly and consistently
(4) It is complete, enabling the user to perform the overall intention it
represents. We verify completeness by walking through the task case, asking
whether the user could complete the task assuming a user interface that
supplied the necessary features and a system that carried out its
With regards to the last criterion, completeness may refer only to the
"happy case" or also to exceptions and alternatives, depending on resources
and level of formality of the process. If it is a small application being
designed under agile conditions, extensions may be allowed to emerge as
needed rather than being elaborated and validated explicitly at the outset.
--Larry Constantine, IDSA [mailto:lconstantine@...]
Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com
> -----Original Message-----Through task (esential use)
> From: news [mailto:news@...] On Behalf Of Agustín Villena
> Sent: Thursday, 24 February 2005 1:58 PM
> To: email@example.com
> Subject: [agile-usability] Re: Re: Task model => User Interface ...
> Hi Larry!
> The problem that I faced when trying to apply U-CD (in the Larry way) is
> that Is really dificult to know when the esential use case is "ready".
> Thnking "a la" Test Driven Development: what tests the essential use case
> should pass to be considered "ok"?