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

agile user experience design

if you’re subscribed to about 27 job searches like I am and are very specific about the nature of your search parameters, say, ooh, I don’t know, ‘user experience Norwich 100+ miles’, even though you end up with a list of java developers and IT managers in Stevenage, then you’ve undoubtedly seen a proliferation of job specifications that on the surface look like exactly the kind of thing that matches your skillset and you’re just about ready to call up that recruitment consultant who likes using capital letters and concatenations of job titles repeated every other word throughout the advert, when you see, near the end of the page, the ‘Agile’ word. as in, ‘must have experience of working in an Agile environment’. or ‘Agile experience required’. or ‘we follow an Agile development methodology’. or ‘Agile Agile Agile Agile Agile Agile‘. or something like that.

this is fair enough. I applaud the adoption of a structured methodology to support a development process since I know just what a creepy mess it can be to not follow any method at all. and Agile looks like its a reasonable software development practice. it means you do things quite quickly. I can do that. I can do things quite slowly too, but if there’s a team dynamic and a project management style that encourages rapid development and lots of meetings where you stand around each other’s desks pointing at widgets and occasionally breaking out to the whiteboard that doesn’t have any pens, then that’s fine. but just because you do that, it doesn’t mean you’re necessarily following an ‘Agile’ methodology. I mean, its ‘agile’, as in, you’re able to make decisions, act upon them, and reset the project outputs with expediency, but, you know, it might not be necessary to attach a label to it and market it externally as that. you don’t have to have a capital ‘A’. because as soon as you do, you’ve changed the job description entirely.

the role I’m in now is pretty agile. working for clients in the city on software development projects that require daily collaborative sessions on user journey development and wireframe builds necessitates a rapid, robust style of user experience design. I’ve had the luxury, in previous roles, of having lead time for development and intervals of checkpoints measured in weeks, when in reality, a couple of days was probably more sensible. for this project, however, there is a definite urgency, not least driven by expenditure, that requires that the user experience design iterations are compressed into daily outputs and reviews. I can’t say that I prefer working one way or the other, although the day-by-day cycle definitely drives increased output and, as yet, doesn’t appear to impact either the focus on the user or the quality of the output (he says, doing that breathing on his fingernails and polishing them on his chest thing).

so why am I bothered about what somebody calls their particular working environment, when it really doesn’t matter, since it doesn’t effect the ability to deliver engaging, meaningful user experiences? because that word is a barrier to employment. that’s why.

barrier 1: ‘I don’t see that you’ve got enough Agile experience’. this applies when you sit with a development team as part of over 3 hours of face-to-face interviews for a user experience role at a software house in a corner of a business park somewhere between an A-road and another A-road, and are told they work in an ‘Agile’ environment, whereby they do all those things I’ve just mentioned with each other’s desks and whiteboards with dry pens. in this case, no amount of discussion on my part about working to suit the environment and being fine with daily scrum meetings and managing sprints and workstreams and swimlanes or whatever, manages to persuade them that I can work in an ‘Agile’ environment. because I can only demonstrate that I could work in an ‘agile’ environment. I can’t actually check the box, that I probably designed in the first place, that says ‘Agile (make sure its a capital)’. or they just didn’t like me. which is equally likely.

barrier 2: ‘I don’t see that you’ve got enough Agile experience’. fair play that if after half a day of talking to real people in a stuffy conference room about a role that they then use the ‘Agile’ thing to let me down. at least I had an opportunity to demonstrate that I was the right candidate. at least I was across the threshold. at least it was a team of people who at least have their own understanding of what ‘Agile’ means. this is just a mild annoyance. in contrast, what really gets my goat, even though I don’t have one, is the creeping proliferation of ‘Agile’ as a keyword in job descriptions posted via recruitment partners on behalf of clients. this nastiness is much worse, because it actively excludes potential candidates before they even have the chance to demonstrate their worth. it is the doubled-edged sword of internet recruitment whereby I might maximise my presence in searches or on recruitment portals by ensuring that ‘user experience’ or ‘information architecture’ or ‘UX’ or ‘IA’ is a key attribute such that searches will find me. and that’s pretty successful. mind you, you can probably find me if you search for ‘Norwich’ and ‘idiot’ or something, but that’s a different user altogether. the downside of optimisation in this case is that I don’t use the ‘Agile’ keyword to enable a higher ranking. that’s to say, when those machine-driven CV scrapers are trawling for candidates based on a job description with ‘User Experience’ in the title and with ‘Agile’ as a keyword requirement, I’m probably not on the list. unless its for a job in Norwich. which it never will be. why not just add ‘Agile’ to my CV? because, in fact, and to the point, I can’t honestly say I’ve worked anywhere that has used the ‘Agile’ word, despite the fact they might be ‘agile’, so I don’t use the word. It would be a lie.

barrier 3: ‘I don’t see that you’ve got enough Agile experience’. slightly more galling than not even getting onto a shortlist is getting onto a shortlist managed by an agent acting on your behalf who understands what ‘Agile’ is marginally less than they understand what’ User Experience’ is. I have to say, I have come across some excellent recruiters at some excellent agencies, and they really understand the marketplace and the applicability of roles to my experience. but they don’t manage all the client relationships. there are numerous black holes I’ve been down whereby the only application route is online to an agency I’ve never heard of to a client I don’t know, based on a job description I quite like the look of (which, coincidentally, pays going rate). after falling through the silent vacuum for a few days, not really getting any indication of application status, I might endeavour to find out what’s going on. if I’m lucky, the application process will have yielded a phone number for the recruiter which means I can actually follow it up. if I’m unlucky, I’ll contact them and they’ll say ‘yeah, I saw your CV, but I don’t see that you’ve got enough Agile experience, and they said they were looking for that, so I didn’t feel I could put you forward’, or ‘yeah, I saw your CV, and they liked the look of you, but they didn’t see you had enough Agile experience, so they didn’t select you for interview’, or ‘Tim Caynes? What job was that? User Information what?’ . its the human interpretation barrier that is the worst. I’m reliant on a third party communicating to a forth party about my personal experience and applicability when they have to negotiate around a keyword that neither they understand or I believe should be a gating factor. or they just didn’t like me. which is equally likely.

as Rob said the other day ‘Agile? That’s just working quickly, right?’ I can do that. Do I need to pass an exam or something?


listening post: the who – 5:15
Archives
Categories