It’s great to see someone write this up. It’s an approach that we made part of our process at Roundbox Global a few years back and continues to serve the team.

Benefits that we saw included:

• Demolish the wall between Design and Development — no more “us” and “them” with its related miscommunications
• Increased teamwork — everyone interested in making the whole team succeed
• Pair designing — make sure the designs will implement cleanly before documenting, developers point to how we can push the tech to meet design needs
• Reciprocal invitation — involve developers in requirements discussions with the client, especially where technical limits are tight

Through this the team enabled itself to move more quickly before changes in requirements and provide software that met the needs of client stakeholders and end users.

I dig the clear hierarchy of the columns and the clean visual quality but I have my questions about how well this approach would play for the majority of Facebook users. (I have a certain affection for MacOS Finder’s column view but I recognize that many people don’t care for it.)

This is one of those interfaces that I’d love to see tested with end users. Interestingly, Facebook is one of those sites (like Amazon) with a large enough user base that an interface like this could get a small scale A-B rollout and remote feedback without causing disruption for the majority of users. Keep the sample small enough and the test might not appear as an article on Mashable until you’ve done a couple rounds.

What do you think of this design approach?

How would your Facebook friends react to it?

Growing documents

Brown begins by suggesting that designers start documents with a basic nucleus of necessary information then adding detail in layers. He also put forward the idea that ideal documentation should be able to give a bird’s eye view and address the road-level details that developers and quality analysts need.

It seems to me that multiple documents become the best approach to meeting this ideal of providing the bird’s eye view and road level detail. In past work I’ve tended to use site maps or high level flow diagrams to give the high level information then use wireframes or lo-fi prototypes to get into the road level detail. (There is also need for technical documentation of both bird’s eye and road level detail but these tend to fall to the Front End and Back End team leads.)

Concept models

A concept model shows the relationships between the important elements of a web site and provides some initial planning outputs so we can work out what the key elements and key moving pieces are.

The key thing is that it doesn’t box you into a specific approach of how to show the information. You’re not locked into pages or actors. You have the flexibility to represent a specific page or a specific person, but there aren’t rigid rules driving the diagram… the idea is to give the big picture as something to start with. As you move forward documenting it serves as a jumping point to move from into more detailed things like flow diagrams and wireframes.

The concept model paints the relationships between things… it’s a learning tool.

Building this deliverable pushes you to learn about how all the concepts fit together and the resulting deliverable serves as a point of reference for you and teaching tool for communicating the relationships between the concepts to others.

Looking over a current project that’s late in the requirements gathering stages it appears to me that starting from a concept map may have helped to better communicate our understanding of the system with the client and provide easier access to some of the high level information they wanted to share with the higher ups without getting mired in the details.

Flowcharts

While these are possibly the least appreciated documents among designers, flowcharts [or flow diagrams] tend to rate very highly with the stakeholders and team members that consume them. As designers we sometimes see them as unnecessary because we often have the “big picture” that the flowchart communicates in the back of our heads. Other stakeholders don’t tend to have that information at the back of their minds and appreciate the easy communication that flowcharts provide.

This is a wholely unsexy form of documenting, but people understand them and that makes them useful.

Spool cited experiences he’s had with flowcharts and raised the question

How do you determine what level of detail to focus on?

If you get too focused on the details it takes forever, if you go too high the flow isn’t clear.

In my work I tend to put together different flowchart style diagrams for different situations, often a high level flow (more of a site map or application flow diagram) and as needed assembling more specific process flow diagrams that provide more detail.

Brown’s comment on designers neglecting this form of diagramming is well taken, in that when I feel time pressure low level process flows are typically the first thing I drop from my process, occasionally to my regret. Perhaps the clarity of communication that flowcharts provide is part of why we neglect it. We look and say “well, duh” and wonder why we took the time, forgetting the power these diagrams have to quickly communicate the flow to other members of the team and to our customers.

Documents as people

You don’t want to give people too many responsibilities. You shouldn’t assign too many responsibilities to a document either. Like a person they’ve got their limits of what they can deliver.

Establish a purpose for the document. What am I trying to accomplish? What is this document’s role in the design process?

If you have a purpose for the document you can make sure that everything about that document serves the purpose. You can become ruthless in decision making.

I see the ruthless editing this enables as the take-away. Mercilessly slash the cruft that doesn’t serve the doc’s purpose from your deliverables. Is the level of detail I’m using here accomplishing the objective? No? Readjust.

Having a clear purpose can be more difficult the more stakeholders there are working with the document. As different opinions fly about what a document’s purpose is the opportunity to ruthlessly slash closes up.

It’s possible for the responsibilities of a document to change over the life cycle. As you reach different points in the project the purpose of a document may change.

I’ve seen changes over the lifecycle take multiple forms. In some cases I’ve seen document formats change to address a shift in responsibility, such as wiki delivered annotated wireframes getting additional technical annotations from the Front End team. In others the documents themselves have remained unchanged but they’ve been put to different purposes than those they originally served. I’ve seen such changes most frequently in how site maps and high level application flow diagrams have been used by the team and customers over the lifecycle.

User testing your documents

This was an especially interesting question Spool brought up in the interview. We test the software that results from the documents to make sure it meets user needs, are we also testing the documents to make sure they meet user needs?

Brown suggests showing customers past documentation as a sample to get their reaction to it and see if the content and presentation works for them. In a sense it’s like doing a competitive evaluation. Here’s this sample, get reactions to it and adapt.

Iterative process is another option, taking the documentation to the customer, take comments on format and further improve to match customer needs. (This would hold true as well for internal documentation, something we’ve done from time to time with our developers and quality analysts.)

I’ve tended more toward the second option than the first, and done most testing iterations on internal documentation where the cost of entry has typically been very low. Asking questions about document format doesn’t tend to make internal folks nervous where some customers take questions about document format as a sign you’re making things up as you go. I think Brown’s suggestion of how to approach user testing the docs with customers by using old documents does a good job of addressing this potential gotcha.

Books and intervening experience

The interview rounds up with Brown talking about how his thoughts on some of the various deliverables have changed. Some items he considered optional when writing the book are necessary (such as annotations on wireframes) and some things he thought essential he’d now skip over.

As the responsibilities of the various documents he wrote about have shifted, the best practices have shifted as well, making the samples in the book a starting point from which to adapt rather than a template to simply adopt. As always, the designer must take the inputs and decide how to adjust to meet the users’ needs.

He and his nonprofit Gapminder have done some cool things with visualization to bring out aspects of the data that get ignored, but as he notes, we haven’t got the holy grail yet. Looking through the Gapminder site, it looks like all the visualizations are hardwired to a specific dataset. This pairing of presentation to specific data provides punch to items like their Dollar Street 2003 Shockwave presentation, which includes home walkthrus comparing lifestyle across the world’s economic ranges. (Very cool.) But it leaves me on my own if I want to apply the kind of graphing methods he presents to a dataset that Gapminder isn’t taking on.

It seems to me the next natural step with more general visualization tools like those in Rosling’s TED presentation (even more than searchability) is to develop a visualization system that lets analysts and decision makers apply the same sort of visualizations over their own data, or better, over multiple datasets from multiple sources, providing the same plotting, subset exploding, curve overlays, and multi-axis visualization. Move from delivering the individual visualizations to providing the tools to create the visualizations.

Some very cool stuff they’ve done already though. Shows the power of visuals to convey a message.

Content + microformats = crazy delicious

It’s easy to find developers and markup standardistas lauding microformats as the next great thing, and as a currently-implementable stepping stone to the semantic web. That being the case, I’ll say that the possibilities microformats provide for easing data export, streamlining content updating, and easing data collection burdens for users are wonderful.

Deferring dreams

I only see one cloud trying to darken microformats’ day… browser support.

Despite how cheaply (in the 37signals sense) developers familiar with hCard can encode contact info, I’ve found it difficult to recommend to many customers that they make significant use microformats on their web sites due to the low payoff compared to the cost.

Microformats are wonderful (remember the crazy delicious comment?), but for a number of customers, this technology shoots wide of their target audiences. Personally, I get stoked when I see Tails’ microformat icon appear in my status bar. But the Tails icon is a great representation of the problem: I’m getting excited over a Firefox extension’s behavior, not a regular browser behavior.

I’m an outlier.

Most of the folks using my recent customers’ sites haven’t heard of microformats, and forget about Tails or any other Firefox extensions. Most of them know Firefox as “that browser that’s trying to take on IE.” The more tech savvy among them will have heard that Bill Gates said something about “we need microformats,” but won’t necessarily know what that means. (To be honest, since that’s all I’ve seen from Microsoft about microformats, I’m not entirely sure what it means myself. Can we look forward to microformat support in future versions if IE, are we doomed to another “embrace and extend,” or is it just talk?)

Despite my love for them, I don’t believe microformats will influence the experiences of “ordinary” users (many of our customers’ customers) until microformat detection and data export are built into IE and cleanly import into Outlook and similar applications. (I want to see the same functions built into Firefox, Safari, Opera, Konqueror, and all their related browsers and all the various email clients, but until “alternative” browser use ceases to be alternative, it’s all about getting Microsoft to adopt.)

A less oft quoted part of Gates’ proclamation on microformats is that we need “to get people to agree on them.” My read: Until we have agreement on microformats, browser makers won’t be able to read them out of the box, so don’t expect us to deliver this innovation to the masses anytime soon.

hOpe

Fortunately, I think much of the work on standardizing microformats has been done. A number of microformats are established and well documented. Developers are using these documented formats on their sites, and enterprising companies are providing microformat based searching. Google’s Usage Rights feature and Yahoo’s Creative Commons search checks rel-license links for specific flavors of Creative Commons licenses, and Technorati provides a microformat search covering contacts, events, and reviews marked with the relevant (hCard, hCalendar, hReview) microformats.

But even with Google and Technorati showing what cool things are possible with microformats, we will have to drive adoption.

Delivering the dream

If the web’s awash in well formed, standards compliant microformat content, the browser makers won’t be able to ignore it, and they won’t be able to claim that the target’s moving too much to justify the development costs to support microformats.

What about the client problem, you ask?

We have a pretty good sense which clients won’t really gain anything from microformats. We have a similarly solid sense of which clients would benefit and would be interested in what microformats can do for them given the proper introduction.

We also know how to make microformat adoption as cheap as possible on our end. The lower the cost for entry, the easier it will be to sell clients on it or just include it as a value add.

And, just a guess, I’m thinking that most of us have one site or another that’s ours to command, maybe even a few family and friends’ sites that are ripe for a quick implementation.

Old time religionin’

And there’s always spreading the word with those we work and play around. Share the gospel of microformat goodness. As people see how microformats will help them kick ass, ((In wonderful Kathy Sierra “help your users kick ass” ways)) they’ll start looking for microformat support. Just ask Derek and Will, once you’ve got an audience on your side, you’re golden. The more people that see what the web could be, the more there will be pushing for it to happen.

As the excuses fall away and user demand mounts, it will be too expensive for browser makers not to support microformats. And we’ll have successfully taken over the world.

At first I wondered if this was for real or if someone thought they’d channel their web 2.0 energy into a “2.0 for Jesus” satire.

Initial reactions aside, this makes a lot of sense for religious folk… a space where you can develop a community of prayer, sharing things you’re praying for with friends, getting to know friends of friends through praying for them and trading comments. (It wouldn’t hurt the more self serving goal of just keeping your prayer requests straight either.)

