User Stories and Role Modeling

Accurately and broadly describing the user community and their immediate needs is a great way to get the first iteration of web based project started. I'm back to the early stages of a potentially large project. I say potentially cause its a start-up and you never know where these things go until its gained some traction by capturing some peoples imagination and traffic begins to build. I've been building interactive web applications since the late 90's and this is cumulatively what I believe are the essential ingredients to get started and why.

User Stories
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.
References:
http://www.google.com/search?q=storytelling+knowledge+agile
http://en.wikipedia.org/wiki/User_story
http://www.agilemodeling.com/artifacts/userStory.htm
http://www.agilemodeling.com/artifacts/userStory.htm#Detailing

User Roles
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.
References:
http://www.foruse.com/articles/rolespersonas.pdf
http://technologyforcommunities.com/2010/07/tech-steward-meet-tech-mentor/

Wireframes

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.
Why wireframes?
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.
References:
http://en.wikipedia.org/wiki/Website_wireframe
http://www.google.ca/search?tbm=isch&hl=en&source=hp&biw=1440&bih=663&q=wireframe+examples 

Lots of discussion

Discussing the user stories, roles and wireframes greatly increases the likelihood of creating a shared understanding of the features and the application as a whole. As far as I know the 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.

Suggested Reading

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.