Feeds:
Posts
Comments

I invented wireframes. Okay, clearly I didn’t – you can read Whitney Hess on the history of using wireframes for application and web design – but back in the day (1997), we didn’t blog or tweet every twenty seconds like we do now, or have as many networks or conferences, and I fended for myself with regards to work tools.

So, all on my own, I used my head and came up with the idea of using low-fidelity PowerPoint sketches to flesh out ideas for chunking out information, for how many pages there would be, and what would be the right content and controls to go on each of them. The point was to do low-fi, low cost, quick turnaround stuff that would get stakeholders focused on the story and the deep structure before the details. And it was easy to try different features and to render them in different ways, just by knocking those little boxes around in PowerPoint.

Then many times I’d work with a visual designer and/or prototyper to work out those details — iterating in response to stakeholder feedback, which went remarkably smoother than it would have done if we’d started with a high level of detail from the get-go.

And so after a few years of being a project IA, I moved on to create a style guide and become an internal consultant in my group, and then to do the same for our European affiliates. When I came home after that — back to project work — I was astounded at what wireframes had become in the seven years since I’d first promoted their use. They were essentially fully rendered (though grayscale) screen designs, and they were done in Visio — which to me is as easy to use as if you’d asked me to render my screen designs as hand embroidery. And the wireframes were the sole province of the IA and the stakeholders — visual design had become a process of washing over them with digital gouache, like the relationship between cartooning and inking. God forbid the visual designer should think that this dropdown menu would have better emphasis in the center than on the right, or that given the data density on the page, that box should not be shaded or have a border, or be a box.

And what’s with cutting your own design partners out of the process of understanding why the stuff on the page is there in the first place? And what’s with having three people — an IA, a visual designer, and a prototyper labor at the same level of detail on the same screens, but separately and in different media? Is that not entirely wasteful and crazy?

And so when at the end of Leah Buley’s SXSW ’09 presentation on being a UX Team of One she casually said that “wireframes are on their way out,’ I felt my heart fill with glee. However wedded I am to the word “wireframe,” what I mean by it is a low-cost, low-fidelity sketch that is a conversation piece — a way to have a conversation about story, audience, priority, structure, content and features. It is totally throwaway object, meant only to bring the screens and their interactions to fruition.

See Leah Buley’s wonderful UX Team of One presentation on her site, www.ugleah.com Leah Buley is an experience designer at Adaptive Path.

Be a coach

Personal and Executive coaching is all about helping people clarify their desires, envision their futures, develop a concrete plan towards achieving that future, holding them accountable towards that plan, and holding their agenda for them in the times when they might give in to their fears or to distractions. That’s also what’s required of good User Experience architects and design team leads towards their clients.

Although I created and ran a style guide for seven years of my career, style was the least of my concerns, and in retrospect, I should have lobbied for another title for myself, my group, our documentation and our activities. For in practice, it was always much more about patterns of functionality, data relationships and user contexts than about layout, typography and color. True, we aimed to use and render the same components in a consistent way, but the conversations I had with the rest of the design team were much more often around questions like “do we have a thing that does X, but with seven types of objects?” or “that design works well when users use it infrequently, but slows people down when they need to perform that task twice or more per hour.” Visual designers were pretty clear on what were their tools of expression — instead, it was information architects with information design problems who consulted me most frequently.

Might a design pattern library have suited us better? Perhaps. Most Design Pattern purists are quick to separate the use of a pattern library from that of a style guide, and we certainly wanted visual specifications to be clear and not mere options. If I were to do it again, I would probably build something that is very much like what we had — a component library — but in addition to organizing it by page type and layout, I would work with my fellow designers and developers on how to define and name components with respect to design problems — function, relationships, and contexts — so as to answer better the questions of my main style guide customers: the architects.

I like the way Infragistics has done this with Quince, released early this year. You can read more about it on Infragistics’s blog. But rather than simply use Quince and add visual specifications, I think it would be more successful if it were co-created within a company so it would better correspond to the mental model particular to that organization, and its indigenous design problems and language.

I have found that for large, content- and functionality-rich sites with many different types of users and business contexts, page-template driven content management and other systems break down for want of sufficient flexibility, or because there are so many page templates created in the system that it’s easier to take a basic one and mess with it than to find the one you need.

A possible way out? Work with a rich, well-organized component library and a good flexible page layout system — I’m a bit of a grid-geek, but I recognize that’s not the only valid approach to designing layouts. So in this sort of system, you have page layouts, and then stuff to put in them. In my old group, we held onto the concept of page types, but they were not built into our templates. Page types were, instead, examples of pages with specific uses — such as a landing page, an article page — with a list of suggested components. They were archetypes, guidelines — not templates.

Working with a limited number of page templates creates a nice neat system, and for smaller single sites, it may be just the thing. But if using a limited amount of page-based templates precludes the ability to do well-targeted, effective and persuasive communication, then I would suggest considering a more open, layout- and component-based system — and having plenty of visual variants for the latter.

Designing for reuse and consistency requires rethinking the way designers work: designers need to think globally and design locally. That is, while designing specific sites and/or features, we have to understand how what we create partakes in the design system as a whole. Does it leverage the core principles? Does it support or contradict a pattern used in another section of the site or of the product suite? Could another established component be used or extended to meet the local need? It takes a certain type of designer who has equally strong left- and right-brain skills to do this: these are the designers with whom I want to work.

Scope and continuity

On a film crew, there’s a role called “continuity” — this is the person that makes sure that while the film is being shot in scenes, it all hangs together as a whole. For example, he/she makes sure that the light is at the same angle as in the previous scene if there’s supposed to be a short time lapse between it and the current one. Or that the dress that was mussed in what will seem to viewers to be a second ago is still mussed in the next second.

What this takes is both an exacting eye for detail and the ability to hold the whole effort in one’s imagination at that same time. This ability to shift focus from the globe to the grain of sand, and to any stop along the way (continent, coastine, shore, beach, dune) is what I hope is my strongest skill. It’s certainly my greatest passion.

Big systems do not spring up for the sake of themselves: the reason for all of the grand effort it takes to get large web sites up, maintained and expanded upon is for people to use them and give you their money. They’re more likely to give you their money if your product is good, your site is easy to use and they have a good time there.

So the experience a user has on your site is the point of having a website. But many times companies large and small lose sight of this. What can one do as a UX professional to get them refocused on their end goal? Here’s a short list:

  • Communicate
  • Demonstrate

Communicate through as many channels to which one has access: set up a UX council with allies and hold periodic meetings, meet one-on-one with stakeholders regularly, set up an email distribution list to send out interesting articles, do a poster campaign, host mini-conferences, and in the context of projects speak up for the user experience when and wherever necessary and possible.

Demonstrate by doing great research and great design. Make sure design choices are well thought out, well-founded in the intersection between both your users’ and your business’s goals, use the technology appropriately and are thoroughly communicated to the team in plain language. Listen hard to the people around one — if they’re making choices about what goes on their website, they’re doing UX design; however consciously, with whatever level of formal knowledge. Bring their UX thinking to consciousness, and support, supplement or gently challenge it. Demonstrate radical curiosity. Be well-read and let it show. Know the competitors and current trends, and show that, too.

Follow

Get every new post delivered to your Inbox.