Category Archives: Interaction design

Interaction design is the key to managing user experience. These articles discuss tradeoffs and provide tips about interaction design.

APR: Understanding Our Users

By Scott Sehlhorst | April 19th, 2007

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.

Read the rest of the article …

Posted in Agile, Agile Project: Ratings, Interaction design, Product Management, Software development, UX | Tagged managing data | 9 Comments

Overdoing Personas

By Scott Sehlhorst | December 14th, 2006

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.

Posted in Interaction design, UX | Tagged driving development with personas, gdd, goal-driven development, managing data, persona, personas | 2 Comments

Actor Hierarchies And Then Some

By Scott Sehlhorst | December 13th, 2006

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.

Posted in Interaction design, Requirements, Requirements Models, Use Cases | Tagged actor hierarchies, actor hierarchy, actor hierarchy model, actor map, actor model, actor table, evolving use cases, ID, managing data, personas, Requirements Models, use cases | 1 Comment

Fifteen Ways to Shut Down

By Scott Sehlhorst | November 23rd, 2006

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?

Posted in Design, Interaction design, Prioritization, Requirements, Software development, Software requirements specification, UX | Tagged featuritis, ID, managing data, shutdown, user experience, vista, windows vista | 10 Comments

Gathering Implicit Requirements

By Scott Sehlhorst | November 17th, 2006

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?

Posted in Interaction design, Product Management, ROI, Requirements, Requirements gathering, UX | Tagged gathering implicit requirements, gathering requirements, ID, implicit requirements, Interaction design, managing data, requirements and design, requirements elicitation, software requirements gathering, ux | 3 Comments

How To Not Suck At Design

By Scott Sehlhorst | November 15th, 2006

topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F11%2F15%2Fhow-to-not-suck-at-design%2F”, “style”: “big”, “title”: “How To Not Suck At Design” }); 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 [...]

Posted in Interaction design, Prioritization, Product Management, Requirements, UX | Tagged Design, featuritis, innovation, killer features, managing data, not suck at design, suck at design | Leave a comment

How To Apply Market Research Better

By Scott Sehlhorst | November 1st, 2006

Mike Mace provides us with some great insight about market research – helping us to avoid ‘the blender’ and ‘the gap’. The gap is a reflection of the inability of most customers to innovate. The blender is the loss of useful market information into a homogenized input that pushes only the lowest common denominator – again stifling innovation. We have to avoid the blender and the gap to get useful data from our research.

Posted in Interaction design, Marketing, Product Management | Tagged blackberry, innovation, managing data, market segmentation, persona, trio | Leave a comment

Use Case Driven Documentation

By Scott Sehlhorst | October 10th, 2006

Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.

Writing Valuable Requirements

By Scott Sehlhorst | May 30th, 2006

One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?

Posted in Interaction design, Product Management, Requirements, UX | Tagged business requirements documentation, good requirements, managing data, product requirements, requirements documentation, software requirements, valuable requirements, writing business requirements, writing requirements | 4 Comments

Requirements Gathering – Interviewing the Right People

By Scott Sehlhorst | May 18th, 2006

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”