I think of a persona as a specific (yet generalized) instance of a role to "personify" and represent what users that play that role, might be like. While we originally argued over the details of the personas, a great by-product was that we focused on the distinctions across our various customer sets. This helped reduce ambiguity during product design. It also helped us make calls on where to put our resources and effort.
One of the best ways I've found to map out a problem space is to create what I call, "Scenario Frames." I call them scenario frames because they are an organizing frame of scenarios. Simply put, they're a set of one-liner stories or scenarios organized by categories. The beauty of a scenario frame is that it can contain macro-level or micro-level scenarios and, because it's a tickler list, it's easy to traverse.
One of the most effective approaches I've found for chunking up a project for incremental value is using a Scenario and Feature Matrix. Scenarios are Your Rows, Features are Your Columns A Scenario and Feature Matrix organizes scenarios and features into a simple view. The scenarios are your rows. The features are your columns. You list your scenarios in order of "MUST", "SHOULD", and "COULD" (or Pri 1, 2, and 3) .. through vNext. You list your features by cross-cutting and vertical. By cross-cutting, I mean that feature applies to multiple scenarios. By vertical, I mean that feature applies to just one scenario. It helps to think of scenarios in this case as goals customers achieve.
A few folks have asked me about Axiomatic design. I figure an example is a good entry point. An associate first walked me through axiomatic design like this. You're designing a faucet where you have one knob for hot and one knob for cold. Why's it a bad design? He said because each knob controls both temperature and flow. He said a better design is one knob for temperature and one knob for flow. This allows for incremental changes in design because the two requirements (temperature and flow) have their independence. He then showed me a nifty matrix on the board that mathematically *proved* good design.
Customer Connected Engineering (CCE) is a practices we use across our patterns & practices teams for engaging customers throughout the life cycle. We involved customers during the planning, development, and release of our deliverables. This is a draft slide set that shares how we do Customer Connected Engineering inside patterns & practices, including our key practices and guiding principles.
12Page 1 of 2