Here are the scans of the design elements I drew out the other night as part of the design and requirements exploration for our agile project case study. There are seven images (with larger versions) showing design exploration.
Category Archives: Agile Project: Ratings
APR: UI Platform Research
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.
APR: Mixing It Up With Design And Requirements
With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?
Prototyping.
Posted in Agile, Agile Project: Ratings, Product Management, Requirements, Requirements Models, Requirements gathering, Software development, Software requirements specification, UML Modeling, Use Cases
Tagged agile case study, agile project, agile requirements management, agile software development, Design, managing data, prototyping
4 Comments
APR: Prioritizing Use Cases – Vote Three Times
In our agile project case study we defined corporate goals and user personas, and from our understanding created a list of use case names. We refined those use cases into use case briefs, filtering out some of the use cases (for the first revision) narrowing the list to six use cases. In this article, we propose a prioritization of those use cases and ask you to vote to share your thoughts.
Posted in Agile, Agile Project: Ratings, Business Analysis, Product Management, Requirements, Requirements Models, Software development, Use Cases
Tagged agile case study, agile project, agile requirements management, agile software development, agile use cases, group think, managing data, prioritizing use cases, use case prioritization
2 Comments
APR: Use Case Briefs
Each of the use cases defined as part of our use case names post is described at a high level of detail here. The goal is to get a broad view of the domain for our project so that we can focus on the most important elements. This is a key step in using use cases in an agile project. We need to understand enough of the big picture in order to determine what is actually the most important. Then we will work on the more important use cases.
Posted in Agile, Agile Project: Ratings, Business Analysis, Product Management, Requirements, Requirements Models, Software development, Use Cases
Tagged agile case study, agile project, agile requirements management, agile software development, example use cases, managing data, sample use case examples, sample use cases, use case examples, use case samples
9 Comments
APR: Use Case Names
In our agile programming case study, we have two corporate goals, but one of them (learn Ruby on Rails) only drives constraints, not requirements. The other goal is to make it easier for people to find and read great content in our niche. This makes the documentation of goal-driven use cases pretty straightforward. All of the use cases support this single goal.
With an understanding of the goals, the next step is to define the use case names.
Posted in Agile, Agile Project: Ratings, Business Analysis, Product Management, Requirements, Requirements Models, Software development, Use Cases
Tagged agile case study, agile project, agile requirements management, agile software development, goal-driven use cases, managing data, supporting goals with use cases, use case name examples, use case names
7 Comments
APR: Persona Development
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.
APR: Scope and Vision – Vote On It
In the discussion on our article about understanding users as part of our agile software development case study, Rolf raised an interesting question about the scope and vision of having people rate articles:
I’m wondering what an ‘article’ is. Does it have characteristics? Is it just some piece of knowledge (I’d say: yes), or even just a reference to a piece of knowledge?
Is it important that an article is readily accessible from the site (that would exclude training courses, books, …)? My answer: no, even a hint for a good book or a reputed company would be of help to the personas.
This article has a poll asking for your inputs. Read the rest of the article …
Posted in Agile, Agile Project: Ratings, Prioritization, Product Management, Requirements, Software development
Tagged agile case study, agile project, agile requirements management, agile software development, example requirement prioritization, kano example, managing data, prioritization of requirements, requirements prioritization
4 Comments
APR: Understanding Our Users
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.
Posted in Agile, Agile Project: Ratings, Interaction design, Product Management, Software development, UX
Tagged managing data
9 Comments
APR: Corporate Goals
Corporate Goals for the Product
We have two corporate goals for our agile project. One of them directly drives the features and functionality, and the other one is a driver of a constraint on the implementation approach. Both types of goal are relevant.
A process that relies on structured requirements always starts with goal definition. Even if we are combining principals of interaction design with structured requirements, we still need to understand our corporate goals. It is from this understanding of goals that we can move forward to developing a contextually relevant understanding of our users.
Latest Articles
Comments on all Articles
