Archive of Interaction design Articles

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.

Implementation continues on nexus, and we’ve re-factored the way that items in a bundle are ordered, as mentioned in our earlier post. We talk a little about affordance, and show a couple screen shots.

The last step in our agile software development project was documenting our understanding of our users. In this article, we will define the personas that we will use to guide our design and requirement development. This definition of personas is built by combining our experiences in consulting, product and program management, and business analysis.

A couple other good articles on how to create personas:

• Leisa at disambiguity on the merits of creating personas.
• Practical persona creation at evolt.org.

In this article we define our primary, secondary, and supplemental user personas.

Continuing the articles in our agile project case study.

The next step in our agile requirements management process is to develop an understanding of our target users. We believe a user-centric design approach is important. The user interface should conform to the way our users think about what they are doing and trying to accomplish. We should minimize the amount that we force our users to think like our software, and maximize the amount that we should force our software to work the way people want it to.

In this article we document some of the thoughts around who are target users are, and how we think about finding patterns in the way that they would approach using our product. This is a micro-example of market definition / segmentation. We’re looking for patterns that provide interesting commonalities. We’ll use this as a foundation for developing personas.

Its easy for us to overdo almost anything. Kim Goodwin offers some good advice about how not to overdo it when using personas as part of our software development process.

Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users - a targeted communication for our stakeholders.

There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question - how do we gather implicit requirement?

Michael Shrivathsan just wrote an article presenting five tips for creating products with great design.
Michael’s List

Start with the user interface. [Roger Cauvin adds, start with a working first iteration]
Work closely with UI designers.
Pay attention to details.
Simpler is better.
Be brave.

Our Thoughts
User centric design is the core of UX and interaction design. It is the most [...]