Use Case or User Scenario

December 13, 2008

I’ve heard both tools referenced a number of times. It seems there is confusion between the two. Here’s my understanding. Please feel free to share common experiences and any further clarification.

User Scenarios

  • Keep the team speaking the language of user needs and connecting design decisions closely in with the implementation process
  • A rich narrative of user interaction with the product that also incorporates persona and environment
  • Meant to show how a typical user (persona or constituency) would use a specific option or action
  • Documents what the user may do before and/or after they interact with product
  • The scenario helps drive the use case … it explains that the user is, for example, typically working on a site or application or blog in a busy office with various distractions, and may have to save progress before publishing and return — and then the use cases would need to reflect that
  • Scenario is a good place to point out motivations, distractions and more
  • Can be a bit broader, move into how a person got to the site /application and why
  • Scenario based approach to design integrates well with Agile’s use of story cards :)

Use Cases

  • A bulleted user – system talk which follows action-response pattern.
  • It does not talk about the user’s demographic profile, technical awareness, and environment or context.
  • Detail every possible option or action on the site – each result and each variable
  • Take user out of the picture to document the system responses to any single action
  • Don’t take personal environmental & habitual context into account.
  • An intermediate step between the context-rich story the scenario provides, and the cold logic of the developer’s code & “business rules” of the application.
  • The people designing the UI, labeling the controls, links and fields, developing the aesthetics and writing content need to know more than just the mechanics of what the user will be doing.
  • Descriptions of system behavior, not user behavior. It doesn’t focus on a particular user or kind of user — it focuses on what situations “of use” the system may encounter and how it should respond
  • Documents every possible feature and how it should work
  • Yes, use cases are flowcharts in words …
  • The distinction becomes really apparent (and problematic) when use cases are expanded from ‘functional specifications’ into ‘real life stories’ to explain things to the lay audience
  • Use case is a conversation between the system and the user
  • A very detailed back and forth of what happens at each click
  • Use cases can be done by a developer as well as the designer and often leads to refinement of test cases and QA plans.
  • Writing use cases can drain creativity of a designer. Reading them can inform the designer

Clive Thompson In Ten Minutes

December 10, 2008

The School of Visual Arts has a new program offering a MFA in Interaction Design. The program markets itself as “training students to research, analyze, prototype, and design concepts in their business, social, and cultural contexts.” Honestly, I am excited for the program and the faculty round up is impressive.

In an effort to continually promote the program and feed the the NYC community there’s a monthly lecture series. November was a focus on sketching and this months topic was “The Interviewer.” There were four speakers given ten minutes to present about interviewing:

  • Gary Hustwit, Director, Helvetica, Objectified
  • Jason Severs, Principal Designer, frog design
  • Clive Thompson, Contributing Writer for New York Times Magazine and columnist for Wired magazine
  • Elisabeth M. De Morentin, Illinois Institute of Technology, Institute of Design

What I found interesting and useful were the ten minutes offered by Clive Thompson. His talk was sharp and, thankfully, on topic. If you’re not familiar with Clive, check out his New York times article ( one million dollar NetFlix prize for solving the recommendation engine’s “Napoleon Dynamite” dilemma ) :

If You Liked This, You’re Sure to Love That

He explained his professional focus is rarely on the specific success of innovators (”that’s not interesting”) but really what took place before the “break through.” He wants to understand what they didn’t know and how they got there.

So he strives to grasp the process and the thoughts through all of the things that didn’t work. He mentioned some terms for further thought like “linear order” and “genius thinking.” It is the “state of absence and failure” that drives Clive’s interviewing and writing.

For me, there’s a great deal going on here that can benefit those of us interested in design thinking and innovation.

In just ten minutes, Clive provided us with valuable insight for improving the process of gathering data during interviews and reminded me to remain intrigued on not the results but the process.

Resonated quite a bit with my fixation with Pixar … I like watching the behind the scenes of their amazing creative process maybe even just as much as experiencing the movie.

First Step’s First. Intentions.

December 3, 2008

I am deciding to take a step and commit to sharing my voice, resources, and experience ‘here’ for consumption. I remain open to where this might lead, how this space will be shaped and take this step with pure intentions for assisting and learning from others on their inspired way.

10 years of producing, managing, designing, coding, driving, teaching, leading, hosting, supporting, consulting, tweaking, streaming and architecting digital solutions – all while advocating standards compliant web practices and naturally prioritizing the experience of the user:

I am committed to shaping this space and applying the very principals that I practice and preach daily for those that might be charged and can benefit from the outlet.

Just what the world needs- another blog, right? Most important – I will continually ask if it is adding value :)

Next Entries →