globalful

what we am are

on exposure

I was speaking with Andrew the other day about the transition from in-house to agency and how that adjustment takes place after a number of years at the former. because a number of years at the former has a particular pace and a particular comfort in the ownership and management of the design you do and the thinking you think and the constraints you know and the collaboration you undertake and the scrutiny under which you find yourself and the measurement of success that you might be subjected to which is likely measured over a period not much less than a decent-sized freelance contract against a set of goals and objectives mapped out over a period not much less the bronze age.

if you have spent a meaningful amount of time as a resident designer on the client side, either as a larger team, or, worse still, as the design team of one, you’ve likely woken up at your desk one day and realised you can probably go back to sleep for a while and nobody will notice until the end of the quarter. a massive generalisation of course, and more likely just an accurate description of my 14 years in-house, but the point is that the pace and scrutiny is different. and it can be a safe place. and you can get away with it. and you can sometimes disappear completely.

once you make the change, however, you can suddenly find yourself very exposed. I thought it was perfectly acceptable to take 6 months to design a faceted navigation system for a line of hardware. and, you know, it kind of was. but as soon as you get started on your first proper design project agency side, you are immediately aware that there is something different. people want to know what you’re doing all the time. they want to know why. they want you to explain to them the things they don’t understand and tell you why those things you suddenly can’t articulate aren’t actually that good anyway. they want to question everything you do. and, by the way, that 6 months? that’s actually 6 days here. if there’s one thing that really hits home in your first 3 months of transition, it’s the change in pace. and it’s not that the change in pace is a bad thing. it’s just that it feels like you don’t have enough time to think. which means you don’t have enough time to design. which is stressful and surprising and difficult and awkward. because you might not actually be able to do it. you might fail. and everyone will be able to say they told you so. and you’ll be exposed.

if I’m honest, it took about a year to get used to the change in pace, which I’m sure will be validated by the account teams who’s budget I used to work that out. I’m pretty efficient now. and that doesn’t mean I’m by any means a worse designer for being a more efficient designer. it just means I’m a bit quicker. if anything, I believe it makes me a better designer, since I’ve worked on the skill that is understanding and articulating the very thing in a given design challenge that is where the opportunity lies. and I can do that very quickly. and I can do it for multiple design challenges. and I can move from studio to studio, whiteboard to whiteboard, desk to desk, and I can point to the thing that matters. it’s an acquired skill. it takes time to learn. but the efficiency in the clarity is what facilitates pace.

the less tangible form of exposure comes when you are suddenly placed under an intense level of interrogation regarding the very thing that you think makes you a designer in the first place. your design thinking. or whatever you want to call it. that process you go through when you think about stuff. and write down words. and draw boxes. or abstract categorisations of emotions. maybe you use different colour pens. maybe you cut bits of paper out and rearrange them in a way that you think is the responsive version of the jean genie. whatever you do to evolve insight into articulation. evidence to ideas. you know, DOING DESIGN THINGS. for that is the place where you’ve likely never really had to justify yourself to other people who might actually be designers too who might even be better designers who might even be honest designers who might actually tell you what they think. because when design is money, clarity is currency. you really need to be able to explain yourself. be under no illusion, when you work for an agency, your constraint is time. but your reputation is all about quality. so quality is, and should be, ruthlessly monitored, evaluated, and understood. and that’s why the integrity of design and design thinking is the first thing that you will get caught out on. well, apart from the pace thing. but it’s not personal. even though that’s what it feels like the first few times someone like me sits down with you, looks at your designs and pulls that horrible squinty patronising-but-really-caring face that tells you there’s something not quite right. but I do that because, actually, there’s something not quite right. I’ve exposed you. how you then deal with that is that up to you. if you’re anything like me, you’ll probably print out pictures of me and stick them to your bedroom door whereupon you’ll spend a full 3 nights throwing manically sharpened pencils at them sobbing in your underpants slowly mouthing “I can design. I’m a good designer. I can design. I’m a good designer. I can design. I’m a good designer” over and over and over until you’re all cried out and you collapse on the floor onto a pile of ripped up creative reviews as the queen is dead plays on repeat over the wail of sirens and the incessant banging on the door.

