Ellen Beldner

Jon Kolko, who I met at CMU, just published his book Thoughts on Interaction Design. I'm a guest author and wrote a chapter called "Getting Design Done".

The book's website is http://www.thoughtsoninteraction.com/.

http://www.nytimes.com/2007/03/25/business/yourmoney/25Proto.html?_r=1&oref=slogin

Summary: Let advanced users hack on your products. They will come up with innovations that you didn't think of.

This stands up nicely to an economic interpretation too: If someone is willing to take the time to hack around and build something that wasn't part of the spec, that means that they're willing to spend capital to have that functionality. Which means it's some sort of market opportunity.

Enterprise software can often be maddening like this: companies sell their software for $200k + and they want to be gatekeepers and prevent customers from getting into the code -- they want to preserve the mystique or something. But often they just end up being roadblocks to customer happiness. Like, I bet if we could have hacked on Oracle Calendar rather than having to build our own totally separate version, we'd be vastly more advanced than either system ends up being. Good, complex software takes time (a lot of time) and figuring out how to build on the accumulated knowledge of others (represented in code)

Unfortunately, the article puts this technique in opposition to "traditional" anthropological design processes -- which often aren't well-integrated anyway. There's absolutely no reason why you can't derive benefit from both techniques.

The other day we launched the Google Base Store Connector.

The progression to the final version was pretty neat. When I started working on the project there was a functional demo that had already been built, wizard-style. I came up with a few user scenarios that led to functions like storing account information so users can easily update their items in one click. That is, if someone has an Ebay store and they want to get listed on Google, it'll be better for them if they can store account information so all they have to do is periodically click something to say "okay, update my items" rather than having to re-enter account information each time.

(Yes, there would be faster and more humane ways to do this that don't involve an intermediary application, but those are outside of technical scope.)

The engineers and PMs on the project did an awesome job getting the details right. For example, based on the store you select (eBay versus Amazon, for example) the textual labels change next to the input fields. We used the language from each of the source sites: Amazon uses the terminology "sign in" with your "email address" instead of something like "log in" with your "username" or "user id". Yahoo! has a "Yahoo! ID". This keeps it just a little bit more familar for users. They probably couldn't tell you if Yahoo! calls it an "id", a "user id", or your "yahoo signin", but seeing the same verbiage will trigger subconscious memory and feel a little more "right". Cognitive priming, anyone?

So: a very small piece of software, but reviews on Ebay's forums generally commented on how simple it was to use. Yay! We wouldn't have gotten there without a comittment to good technology from the PMs and engineers. Good user experience is only partly UI design; a lot has to do with the engineering behind the interface.

When it comes to discussions about writing software specs, I really like to quote Sen-Rikyu, the master of the modern Japanese tea ceremony: "Tea is naught but this. First you make the water boil. Then infuse the tea. Then you drink it properly. That is all you need to know." But if you know anything about the actual practice of the tea ceremony, there is -- for laypeople who have not mastered the Zen of simply boiling the water and infusing the tea -- an immensely complex protocool, replete with symbolism that must be adhered to.

Writing specs is simple. All you do is document what has been decided and capture known uncertainties, and underlie everything with a giant disclaimer that until the code is written you won't know exactly how it's going to work.

In fact, perhaps we shouldn't think of specs as specifications of software. They are specifications of goals for the software.

I'm about to start working on a UI spec for some upcoming changes to the Google Base UI. I'm always looking to improve, and this is a pretty complex series of workflows that we have to get just right. So I want to make sure that I capture and communicate all of the decision points that I've traversed up until now, and that I specify behavior that may not be fully obvious in the prototype that I built.

Let me highlight some key concepts from that last paragraph: Capture. Communicate. Spell out corner cases.

So I searched for write UI specs. The first result is 37 signals explaining why specs don't work. I read this type of article -- along with some Agile and XP techniques -- as a radical overreaction to the other extreme (of overplanning and presuming you can actually precisely specify software on a piece of paper before anything is written). In that sense, the 37 signals article is irresponsible. It's speaking to a particular historical context of software engineering without acknowledging that there are a lot of ways that specs can be written, usefully, in the context of more modern software engineering practices. Moreover, when you're not working at a small startup, it is irresponsible to not write specs. Specs help other teams anticipate and plan for what's happening down the line, and when you don't have the same 10 people doing everything -- when you have a marketing department, a customer service team, writers who have to do help documentation -- you need to let them know as early as possible what you think is coming down the pipe, so they have maximum time to plan their own resources and schedules.

Sitting down with my architect this weekend to make decisions about kitchen cabinets, countertops, sink, and how the stairs will work. The kitchen will be monolithic charcoal gray (or maybe white) so it doesn't compete too much with the brick & timber in my loft. Work will start ASAP.

I can't wait to start cooking again. My 14 boxes of kitchen and dinnerware are starting to annoy me, and I want to have dinner parties again.

Pironimo.net is a twiki installation that I deployed, customized, and maintain for a small community of friends (around 30 people). It began on another server in September 2002. Since then I've done about three major UI revs and one software upgrade.

At work we have a bunch of Toto washlets. One day I was explaining to some friends about the wall-attached remote control. One of them, in annoyed puzzlement, asked why on earth would you need a remote-controlled bidet control? This sketch is an exploration of different solutions based on my task analysis.