Little Springs Design. 2001 – 2010.

I love stuff like this article in which Jared Spool divides up design into five styles. Analyzing, codifying and labeling is just totally my thing.

For the record, the styles of design are:

1. Unintended — I'd also call this "not designing." Some people I know at Sprint call a lot of the results "PUI," for programmer UI. Sure, sometimes it can turn out okay, at which time I call it "accidental design."
2. Self — This is popular today, and I already ranted about why it's a bad idea.
3. Genius — This relies on good designers. While the article mentions they rely on their vast experience, this is actually all too often just relying on their innate design sense, without consulting historical knowledge.
4. Activity-focused — Like use-case analysis. How do you expect the product to be used. Best if there is research, but really you can get a long ways with heuristics and similar products.
5. User-focused — Personas and so forth. Again, best with research, but you can get pretty far with heuristics and so on. I think this works well with activity-focused design as well. Hard to do it alone, I think.

That is, I liked this post until I got to the end:

we found that the most effective teams were skilled in all five styles, choosing the style that best fit the needs and goals of a project

This worries me. Not everyone and everything can be the right approach just because it exists or feels good.

I am a pretty good designer – traditionally I guess of the "Genius" type as above. I'll plop down in a meeting with clients, and usually in the meeting will come up with a sketch which will work great if implemented directly. Usually. I can hit about 95% reliability with this. I do miss. And the more detailed it gets, the lower my reliability gets. When you get down to things like what order items should be in a table, it gets down towards random chance levels.

Most others I have worked with are not capable of this, or have lower success rates when doing design off the cuff. Even people I'd call good designers, or who are good artists, so no offense if you are reading this. When you toss the design in front of users, they fail, or have higher churn, or lower satisfaction.

Processes and procedures and methods are a good thing. I noticed these statistics and specifically started working on developing my own some years ago. Some year here or other I'll probably even publish it. But anyway, it worked. I improved my own designs in measurable ways, and was able to offload important design tasks to others. The whole department improved its speed, reliability and satisfaction of clients and end users.

The key procedure factor here is that you always use the best process (of the 5-stages above) you can. Just because you cannot do research doesn't mean you don't skip the more rigorously-centered processes. And time is never an argument; I have worked for folks who insisted a good UCD process took 6 months. Maybe. But a decent one can be finished in a few weeks, and it's entirely possible to follow the general principles in a long afternoon.

And always recognize that there is bad design, misdirected process and simple mistakes. Believe in AAR's. If possible conduct ongoing benchmarking research. Make statistics of them all. Seek to analyze and improve your work, and your team's work and process.

This entry was posted on Friday, January 23rd, 2009 at 11:36 am and is filed under Design, Theory. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.