things what I writ

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.

A word for a thousand pictures

Well, maybe not a thousand, but a few. Maybe a hundred. And more than just one word. I mean, we’re wont to drivel on about pictures telling a thousand words and that’s pretty useful when we sit in a box all day and sketch things out and then justify it to project managers by saying that it’s critical to visualise and that it helps tell the story and the client will respond, like, totally strongly to that

Except it’s not always true. I’ve spent all day in a box sketching things out that, like, a client will totally respond strongly to, but they simply don’t tell the whole story. They don’t replace a thousand words. There needs to be some words.

And it’s those words which actually articulate the human behaviours and cognitive processes that I think really need to be understood, because it’s those that make the difference in this case. It’s about the emotional response and what that can tell us with regard to the design decisions we make. The pictures are nice, but on their own, however much I stand in front of them and wave my arms around saying things like “this totally expresses their engagement franchise model”, they don’t provide the full contextual description. I can’t have a conversation with the clients about how their customers are feeling and without demonstrating that, I’m not really going to honestly say I’m designing for a great experience. I’m just drawing good pictures.

To Boldly Glow: Experience Design without Borders

When creating user experiences, you need to understand the problem you’re designing a solution for. You’d better engage the users, the customers and stakeholders. You’d better evolve those insights into concepts, journeys, information architectures and design frameworks. You’d better work with the best build and delivery partners.

Most experience design agencies are set up to be able to do exactly this. Most experience design agencies do it pretty well. Mostly

Commoditisation of service offerings

However, as the experience design industry approaches a critical mass, such that it is able to commoditise its service offerings, those services cluster into a set of repeatable, predictable and marketable objects, like practice moths around a service flame. Some agencies might focus on the research cluster. Some might prefer to lead with the design and build cluster. Some might really be able to deliver them all as an integrated experience design offering.

But we’re evolving into digital utilities.

While those commoditised experience design services help clients and agencies agree on deliverables, costs and timelines, the resulting engagement might be less collaboration, more subscription. If a client really does have an articulated, addressable problem, and the service offerings have evolved to the point that we can deliver great user experiences without too much operational overhead, thank you, then everybody is happy. But what about the client that can’t articulate their problem? What if they don’t even have a problem? What if they just have a feeling that things could be somehow ‘better’?

Designing without borders

That’s where we need to take our experience design practice back to designing without service borders. We still gather insights. We still interpret and evolve. We still detail and deliver. But our engagement is based on our excellence in crafting experiences that delight customers and users. We don’t lead with services, we lead with design. Our designers are visionary. They understand the complexities. They’re vibrant, exciting and unique. They don’t shuffle into that workshop with brochureware, they walk in to that workshop self-aware. They boldly glow, and so they should.

listening post: daft punk – the grid

Learning workshops at a workshop workshop

Last night I plodded through the rain from a full day of usability testing to attend the latest UXDO practical session at Fortune Cookie in Clerkenwell. I took a lot from the previous better writing session with Martin Belam and Cennydd Bowles, and was looking forward to this session on better workshop facilitation. A workshop workshop, if you will. One of the main draws of the event was, again, the quality of the speakers that Sjors Timmer had managed to line up. This time, Leisa Reichelt and Giles Colborne were leading the session. Any time I’ve seen them speak, either on a stage, or at a bar, they always have something valuable to pass on and have a great, engaging style that really draws you in.

Having scribbled my twitter name on a post-it note and stuck it on myself (UX event protocol these days) I joined the session a few minutes late and notwithstanding Jonty’s assertion that he was drinking all the beer, I managed to pick one up and get stuck in. Which is the point of the UXDO sessions – to just get involved with your peers and learn what you can from each other. As Leisa mentioned, many of us have run successful workshops and are happy facilitating, but there’s always an opportunity to share those experiences, listen to others and discover new techniques and approaches that might take you just slightly out of your comfort zone and help make you a more well-rounded practitioner.

The thrust of the evening was, for the 25 or so of us, to identify what the barriers are to us being successful in facilitating workshops and how we might come up with solutions to help us overcome or address them. That was done over a 2 hour sprint of a workshop by way of brainstorming, affinity sorting, defining problem statements, comparing, ranking and collating, discussion and identifying solutions and rolling it all back together again. We threw in a bit of KJ method and shared tips and techniques along the way and, in the end, came away pretty satisfied with our outputs. At least, I was pretty satisfied. I mean, it was a pretty unrealistic workshop set up, but it was really successful in exposing methods, focusing objectives, setting expectations and understanding the kind of issues that might need considering in most workshop scenarios.

Leisa and Giles are even writing the whole thing up, which is an admirable commitment to the UX cause. Thanks to them for facilitating a great evening of learning and sharing. I even managed to crash the UX after-party (pub), since I didn’t have to travel back to Norwich, and had a rather nice conversation about the UX of allotments with Leisa and shared a ‘we seem to be the last ones here’ moment with Boon and Jeff before heading back to the hotel in Euston to watch an extraordinary football match between FC Barcelona and Real Madrid on Spanish TV, which was rather less well facilitated than the workshop, it has to be said.

How I got found as a user experience designer

User experience design is a proper job. At least, user experience designer is a proper job title. It’s a job title I’ve given to myself for years and it’s worked for me to describe to others what I do, without necessarily having to describe to others what I do.

Three little words

More importantly, ‘user experience designer’ works as a job title when you want to be found. When I was hawking my freelance self around a couple of years ago, I made a decision on how I wanted to be discovered, and how easy I might facilitate that discovery. That decision was to bet the farm on 3 words – user, experience and designer – hopefully in that order. How I used those 3 words, and where I used them, was an important part of the strategy, but it is the 3 little words themselves that were to describe me to others.

