Posted
Comments None

It irks me when people reference the Agile Manifesto. It doesn't say anything. It's all kittens. It's as if agilistas protest in the streets in support of kittens. Everyone at home watches on the news, nods, and agrees: I like kittens! You like kittens! We all like kittens! KITTENS ARE THE BEST!!!

This rhetorical strategy positions pro-kitten citizens as "good" and anyone who disagrees as "bad". What kind of cold, callous asshole doesn't like kittens? The pro- versus anti-kitten battle distracts us from the real discussion:

  1. Do we want kittens?
  2. Do we need kittens?
  3. Is there anything better than kittens?
  4. Are kittens a good idea right now?
  5. Will any old pet do?

To illustrate this point, I've translated the kittens out of the Agile Manifesto, so we can focus on the real issues at stake:

Manifesto + KittensManifesto - Kittens
Individuals and interactions over processes and toolsReal people doing work over models of people doing work
Working software over comprehensive documentationReal software over models of software
Customer collaboration over contract negotiationReal collaboration over models of collaboration
Responding to change over following a planReal learning over models of learning

When we remove the kittens from the Agile Manifesto, we reveal the conflict between "the real" and "models of the real". We reveal the primary tension between development and design, between disciplines of making and disciplines of modeling. We also reveal the developer's underlying assumption: development is more real than design. But we also reveal the real conversation:

  1. When do we want the real thing instead of a model?
  2. When do we need the real thing instead of a model?
  3. When is the real thing more advantageous than a model?
  4. What are we making? What is the real thing?

These are real questions we can answer for each of our organizations, for each of our projects, for each of the elements of design, and for each iteration. Instead of always assuming the "real" thing is what we want and need, we can evaluate what we're trying to accomplish and whether or not a model would do just as well.

Author

Posted
Comments None

There’s a dangerous, anti-deliverable meme lurking about that damages good teams.

First, it removes the need for engineers and managers to think critically about what problems they need to address, and what methods they should use to address them. Second, it suggests user experience professionals are not as capable as other professionals on the team to make decisions about what work needs to be done, at what fidelity, and with whom.

That irks me. It’s a quick fix more useful for lazy teams than for lean start-ups.

I’ve put together a collection of deliverables on Flickr that help identify, clarify, or evaluate important problems and opportunities facing organizations. These deliverables were good. They took time. And they’re demonstrative of how “deliverables” add value to the organization ,help create better products, and help improve how teams think.

Deliverables are not the problem. User experience practitioners are not in the deliverables business. We’re in the business of finding and evaluating problems and solutions.

Author

Posted
Comments None

I’ve used EightShapes’s brilliant Unify deliverable system for about four years. It’s excellent.

Out of the box, Unify is designed for use with Adobe InDesign. Lately, however, I’ve been site mapping in sweet, luscious OmniGraffle, and I created a Unify-inspired OmniGraffle stencil for making site maps.

But, there’s one problem with lots of site maps.

In your typical site map, you show the page’s title adjacent to the little box for that page. Unfortunately, clients and developers and designers don’t always what kind of page the page will be. In other words, if you have a page titled, “Orders”, it’s not clear if that’s a dashboard, a list of orders, or even a form form for adding an order.

Site map example

So I added a line for every page on the site map where you can offer a very brief description of the page.

If you’d like, feel free to download and use the site map stencil.

File NameVersionPlatformSizeDownload
Site Architecture.gstencil0.6OmniGraffle138kbDownload

And if you have any ideas for making it better, please comment below, or —better yet—email me: austin.govella@gmail.com.

Author

Posted
Comments None

Great presentation about how strategy is about convincing yourself you know enough to to act and test your strategy. That's what design is.

(The Medecci Group's Frans Johansson at the 99% conference.)

Author

Posted
Comments None

Li Ming Hsing's design for a crosswalk sign illustrates the gulf between concepts and execution.

The designer explores two important concepts. First is the idea of communicating states and their duration. Not very sexy, but critical. The second, capturing, or recycling, waiting time.

I enjoy the solutions the designers used to explore the two core concepts. But if you threw this design into the "sweatbox", I'd have no problem imagining the client killing design for being too whimsical for a crosswalk. However, the two core concepts are still really good. Making sure you anchor discussions on the goals and the concepts you are using to fulfill them will help ensure good concepts aren't thrown out just because the execution isn't approved.

Author

← Older Newer →