things what I writ

Expose yourself – design workshops in the real world

When I uploaded my slides from the recent IA Summit in Denver to slideshare, I had particular problems with uploading the speaker notes, which, still now, are not available. I’m a great believer in using simple slides as a visual enhancement to a spoken narrative, and so when those slides are posted on their own, there can be some strange interpretations.

In particular, I have one slide in that presentation which simply says ‘Expose Yourself’. On its own, it could be read as something of a mid-life crisis admission in a magistrates court, but in my defence (pun intended), it’s actually part of a series of slides that try to explain the benefits of opening the black box of design, to encourage collaboration with clients and stakeholders to maximise brain power and increase efficiency.

I recently worked on a project that had a quite specific definition of the design deliverables that were likely to be required, before we’d even understood the problems and thought about solutions. This sounds bad, but really, it isn’t. When we’re defining a statement of work that clients can agree to and sign off, especially for newer clients, we’re not yet in the position to sell them a period of time that’s largely undefined, that we’ll somehow magically fill with analysis and design. Pragmatically, we have to describe something tangible for delivery, based on our previous experience of similar projects, that is meaningful and understandable. Critically though, that ‘tangible something’ has scale – and that is where it gets interesting.

On the project in question, the design deliverable was pretty well-specified from the outset. But following the results of focus groups, it was clear that we needed to spend some serious thinking time trying to understand what the deliverable really needed to be – which was potentially quite different from what we’d anticipated. The scale of our ‘tangible something’ was measured in days, and in order to set our new course, we had to agree on the best use of those days. In this case, we proposed that to understand that, we should get all the project stakeholders to bring their thoughts and ideas to the table and that we spend a day working together on defining our goals and objectives and thinking about how that looks when we talk about structures, clusters, boxes and arrows. Yes. A design workshop.

Design workshops can be super-effective for clarifying objectives, surfacing ideas, analysing research outcomes, using up flip charts and making swift progress through design challenges. But they are not for everyone. They’re not for all clients. They’re especially not for all designers. While more than one head is almost always better than just one head to solve a problem, there can be a reluctance on the part of professional problem-solvers to allow others to collaborate with them on that most cerebral of tasks. That’s why I say you have to expose yourself. Let clients, stakeholders and anybody else who might have an opinion be part of your process and maximise the benefit of all those brains being in the room. When you’re steering a new course for your project ship, it should be all hands on deck. If you want to hit new project targets, you should have all your brain-wood behind one arrow. If you want to continue with ridiculous project metaphors, you should all, well, actually, forget that one. The point is, design workshops really work, and if you’re not doing them, especially when you need to corral project stakeholders and think about design direction, then I really think you’re missing a trick. In this case, the workshop enabled us to clearly define the design requirements, scope out the next phase of work and turned on at least a hundred lightbulbs over people’s heads. In the end, just talking through design propositions in the workshop radically altered the client’s expectations for how their business could position themselves in the marketplace. We’re going to do another one soon, where I’ll expose myself some more, but better to be outed in the conference room of collaboration than stuck on my own in the black box of design.

Lean UX: The UX you wish you were doing

Jeff Gothelf, Director of UX at TheLadders.com, has a great proposition for what he is calling ‘Lean UX’, which reminds us what’s great about user experience design and how, potentially, we’ve over-specified it.

His central proposition is that it’s about time we got back to looking at experiences, rather than deliverables. Deliverables help us build commodities and describe solutions and actually, they can be pretty handy to work backwards from when we’re selling into a client.

The trouble is, deliverables can also define our outcomes and we often simply work towards those outcomes, filling in the boxes as we go. I can do that. I can do that on my own, in a dark room. And then I can ask users whether it’s any good. But really, we’re missing the experience design opportunity – to get those users at the heart of the design process.

All Jeff is really advocating is that we stop for a moment and remember what user experience design is about – solving problems. You don’t solve a problem by simply picking the right deliverable. You solve a problem by understanding the problem, engaging with the user and having a conversation.

Jeff’s method includes quick conceptualisation, early collaboration and a distinctly unselfish approach to design success, but what keeps it simple is that he doesn’t focus on artefacts, documents, or whether you want it in Visio or Axure. Because that’s not the point. It’s about:

  • Control: giving it up isn’t giving it away, you’re still the ‘keeper of the vision’
  • Momentum: keeping everyone engaged and motivated
  • Quality: not compromising on finding the solution
  • Feasibility: keeping an eye on implementation (but not the documentation!)
  • Filling the blanks: the more you talk, the more you see