Optimising for search

From the outset, I intended to capitalise on the visibility of those 3 little words and how they might somehow be associated with my own name. I thought at least having my name appear on the chunk of content returned by a search query would be a start. I like to think that the eye-tracking results would show a strong relationship between the user experience designer title and a real name in reasonably close proximity such that it fired some neural connection in the brain of the user that suggests I might be actually the embodiment of a user experience designer and therefore justifiably and majestically hoisted to the top of a mental list that someone is keeping.

There were a number of places I wanted that to happen:

  • My personal sites
  • CV/resume hosting sites
  • Recruitment sites
  • Job sites
  • Related sites (job title on flickr, linkedin, facebook)


Some of the searches I imagined were public searches, via google, bing, altavista, lycos, grep –r ‘user experience designer’ /theinternet, or something, for which I optimised on page titles, prominent usage in content blocks, page data, and so on. No black arts there. Others were more specialised, internal searches, such as cv/resume scans on recruitment databases, or paid-for searches on job sites. In these cases, I made assumptions about the data that was being interrogated, often based on the forms that collected the data, and tried to optimise based on that. For instance, I knew that no real person would actually read my uploaded resume until it passed at least round one of the keyword scanrobot, so if you’re not being specific about your job title, job categories and experience, then you stand less chance of rising to the surface, like Keanu Reeves does, when he’s dropped out of that slimepod into the machinespittle and chooses to breathe. I mean, a bit like that.

It takes a little patience to consistently optimise across multiple sites, with different search methods and black-box operational models, but the most important thing, as far as I was concerned, was to retain the focus on those 3 little words.

Maximising metadata

On its own, however, optimising for search using ‘user experience designer’ alone, was not enough. It got me closer to being discovered and considered, but I also needed something more unique that I could associate with the job title, that would filter the outputs to make them more about me.

Knowing that being found by virtue of someone looking at my own web site would be nice, but unlikely, I targeted those other sites that held my data, such as cv/resume sites and recruitment sites and picked a set of 3 attributes that I would bet my other farm on. Since these sites are largely form-based in their data-collection, and have reasonable overlap in their data sets, it is easy to pick the attributes you want to focus on and map that to the metadata they support.

The 3 attributes I picked were:

  • Location
  • Type (Freelance/Permanent)
  • Rate


It’s here that I had a special case, which was really the determining factor in being found. If I were wanting to stand out from a crowd of user experience designers, who had all optimised for search, and, for example, all lived in London, I’d be faced with a bit of a challenge. A user experience designer in London is like a bicycle in Beijing, right? They’re all over the place. Saying you’re in London doesn’t make you stand out at all.

Location, location, location, location

But what about if you’re in, say, Norwich? I mean, a user experience designer in Norwich is like a, well, I can’t think a good analogy for there not being many of them, suffice to say, there wasn’t. Which was to my advantage. Type and rate were pretty simple to define, more a case of setting a level of expectation and screening out derisory and pointless offers. Location, however, was my unique selling point. Except it wasn’t a selling point at all. When I moved out to Norwich about 8 years ago, with the support of a previous employer, I knew I’d put myself out on a limb. What I did (user experience design), just wasn’t done in Norwich, so, should I no longer work for that employer, I would have been pretty stuck. One day, I was no longer working for that employer, which is where this story begins.

Nevertheless, Norwich was where I was, Norwich was where I wanted to stay, and so Norwich was the location I added to my data set. And I stuck to it. Which is the point – pick your data, optimise, and stick to it, because if that’s what really defines you, that’s how you’ll want people to find you.

Results

What I’d really narrowed myself down to was:

Keywords:

  • User
  • Experience
  • Designer

Attributes:

  • Location:Norwich
  • Type:Freelance or Permament
  • Rate:£ A number larger than the last number I thought of


What I got out of it was emails and calls from recruiters and robots that were slightly biased in favour of user experience design, and more or less centred on ‘the south east’ (including London), but, since I also included a number of other attributes as part of any upload, application or registration process, I also got a large number of administrator, programmer, database, design and other jobs as well. I got lots. Which was nice, but things weren’t really narrowed down to the degree that I had hoped for. Still, I hadn’t expected to get a perfect match, since, well, there wasn’t one.

What I had bet both my farms on was that one day, there would be a job, and its title would be User Experience Designer, and its location would be Norwich. When that job came up, if anybody was looking for a candidate, I would be the top of their search list. And that search list would have one name on it. And that name would be mine.

I had to wait a while. I had to do freelance work in London for a while. I had to travel 3 hours, each way, every day, for a while. But one day I got a call from a recruiter. I got lots of calls from recruiters, but this one sounded interesting. They had a user experience designer role. Duh. It was in Norwich. I’m listening. It’s permanent. It meets my criteria. Am I interested?

Have a plan

That call was for the job I’m currently in at Foolproof in Norwich. This job is the only job I want to do in Norwich. It’s a perfect job. And, because I was so busy travelling and sleeping and working, I hadn’t even noticed when they’d put the job posting out. I’d pretty much resigned myself to a London commute, and was actually considering an offer of a permanent user experience role based in Hammersmith. Which would have killed me.

But my bet paid off. When the recruiter searched for ‘user experience designer norwich’, I was indeed top of the list. There are others in the list now, as indeed there are other jobs that have appeared in the last year, but when I really needed it most, my plan was good. Have a plan, people, and stick to it.

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.

Archives
Categories

Share