Using Essential Use Cases to design a UI-centric Application

Question

I'm begging a new project (oh, how I love the fresh taste of a new project!) and we are just starting to design it. In short: The application is a UI that will enable users to model an execution flow (a Visio like drag & drop interface). So our greatest concern is usability and features that will help the users model fast and clearly the execution flow.

Our established methodology makes extensive use of Use Cases in order to create a harmonious view of the application between the programmers and users. This is a business concern, really: I'd prefer to use an Agile Method with User Stories rather than User Cases, but we need to define a clear scope to sell the product to our clients.

However, Use Cases have a number of flaws, most of which are related to the fact that they include technical details, like UI, etc, as can be seem here. But, since we can't use User Stories and a fully interactive design, I've decided that we compromise: I will be using Essential Use Cases in order to hide those details.

Now I have another problem: it's essential (no pun intended) to have a clear description of UI interaction, so, how should I document it? In other words, how do I specify a application through the use of Essential Use Cases where the UI interaction is vital to it?

I can see some alternatives:

• Abandon the use of Use Cases since they don't correctly represent the problem
• Do not include interface descriptions in the use case, but create another documentation (Story Boards) and link then to the Essential Use Cases
• Include UI interaction description to the Essential Use Cases, since they are part of the business rules in the perspective of the users and the application itself

Answer 1

Getting user feedback with UI prototypes is essential to creating a user interface that your user community will understand and be productive with. The best way to do this IMO is with paper prototyping. Your use cases can drive the initial creation of these prototypes, and the user interaction sessions with your clients can refine the UI design.

If you prefer electronic prototypes, you can use something like PowerPoint to rapidly prototype them.

See also http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html and http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html

Answer 2

First gather information about the users' workflow and goals. This is best done by physically going to see how the users are doing their work today (for example using contextual inquiry). Document those goals as goal-based use cases (see the link below), which contain only the goal - they should not contain any details of how the system will be used, because those details are what we are just starting to design based on the use cases.

Based on the use cases, create a quick paper prototype of the UI, and try step-by-step that how the users would reach their goals using the prototyped system. If the use cases can not be executed well enough with the UI prototype, keep on improving it until all use cases are supported. Show the prototype to the users and use usability testing and other techniques to find out problems with the UI.

When the UI design is good enough (~85% ready - some fine details are best tweaked after implementation), you can document it for example by taking picture sequences of the prototype, which show how the use cases can be executed with the system. But communicating the UI design to the programmers is best done face-to-face, by showing manually how the prototype works and answering their questions. Don't just "throw the documentation over a wall", but follow through to see how it is implemented and test whether the implementation matches what was designed.

See the longer process description at http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf