Field Notes Inside an Integrated Communications Agency

It's Friday, which means I'm debating the usefulness of wireframes again. Wireframes, for the new and uninitiated, are like "stick-figures" of a website. They indicate importance, organization and functionality of a UI but do so in a way that tries not to be too descriptive of the design. There's a certain amount of layout and organization that is implied, but we try to make sure that we don't tie designers' hands too much.

And it doesn't always work.

At capstrat , our designers and developers do some really powerful work. What's more, they get user experience and usability. So as a UX designer here, I'm in a position where steely control over the design isn't always necessary. In many cases, it's not appropriate since it impinges on designers' and developers' abilities to better deliver a product. Wireframes, unfortunately, can be seen as very prescriptive. Using them can minimize the contributions and expertise of people whose experience is essential to the design.

So, where does that leave us? Well, there are alternatives - page description diagrams being one. I won't go into them too deep here (you can read for yourself here), but suffice it to say that I'm underwhelmed with them. Mostly, they seem to be too vague. They're too prone to error and misinterpretation and are uneven on detail. What's more, they lack the basic information to communicate page-level organization and choreography. As a UX designer, I feel that page description diagrams simply abdicate way too much of what is my responsibility.

But wireframes are also good. They set boundaries of expectations to clients and are concrete in a way that prosaic descriptions can't match.

So, is there a middle ground? I think so, and here's an idea I've been banging around. I call it Pidgin.

Pidgineering

Pidgin dialects arise as a common ground between speakers of different languages. They mix terms from both and create a hybrid. I'm extending the analogy to UX deliverables. In this case, I'm interested in finding a common ground between designers, UXDers and developers. The goal is to create a vocabulary that conveys capability and choreography but is less prescriptive of the design. For the impatient, here's what it looks like:

Essentially, Pidgin is based upon three concepts: blocks, relationships and views. Here's the legend:

Blocks

The idea is to identify meaningful blocks of content and function, and show how they relate to one another. What's a block? Well, that's up to you, but essentially it's a distinct piece of function or content that can be usefully separated. A block is somewhere in the middle. So, a textfield probably wouldn't be a block, but a collection of fields and the submission button would be.

Relationships

Blocks relate to each other through relationships, which are...wait for it...lines. With arrows! Arrows describe the relationship; the pointy end shows what the block belongs to. By default, a single arrow means that the block will only occur one time for the other block.

There can be double arrows too. These indicate multiplicity: that a block can occur many times within another. In an article listing, for example, an article block might appear many times.

The lines themselves are either solid or dashed, indicating the block is required or optional respectively. If you want to get all crazy with it, you can use an open ended arrow to indicate multiple states of an object. Personally, I would discourage this except for trivial states of change. You're better off showing the default state and creating a storyboard for the block that shows how it acts in other situations.

Views

Remember when I said that content blocks related to one another? You might be thinking: but to what do they eventually relate? Views. A view is your page. It can inherit from more basic pages if you want, but that's not necessary. For example, you might abstract the global navigation and relate it to a more generic view. This is shown in the diagram above. Overall, though, a view aligns to an entry on your sitemap.

Is there a catch? There's gotta be a catch.

Yes, Virginia and it's something I'm wrestling with. Pidgins aren't testable-at least, not testable in a conventional sense. You could place this in front of a user and ask them to complete a task, but the results wouldn't be valid in the final design. You could get an idea of gaps and missing functionality, but not a whole lot more. You might be able to test each block, but that's really not useful either since it doesn't test the choreography, which is critical. As a tool to engage both development and design, however, pidgins seem useful in the early stages of the design lifecycle.

Thoughts?