you get over it. it’s all part of the transition. welcome to the real world.

listening post: biffy clyro – 57

I don’t need your design process

Sometimes, you question whether you’ve just been winging it for the last ten years. That’s usually when you’re surrounded by people you’re supposed to have an affinity with, but they’re all talking about something you think you should probably understand but quite obviously don’t. Worse than that, perhaps you’re supposed to actually be doing it, since, well, surely that’s what you do. That’s what I felt like a couple of hours ago.

I once applied for a senior user experience designer position for a software company in Cambridge. The only sticking point, in their mind, was that I didn’t have any Agile experience. I won’t labour that point, because I have already, suffice to say, despite my protestations that it really wouldn’t be an issue, because I’ll still be able to function if for some reason we have to stand up on a Tuesday morning, it was the one thing I couldn’t honestly say I could tick off their list. I couldn’t adopt their process. I didn’t get the job.

This is ridiculous to me. As a designer, I tend to go through a process. I tend to take a problem, try to understand it, and try to solve it. By design. There’s usually more to it than that, but, really, not much. I’ll put my hand up right now. I could not articulate the difference between waterfall and agile, if questioned. I’m not even sure if those things stand up to comparison on common criteria. I’ve seen the lean UX manifesto and been talked through it a few times, but it’s still just the good bits of UX, without the bad bits. If you want to throw in kano, keynote, kelloggs, that’s fine, but it won’t change the way I approach a problem. I might find that some of the tactical methods are useful, helpful, more efficient. I might loosely adopt some strategies and roll them into a framework suitable for the task at hand. I might find that faced with a hill, just skiing down it is the most appropriate thing to do.

But I won’t pick a process. I’m fine with the one I’ve got. It’s not wilful. I don’t doubt your process is appropriate, effective and successful. I just don’t need it. But thanks for sharing.

There is no user experience design process

Whenever I look at a new project and I’m mapping a process to the task in hand, I’m reminded of those cutlery deniers in the Matrix. There is no user experience design process.

That’s not to say there aren’t a few processes to choose from. It’s easy to argue that user experience design doesn’t follow process, because really, as Chandra Harrison pointed out the other day, the process is really user-centred design. User experience is really, well, the user experience. Except, I call myself a user experience designer, and when it comes to ‘designing stuff’ that addresses user needs, identifies requirements, suggests solutions, optimises performance, but also needs to be designed efficiently, predictably, and consistently, there’s got to be a reference model for how a design project runs. Well, I say there’s got to be, it’s more like there should be.

Building a design framework

Whatever process you use, if you’re just using one, that seems to work for everything, it might not really work for anything. At least, it might have worked for one thing, but a singular success does not necessarily define a re-usable method. Much better to understand and review previous design projects to understand which approaches worked best in specific instances and then build a design framework that actually supports building your own, modular process to support multiple projects.

There’ll be traditional activities in there, identified from the ground up, like research, design workshops, competitive analysis, wireframing, persona definition, prototyping, and so on. There’ll also likely be a more generic process pathway within which those activities sit. Think ‘discovery’, ‘ideation’, ‘visualisation’, that kind of thing. How you put your framework together largely depends on what kind of projects you, or your organisation, run, but you’ll only know what the elements are if they’re based on a thorough understanding of prior and planned work. How rigid the resulting framework is will depend on your client mix and how diverse your projects are. The flexibility in how you allow staff to pick the best, most relevant elements and roll their own process to suit those clients and projects, is what makes your framework delightful, rather than frightful.

Framework schramework

I should point out that everywhere I’ve worked as a designer in the last 15 years or so has had a project on the go to build the framework I’m talking about. The ones that don’t work tend to focus on deliverables between activities and phases. The ones that work better tend to be more focused on the definition of the activities themselves and what value they add. And, of course, they’re probably redundant anyway, since lean and agile anti-processes are surely going to take over the world. Either way, I’m looking forward to seeing the next one. I’ll let you know how it goes.

listening post: u2 – friday muddy friday
Archives
Categories