Home » Archive

Articles in the Design Category

Design, Project-Management »

[31 May 2009 | 2 Comments | ]
Scenario Frames

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.

Design, Project-Management »

[31 May 2009 | Comments Off | ]
Scenario and Feature Matrix

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.

Design »

[31 May 2009 | 4 Comments | ]
Axiomatic Design

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.

Design, patterns & practices, Process, Project-Management, Requirements »

[19 May 2009 | 6 Comments | ]
Customer Connected Engineering

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.

Architecture, Design, Requirements »

[2 Mar 2009 | 3 Comments | ]
Agile Architecture Method

The Agile Architecture Method is a way to bake quality into the life cycle. It’s also an iterative and incremental approach for architecture and design. In its simplest form, it’s a way to help you identify potential hot spots against your prioritized scenarios. The hot spots are key engineering decision. The main hot spots are cross-cutting concerns, such as data access, exception management, logging … etc. and quality attributes, such as security, performance, reliability … etc.

Design, patterns & practices, User Experience »

[2 Feb 2009 | Comments Off | ]
Personas at patterns & practices

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.