Monday, June 20, 2011
User Stories and Role Modeling
Telling stories assist greatly in sharing knowledge and building understanding. Gathering user stories when working within an agile approach to software development is a great tool for focusing on the next build and the features it includes. Scott Ambler does a great job of describing the user story. What I find most important with the user story is the confirmations that also occur when writing the story.
Why user stories?
Humans brains are mapped to understand stories and having a shared understanding among designers, developers and users is really important in getting it right. A big benefit to having a comprehensive set of user stories (with confirmations) is they drive testing.
Understanding the broad range of users at the early stages of designing software is important. Brainstorming the breadth of users is helpful when determining the scope of a project as it often exposes features that are derived or afterthoughts. The idea of the administrative role or the stewardship role are often overlooked when focus is on the first, usually customer focused, release.
Why user roles?
Being able to tell stories from many different perspectives, all within each iteration of new features, creates a focused and working solution within each iteration. Having a broad set of user roles identified keeps the design comprehensive and the features current.
Wireframes takes the design discussion beyond the user stories and roles and puts design to "paper". Wireframes are very basic diagrams detailing the screen elements without the focus being on graphic design and aesthetics of the site. Its focus is on the features, navigation and organization of features.
It allows people to discuss the main features and how they will be implemented and clustered without to large an investment toward the actual interface design. The discussion is more focused on how it will all work and how features are grouped.
Lots of discussion
Vulcan mind meld is only possible when in a star trek episode. So having discussion with users, stakeholders, programmers, designers, architects, etc. is beneficial to the overall success of the project. Determining the right mix of people for these discussions depends on the project and the organization. Always better to have the groups small and focused.
From all my reading on the user story and user role, this is the book to read if you want more detail than is described in this post.