To quote one of the quotes he quoted, “Speed first. Aesthetics second” – Jason Fried of 37signals.com.

I’m paraphrasing here, so to get the full story, check out Jeff’s presentation.
Lean UX: Getting out of the deliverables business

View more presentations from Jeff Gothelf

If you want to hear him talk about Lean UX in person, he’s at a number of speaking events this year, including the IA Summit in Denver, but I should probably mention that there’s also a scintillating discussion of the value of thought in experience design happening at exactly the same time, so if his session is full, perhaps you could consider that one instead.

Building theme-based information architectures

There is often a temptation to dive into information architecture design based solely on acquired knowledge and a well-articulated business objective. It’s quite possible to produce meaningful taxonomies and content structures in this way, especially for discrete, closely scoped projects. However, some of the most effective structures evolve when iterative analysis of research findings and discussion outputs start to surface emerging themes.

I recently worked on the development of a new sales and investments channel for one of our financial services clients. A sales and investments channel in of itself is not a particularly unusual proposition and there is a depth of experience within the team that might predict some of the outcomes. We might even consider sketching out the concepts in our heads just to start the conversation, since the business objective is reasonably clear. In doing that, we might even get it done quicker than anybody planned, or budgeted for. I might even get home in time for tea.

How we really maximise the potential of the design phase is if we take the insights from a well-executed discovery phase, invest meaningful time to digest and analyse the messages we’re getting from customers, and we start to build up a picture of an ideal customer journey. I’m not talking here about spending a day in a dark room with a stationary cupboard’s worth of post-it notes and walking away with a full site map. All we should really be aiming for at the end of an initial design session is identifying those emerging themes and understanding how accurately they reflect the voice of the customer. Themes are really just a logical clustering of questions, statements and pain-points related to a customer’s interaction. Since they’re deliberately vague at the early stages of design, they’re not distinct categorisations with well specified hard attributes, but more of an expression of the customer needs and desires. If that doesn’t sound pompous enough, I’d also suggest that they often describe the soft attributes of the customer’s emotional engagement with the site, for example, ‘I’m worried about the future’, or ‘I need help on this’. Identifying these themes early provides a clear customer-centric reference when iterating into task-based journeys and navigation models.

Themes are also a great way to solicit empathetic feedback. It’s more meaningful to describe a potential customer journey to a client, for example, if they can clearly empathise with the customer. Using needs-based descriptions with more open language, through themes, it can be much easier to evaluate a customer journey than by simply referencing a label on a navigation entry point. Consider the difference between ‘Protecting my future’ as a theme and ‘Savings’ as a label. While one might not map directly to the other, there is still a much clearer expression of the customer need through a theme-based approach, which sets the context for discussion and iteration.

There are number of approaches to how we take discovery outputs and begin to build out information architectures that place the customer at the heart of the discussion. Using a theme-based approach is one of those that I rather like and it has proved successful in articulating the voice of the customer, particularly when talking with clients. While this has been a brief outline of the approach and some of the benefits, feel free to contact us to find out more.

inheritance in user experience design

by which, I mean, inheriting someone else’s user experience design, or proposal, or thesis, or presentation, or, even, 5 year plan. there is nothing quite so painful but satisfying as developing your user experience methodology and describing, in the most insightful of prose, the application of the process unto the design challenge that is the growth target that begets the business that spawns the project that produces the artefact that describes the outcome that provides the design solution. from whence that design solution was so eloquently detailed is the brainism that you channelled and distilled and expertly crafted into methods and practices and timelines and checkpoints that spake of some experience alchemy magick’d up from your mind cauldron.

in other words, its nice to define a process that supports a practice that enables you to deliver against your goals and make the online world that little bit better each time. actually, that last bit might be a rather grandiose and pompous blart, but without there being kind of user experience light at the end of the funnel towards which we steer the online improvement charabanc, why would we bother?