What I see as the big unknown quantity is whether people will be shy about sharing the things they’re praying for with the community at large. It provides ways to do so, and ways to limit prayer items to a specific list of friends. My initial guess would be that people will keep their sharing pretty tight, but then, I wouldn’t have guessed that I’d be so free as I am about sharing bookmarks through del.icio.us or ma.gnolia, or photos on flickr, so what do I know?

Or more to my mind… how can we most effectively introduce these technologies to users who don’t know what an RSS is, so they can reap the benefits of these great new tools?

I live by my feed reader and my favorite blogs’ feeds, but I doubt that most of my non-designer friends make use of the tools that the more “web 2.0 savvy” use daily. We see amazing possibilities with these new technologies, but how will we present those possibilities to users? Will our presentation help users see how these new tools get them what they want, or will we trip over our excitement over the next big thing?

If you tell me why RSS is great, I’ll think it’s cool, but if you show me how much faster I can get at posts on my favorite blogs and share my own posts (or del.icio.us bookmarks or last.fm charts) with my friends, I’ll love you forever… and actually use this cool new thing.

Until recently, jarango had separate English and Spanish language sections, ceding to the impracticality of writing in one language or the other then translating the content so everyone can see it. In planning out plainasm (the precursor to the current blog), I flirted with the idea of the same approach, until I realized how little IA work I do in Spanish and how little benefit potential readers would get out of the occasional post I might write in my adoptive tongue. (This has changed over the past year as I’ve become involved in the IA community in Costa Rica, hence the current blog’s English and Spanish editions.)

Honestly, I’m sad to see the Spanish section of the site go into archive mode, but I think Arango did the right thing. One’s best hopes for providing content in multiple languages can end up holding back content in either language.

On memes

• Memes are essentially ideas or portions of an idea that catch hold and travel from person to person.
• A proper meme is self sustaining. That is, people pass memes to one another because they find the meme or the conditions under which they encounter it so interesting that they can’t leave it alone.
• Memes live is an ecology of ideas where the interesting survive and are passed on, at times despite social pressures to the contrary.
• Memes that propogate by obligation will survive only so long as social pressures press people to propogate the meme, after which they will be hunted down with extreme, derisive prejudice.

A little experiment

And here’s my little unscientific experiment. I’m going to place a modified version of last spring’s Music baton meme on the ground here and see if…

• the meme succeeds in passing itself on (without the social pressures that come with people specifying who they’re passing it to)
• the meme proceeds beyond my own direct social network into the great out there (from which I’ll need people to kindly trackback so I can see its progress)
• social pressures against another run of the music baton smash this version of the meme (hate that music baton meme… just hate it!)

Music baton plain pick-it-up meme

Total volume of music on my computer
12.39 Gig

Last CD I bought
Get9 (import), Yoko Kanno

Song playing right now
“Clouds,” Cibo Matto

Five songs I listen to a lot, or that mean a lot to me

• “I Want to Break Free,” Queen
• “Fortunate Son,” Credence Clearwater Revival
• “Noel: Christmas Eve, 1913,” John Denver & the Muppets
• “Solsbury Hill,” Peter Gabriel
• “Super Powers,” Ookla the Mok

I picked up this meme from

[link or trackback the blog/person you got it from to help track where the meme's gone]

This weekend’s Buffy entry really drove the problem home. That is, the fifty times I’ve looked over my little 2 page essay and realized that it boils down to “I like Buffy because it’s about self-denial for the good of others and about fixing your mistakes.” Sure, that’s simplifying. I’m leaving out all the bits that point out that there’s more to the show than what I’m pointing out, but once I was finished hedging, did you really care what I was saying anymore?

I like to tell clients how important it is to tailor your tone to your audience, let’s do the same here. Time to go conversational.

You may also notice from today’s earlier post, I’ll be indulging in the occasional “lookie there” post, since there just isn’t time to write my own comments on all the cool things going on out there.