photo credit: Sinaasappeljuice

At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.

We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.

We move onto user stories, all of which are written from the point of view of the personas:

As Accounting, Myrna needs to quickly extract time expended per project so she can calculate the actual costs.

Our user stories state both the user’s need (what) and business benefit (why) from meeting that need. The story is no longer some randomly floating idea; it’s now anchored to an identified user and given context within the scope of the business by specifically stating how the user and/or company can benefit from this feature.

From here we move onto acceptance criteria (how), i.e., defining how the user expects the feature to work. Since they’re written from the point of view of the user, they’re easy to understand and aid in experiencing the feature before it’s built:

Given that Myrna has clicked on Reports > Costing Report
   And that the costing report page has successfully displayed
When Myrna selects one or more projects
   And she specifies a date range
   And submits the request
Then the costing report will show the hours by project for each resource for the specified date range

Even without delving into the details (e.g., how does the user select one or more projects), you still have a pretty good idea of how someone will interact with this feature; i.e., you’ve established a foundation that interaction designers and information architects can now build on. Acceptance criteria, btw, are also great at uncovering any user story you might have missed, such as: does Myrna need to save this report after it’s generated?

Designing software with a user centric point of view begins with defining the Who (Personas), What (User Stories : User Needs), Why (User Stories : Business Benefits) and How (Acceptance Criteria) of feature stories. With this knowledge, we can then create a well-designed feature that we’re confident will meet the users’ needs.

Share/Bookmark