Where the Wireframes Are. (Or Aren’t)
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?
All Articles
@John - I had not seen that before, but Constantine's take is very interesting. The difference, as I see it, is that his focuses on the underlying interaction whereas pidgin focuses on the representation. What's really compelling about his approach is that it would fit in nicely with something like Chiara Fox's content models. It definitely focuses on things that need to be accomplished to make a user happy, without being too prescriptive about how they are done.
So, I think both Canonical Abstractions and Pidgins are serving two different but similar ends. The former seems to focus on the IXD and flow: something that I accomplish with UML activity diagrams. The latter sits at that point where we know the objects and choreography for a page. It's concerned with giving the designer liberty to make it communicate effectively.
Anyhow, thanks for the comment and the insights. I'm always interested in seeing how other people approach these situations.
Hi Todd, have you read Constantine and Lockwood's papr on Canonical Abstract prototypes for interfaces? (http://www.foruse.com/articles/abstractprototypes.htm) This proposes a similar approach to what you have outlined here, although it takes a step back from choosing even the widgets used, specifying only the intent of the designer. So you might use a block (or sticky note) labelled "Options Chooser", which represents the fact that you know you need some type of widget on the page for choosing options, but you defer saying what exact form that wll take or how it is laid out on the page.
This way, you can build a picture of all of the functionality needed in a given view, and even try out interactions in a walkthrough, before moving on to design the detailed layout of the page.
@evan: the choice of "views" was deliberate. I wanted to think of things as being chunks of portable content. So a view might not always be equivalent to a page, but usually it will be. Using "page" seemed too prescriptive. I should note that this idea is based loosely on the UML--specifically, class diagrams.
@Jonell: I'll answer your questions in sequence, and in haiku. Ok, maybe just sequence.
(1) Visioning: I'm seeing this occurring pre-wireframe, perhaps as information to anchor joint wireframing sessions.
(2) Designer / Developer response: No response as of yet. It's been incubating in my head for a few weeks and I'll probably implement it on the next project.
(3) Client Response: I don't think Pidgins will be client facing; they're still too abstract.
(4) Narrative / Storytelling: Ah, yes. Not always are we concerned with showing the narrative but it's important occasionally. For team needs, I'm thinking of using 1-sentence scenarios of user goals for the page.
I think this is really interesting, and fun to think about. I'd like to explore the model - see if I can get my head around it by trying to retro-fit it against some of the RIA's we've done.
So, I've got lots-o-questions:
1) At what point does this come into play in the "visioning" process for your IA's/UXD's?
2) How are your designers and developers responding to the approach? And...
3) Assuming this is an alternative to the wireframe, how has this been received by clients? (i.e. in a lot of cases, a wireframe or series of wireframes can help depict concepts relatively clearly - depending on the complexity of the interaction. When you put a wireframe in front of a client, it's fairly easy to gauge level of excitement, acceptance, or disapproval of a concept. Do clients feel that the Pidgin depicts interaction models and concepts?
Related to the last question, it's often the case that the IA/UXD has to be a really good story teller, and we rely on our wireframes and sometimes storyboards to help us. Which leads me to...
4) Does the Pidgin help facilitate the "story telling" of an interaction or is something needed to supplement the Pidgin to tell the story? I'm guessing something needs to supplement it, and there are likely several creative ways of doing that depending on the project...and what the client and team needs.
Not only does this approach capture relationships and priority, it tends to translate nicely into a content management system. Many systems use blocks to represent repeatable content and some, Drupal for one, use views to organize content items. While the concepts may not be completely congruent, this model shows a transition from the model of static HTML pages to robust, logic-driven web sites. I think it’s long overdue for UXDs to avoid considering "pages" and consider the relationships between elements. Good thinking, Todd.
Post a comment
We look forward to hearing what you have to say. Before joining the conversation, please take a moment to review our comment policy.