The conception, birth, and first steps of an application named Charlie

Subscribe: Atom or RSS

A Clean Sheet of Paper

by Alister Jones (SomeNewKid)

In part two of his four-part article series on Painless Functional Specifications, Joel Spolsky recommends that we engage in a little bit of story telling. We should come up with a few fictional, but realistic, users of our software product, and tell the story of how the users work with our product. To put a slight spin on this suggestion, we might say that the story should describe how the users want to work with our product. Then, we should design the product to get as close as possible to having it work the way our users want it to work.

I am going to tell the story of how three website owners will want to work with Charlie.

The first website owner is named Tom—a no-nonsense name for a no-nonsense guy. All Tom wants is to click a button or two and have a website that is ready to go. He doesn’t want to be worried about templates and colours and other shit. He just wants a website where he can start writing articles about his favourite subject, Carrol Shelby.

The second website owner is named Michelle—an amateur photographer who wants to show her photos to the world. She just wants a website that presents a few albums where each photo can be clicked in order to see the full-sized photo. Standard stuff. But whereas Tom doesn’t care about templates and colours, Michelle does. She wants the background to be black, since most of her photography is black and white. She’d like the title and the photo borders to be mauve, which is her favourite colour.

The third website owner is named Joshua—the owner of a boutique winery. He has paid a lot of money to a graphic design firm to come up with a design for his wine labels, so he wants his website to reflect the same style. His labels display titles in a Garamond typeface, flush right, with the first letter in red and the remaining letters in black. The website should use the same style.

One of the originally-specified features for Charlie was that it would support both custom websites and turnkey websites.

A custom website would come about by Tom, Michelle, or Joshua sending me an email or calling me on the phone and saying, “I hear you’re the second-greatest website designer in the world. Jason Santa Maria is unavailable, so I’d like for you to design my website.” Creating a custom website is relatively easy—it just takes time. It is the turnkey websites that require special attention.

A turnkey website is one where the website-creation process is automated. This would come about by Tom, Michelle, or Joshua visiting a Charlie-based website and clicking on the “create a new website” link. Creating a turnkey website is relatively hard—it requires designing a system with the right tradeoffs between automation and customization. Tom wants it all automated, Michelle wants a little customization, and Joshua needs extensive customization.

In the following weblog entries on creating the user experience, I’ll be looking only at the turnkey experience, since that is the one that requires planning and coding. Any custom website will really just be a single-instance turnkey site with lots of customization. In other words, planning and coding for turnkey websites will lay the foundation for custom websites too.

So, having forgotten that Charlie just happens to use ASP.NET—and thereby starting with a clean sheet of paper—how can the product be designed to provide Tom, Michelle, and Joshua with a pleasant and effective experience in creating their turnkey websites?

by Alister Jones | Next up: Ready, Set, Go!

0 comments

----