lanehalley

Tom Scott posts that Dave Thomas proposes an “envisioning” and “definition” phase to be added to the front of the Agile “development”  and “release” cycles. Thomas assumes that developers perform all roles, and there’s still no place for documentation that isn’t code, but this doesn’t seem that far off from what Alan is proposing. There’s even this quote, that sounds rather like Alan’s recent presentation “The Envisioning Team provides a clear definition of what needs to be built; the Definition team designs how to build it.”

Interesting.

There's another post that references Dave Thomas here and opens the larger question about how to do Scrum with larger teams.

"Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?"

The development community hasn't come up with an answer to this problem yet, perhaps the IxD community can step up and help?

Andrew Hinton has an interesting post about Personas and the Role of Design Documentation.

"Whenever orthodoxy seems to be going awry, you can either reject it, or try to understand it in a new light. And one way to do the latter is to look into its history and understand where it came from to begin with—as is the case with so much dogma, there is often a great original idea that, over time, became codified into ritual, losing much of the original context."

Word.

He also has this interesting note about the Charmr from Adaptive Path

"One thing a couple of the presenters said really struck me—they said they found themselves having nightmares that they’d been diagnosed with diabetes, and had to manage these medical devices for the rest of their lives. Just think—immersing yourself in your user’s experience to the point that you start having their dreams."

Also true. In my projects, I often am so deeply involved in the personas that I dream conversations with them.

Just discovered that there's a rose called "About Face."

"A topsy-turvy attention-getter, this bi-color medal-grabber makes your eyeballs salute ‘cause the two colors are outside-in. Or is it inside-out? The lighter lasting golden-orange color is on the inside with a distinct darker bronzy-red outside. Yet it's not just the flying colors that will cause a flap. It's a turning point as a plant, too, with superb vigor, lush clean green leaves and loads of bloom."

Q: In Alan's talks, he sometimes mentions a "design blueprint" What does this mean?

A: A design blueprint is a form and behavior specification that illustrates what every screen looks like and describes the states and behaviors of every control. It also contains the personas, scenarios and a summary of the research used to generate them.

As you might expect, the information is presented in several ways to meet the needs of different audiences: A high-level framework which describes the parts of the interface and their relationships, pictures of individual areas and controls which describe all the parts and their functions in different states and a series of full-screen pictures which illustrate key scenarios. The blueprint also contains a visual style guide that defines the color, typography and visual look of the interface.

Depending on the complexity of the project, the document can be quite large. Because we are consultants, we often transition the document to our clients when construction starts. They then place the information under source control with other project documents. If you're doing this in-house, you could just as easily start the document under source control.

As construction starts, the design team works with the construction team to resolve problems and change the design. The objective is to keep the blueprint up to date with the current design of the product. I've seen clients do this using comments on .pdf versions of the blueprint, or they make document changes in the document source with some sort of version control. As you can guess, this takes time to do, but pays off in clarity, especially when you're working with a distributed team (in the US and India, for example)