

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.


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.

In our previous article in the series on the development of nexus, we discussed navigation and information architecture. We identified the challenge of filtering articles by category and by level of experience (beginner / expert), while also viewing the articles along a characteristic (most-viewed, highest-rated, etc). Between both url-creation and visible site-navigation, the challenge we explored was how to present one facet or dimension as primary and others as secondary.
One of our readers presented a third alternative - faceted navigation.

We have an interesting information architecture challenge as part of our agile project. We have talked about browsing and searching articles organized both by category (product management, business analysis, etc) and by level of expertise (beginner, expert). We’re also rating and reviewing the articles, which introduces the ideas of “latest”, “most reviewed”, “highest rated”, etc.
This presents us with a three-dimensional way to approach structuring the information and navigation of the site.

One of the elements of design we need to consider for our agile project is the interface that our users will be using. We need a way to survey our users to get this data. We are using the data from visitors to Tyner Blain as a presumably representative sample of the users of the new ratings site. This user group is defined in our vision document as “people in our niche.”
Most of the articles in this series (and offline conversations) are being used to gain qualitative feedback. We will combine this qualitative understanding with easily gathered quantitative data.
In this article, we look at some of the statistics gathered from just under 30,000 visitors since the first of the year.

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:
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.
Joshua Ledwell wrote a short article expressing his perspective on designing software that is neither too simple nor too complex. He also links to some excellent other articles on the topic.
Learning curves have been studied for decades when evaluating manufacturing systems and proposing cost reductions. The Boston Consulting Group did an oft-cited analysis in the 1960’s that describes how people get faster at tasks through repetition. Peter Abilla looked at the extension of this to writing software. We look at how it applies to using software.
There’s a buzz going around about the conflict and collaboration between product managers and user experience professionals. It started with a pair of articles co-written by Jeff Lash and Chris Baum. In short, with a user-centric view of products, both roles are responsible for the success of the user-interactions. Who makes the decisions?
Jakob Nielsen identifies 8 levels of adoption of usability by corporations. He calls them the stages of corporate usability maturity. There is definitely a continuum of adoption and appreciation for usability in companies today. By understanding the eight levels we can determine how best to increase the commitment to usability on our projects.