therefore, having just said whatever I just said there, it’s a significantly greater challenge to mind-mangle a process design when it actually begins as someone else’s. I’m currently co-working on a proposal for developing an experience design practice that helps enable a business transition. except that proposal is someone else’s and I’m collaborating on the further development and enhancement to get it to where it ends up on a projector in a boardroom and people start raising their eyebrows and checking their iphones for status updates from farmville, but its a good challenge. its also a challenge that’s likely to make the outcome more successful. in this case, the two heads are much better than the one head. the one head being mine.

just try everything

there is an option during an interaction with a particular screen, page, interface, device, port, socket, panel, window etc., that can be so effective that its a wonder we don’t do it from the outset and avoid all that well-thought-out user experience nonsense. its the option I most often select when I’m beginning to feel the vein on my forehead and there’s small beads of ‘stay calm’ sweat forming on my temples. more often than not, its when I’m trying to find the enhancements panel in window media player, or wondering why on earth something that used to be quite so simple in windows XP needs to be quite so appallingly difficult in vista, but quite often, its at the point when I have piece of hardware A that need to somehow interface with hardware B in order to successfully deliver experience C.

its normally at that point I just try everything. this is actually more successful with hardware issues since notwithstanding the screwdriver/electrical outlet scenario, most should-be-compatible-somehow hardware interfaces allow you do mash them together in any number of ways before doing it the right way. things don’t really get broken much and there’s not very often a knock-on effect to other resources. consider my vein-throbber today. I was only trying to wire in my previously perfectly serviceable 5:1 speaker system into the back of my new desktop system – both dell. of course, since the last computer, they’ve changed the sound card interface and so it all looks a bit different, although its all a bit the same, its just that the 6 jacks plugs and 1 I/O cable for the front left, front right, rear left, rear right, center, subwoofer (I have to say them all out loud like that because the old soundcard configuration utility spoke them out like that like some teutonic sat-nav for audio hardware) now don’t have the same number of sockets and boards and interfaces and things like that to plug into. but they have some of them. needless to say, crawling around the back of a PC with a torch when you’re supposed to be analysing financial consultancy data outputs doesn’t really have a long attention span, so the temples are glistening pretty quickly. I tried a few insertions and extracted myself from under the desk, hitting my head in the process, to see what was coming out, but it was variously a fuzzed warbled cross-phased back-to-front tinny bass calamity of an Aimee Mann track. 3 or 4 swaps and re-insertions and head bangs and torch positionings later, there really wasn’t any progress, and the markings on the interface panel that were supposed to somehow help me out were just making it worse, since they just appeared to be crop circles to me. its at that point I decided it was probably worth the risk to my 800 quid desktop if I just tried everything and anything and just wrapped this sorry exercise up.

needless to say, as soon as I just randomly flapped about with whatever cables and plugs I had in my white-knuckled fist at the time and crammed them into the nearest probable orifice, then hey presto, goodbye caroline. I should have just done that in the first place and saved myself the bother. which is what I subsequently did with windows media player. so craftily obfuscated are the enhancements that rather than navigate a series of contextual menus or follow a meaningfully and meticulously signposted user journey to the graphic equaliser of beelzebub, I just randomly clicked all the buttons on my mouse at stupid speed across all the panels in the media player container. and it worked. I saw a fleeting reference to a fly-out menu that said ‘enhancements…’ and followed that menu thing all the way to frequency nirvana.

so now I’ve got my sound balanced exactly how I want it, and my speakers are working just fine thank you. once I’ve rebuilt the music library I deleted in the process, it’ll be great.

listening post: nothing – I deleted it all

even more gainful

since I last extoled the virtues of an employer, I’ve mercilessly cast them aside in favour of an even more virtuous employer. that’s not to say the last one wasn’t virtuous, for it was, and I liked it, but my new and current employer held all the cards in terms of my experience, development, and personal circumstances. if I were to have written myself a perfect job description (which I often did) while I was on the 6:10 train to user experience land (London) every day (which I was), it would have looked something like this:

  • user experience consultant
  • 10 years+ experience
  • permanent
  • salary like what I had before
  • involved in strategy for growth
  • oh, and in Norwich.


that was, effectively, the holy grail of job descriptions for me. so, it was with some surprise that I was contacted by Michael at localrecruiteragency to let me know that there was a role available that was indeed exactly that job description and was I interested. needless to say, I asked where their hands were so I could bite them off immediately. once we started talking, it was obvious (to me) that this is where I should be, and thankfully, they thought I may be worth a punt, so here I am. which is nice.

Archives
Categories

Share