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.

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.

Usability and the Business Analyst: Smuggling UX at the UK IIBA

There’s a new contraband changing hands in clandestine boardroom exchanges in the most powerful businesses in the land. It doesn’t fall off the back of a lorry, or get swept up on the beach, following the sad demise of some stricken thought tanker, however. No, this new currency is traded under the cover of business analysis. This illicit commodity is user-centred design.

I recently attended an event run by the UK chapter of the International Institute of Business Analysis, hosted at Credit Suisse, in their rather nice offices at Canary Wharf. The event was a panel-based discussion of how user experience and business analysis might gracefully collide, somehow becoming something more than the sum of their parts. Put another way, how does user-centred design affect the business analyst?

The panel

On the panel were erstwhile and engaging practice professionals from both sides of the collision: Cennydd Bowles and Chandra Harrison, with many years in user-centred, experience and interaction design (other design practices are available) and Jake Markham, who built the business analysis and design practise up at Credit Suisse. It was chaired by Nick de Voil, from De Voil Consulting, who conveniently bridged the gap between user experience and business analysis.

Nick Dunlavey of Information Architects, who had invested significant effort in pulling the event together (largely crowdsourced via twitter, incidentally, in case you’re wondering how a meeting of UX and BA professionals in an investment bank gets put together), kicked off proceedings in the plush 7th-floor theatre with an admission. He has been smuggling UX into projects. Appropriately, he’s been using Cennydd’s Undercover User Experience Design book as a reference to do that, and thought it would be a good idea to try and link usability and the business analyst.

To set the context for the discussion, Chandra and Jake took some time to talk about, respectively, what user-centred design and user experience is and where we are with it right now, and the development of the business analysis skills and competencies framework for Credit Suisse.

Understanding user experience

Chandra gave a whistle-stop tour of UX, from its mostly overlooked early development in product design to its subsequent and most recent focus on user satisfaction, via world war one biplanes, personas and skills matrices. She was careful to describe user experience as ‘just a term we use at the moment’ and to be clear that ‘user experience’ is not a profession, but, rather, it simply describes ‘what users experience’. What we really do, as practitioners, is apply user-centred design as an approach to system design that supports those experiences. As it turns out, most of the tools and techniques we use to do that are very similar to the tools and techniques that business analysts use, but, critically, we talk about them in very different ways. It might be rather too simplistic to say that business analysts focus on business and user experience designers focus on users, but it’s definitely the user that is the differentiator. The depth of understanding and appreciation of user behaviours, gained from years of observation and dialogue, is what user experience brings to the business analysis party. And then eats all the canapés.

Business analysis and user experience

Following Chandra, Jake was also keen make an admission before he began his talk. He is also a ‘professional smuggler of user experience’. Since Jake is responsible for defining the activities of the business analysis and design group at a company like Credit Suisse, this is good news indeed. In talking us through his own history at the company, we got an invaluable insight into how a global investment banking business is defining its business analysis function and how closely that may be aligned to user-centred design practices. Ultimately, the business analysis function is about identifying needs, collaborating on requirements and facilitating solutions, but it’s focused clearly on the bottom line for the business and the customer. Conversely, the user-centred design function is about identifying needs, collaborating on requirements and facilitating solutions, but focused clearly on user needs. This means that there are clearly opportunities to embed used-centred methods into the business analyst skills and competencies framework and satisfy goals for business benefits and enhanced user experiences.

As I read the definitions of the four roles that have evolved from Jake’s business analysis taxonomy, I was simply changing the job titles for those we use in user experience and the descriptions were pretty consistent. For Business Architect, read Information Architect and you’re nearly there. In line with a comment Cennydd later made about the demise of specific ‘user experience’ roles, I don’t really see the need for the fifth, UX-specific role Jake suggested they might need. Rather, the user-centred design methods and practices should pervade across all roles.

In the middle of all this, Jake also put up a slide that had some enormous numbers on it that spoke to the scale to which a global investment banking business like Credit Suisse operates, at which point I had to check I was wearing the right glasses.

Questions, answers and opinions

On to the panel session itself, and thanks to a brief introduction by Nick, I think I now know what a lasagne panel is. I can’t imagine why I never knew before.

The debate was eloquent, lively and, with the inclusion of Cennydd, was determined not to just turn out stock answers or platitudes. For the most part, the panel vehemently agreed when questioned on things like the business benefit of usability, quantitative measurement, accommodating user requirements without scope creep (BAs love scope creep), and the perception of user experience design operating exclusively in the digital space, on web and web apps. One of the emerging themes was the business benefit of creating ‘value through change’ rather than working to functional requirements. I can’t say I grasp this concept well enough to say whether I agree or not, but if it means understanding user needs, and designing, possibly disruptively, for that, then I’m all for it.

I’ll be honest, I took more notes when Cennydd spoke than when others did, since he catches the zeitgeist of my profession better than anyone else right now, but I did admire Chandra’s enthusiasm and deliberately wider view of usability and Jake’s measured, literate and erudite responses. However, Nick de Voil probably expressed the relationship between user experience and business analysis best:

User experience practitioners have permission to ask people how they work, operate, and do what they do. This approach has emerged as accepted practice in the last few years and it is this that makes them a powerful ally for business analysts.

As I have spent a number of years as a globalisation manager for a large corporation, I was amused to see that nobody wanted answer a question on globalisation strategy. I think we all know you might as well ask for alchemy on toast. I was also reminded, from previous work with another investment bank, that if someone from a global trading division asks a question, you need to be ready. They are scarily efficient in their questioning and can spot flannel through walls of lead.

If you thought about going to this event because it had ‘UX’ in the title, but didn’t go because it had ‘BA’ in the title, you missed a trick. Both our professions require a broadness of understanding that can only be developed through immersion, discourse and appreciation. Many thanks to Nick Dunlavey, the UK IIBA, Credit Suisse, and, of course, the panellists for a thoroughly enjoyable and enlightening evening.

And there was caviar. You’ll go next time, won’t you?

Undefining ourselves: More might be less for user experience design

As I was reading through Jeff Gothelf’s blog entry on the mythical user experience visual designer unicorn, I thought way too much about the current apparent need for user experience professionals to wear more than one pointy skill hat in order to somehow make themselves that much ‘better’.

In a nutshell (which, by the way, is a cleverly crowbarred reference to my own developer background) it seems to me that the more skills we pursue, the less skills we can practice and develop. Under a rather broad categorisation of ‘user experience’, which I’m not even going to set the boundaries on, because I still don’t know what they are, there are a huge range of techniques, skills, practices and methods that are constantly evolving and shifting in response to needs, innovations and opportunities. We learn, use, modify and generally make our best use of those techniques and skills, to help us solve problems and design solutions that we hope make the world a better, more delightful place. And I think that’s enough to be going on with. At least, in terms of a value proposition for a User Experience Designer.

There is a tendency for us to refer to ‘full-service agencies’ as some kind of 7-fingered, flat-footed cousin and the very idea that they might make a claim to be able to provide user experience expertise is roundly scoffed at. Which seems a contrary position, if we can be quite so pleased with our own ability to write code, build platforms, deliver compelling visual designs and so on, effectively pitching our own ability to full-service clients. If we’re making this shift by design (which, by the way, is a woefully crowbarred reference to my own design background), then the strategy is somewhat grab-bag. User experience design can be a hard sell, but it has a certain purity of intent that can be evangelised. As we seek to extend our reach, that intent becomes less clear.

Maybe we are all just 'designers' after all, but if that's true, I've got loads of profiles to update.

Let them meme cake: Conspicuous connection in the social network.

I’ll be honest. I’m only writing this post because I thought of the title. Now I have to write the content. I know I’m not the only person who does that.

Having said that, the title was borne of an observation that we’re moving/have moved into a new phase of conspicuousness, driven by the desire to belong. This time it’s a curious elitism defined by your connection mass in the social network, but conspicuousness draws on a strange lineage from a mythical Marie Antoinette to many on the net via as much as I can get and mourning those I’ve never met.

Conspicuous consumption

As a device to delineate a social class, as with the conspicuous consumption of the cake-eating French aristocracy, its intention is clear: to define yourself irrespective of others. While not so much about cake, there were clear, if unwritten, rules about the externalisation of wealth and power to demonstrate your status. This was mostly manifest in the construction of elaborate and ornate dwellings and the furnishing of one’s self with much dandyness. However, it also demanded that you were a magnanimously social creature - the burden of lavish party-throwing and fatuous, fabulous benevolence was great - but all these attributes identified you as belonging to that noble, narrow aristoclass, unattainable through mere social climbing and fiercely protected by the bourgeois with their own laws on how to use the dressing-up box.

Conversely, through the industrial revolution of the late 19th century, when the term was first used, and the post-war era of the 1950s, particularly in America, conspicuousness was all about perception of social power and ascending the social strata. Conspicuous consumption here was more about demonstrating accumulation of wealth as a means to describe your social standing, in the process, creating its own social class – the nouveau riche. In contrast to an aristocratic, 6-fingered, birth or marriage right, this was an attainable variation of social climbing, and conspicuousness was part of its tactical implementation. While often attributed to the already wealthy as some kind of vulgar, modern rendition of cake-baiting, it probably more accurately describes the actions of those who can ill-afford the conspicuous investment, but still have that desire to be seen to belong to the class that can.

Conspicuous compassion

In the tail-end of the 20th century, a more emotive form of conspicuousness began to surface, that seemed to suggest a different kind of need: to define yourself to be just like others. Conspicuous compassion was posited by Patrick West, for Civitas, as a kind selfish, ostentatious recreational grief, which was triggered in individuals who had somehow lost their way due to the diminishing social influence of the church. It is suggested that this ‘mourning sickness’ pervades our modern society, because we have need a to show how much we care, without actually wanting to waste our Sunday mornings at church when there’s a sale on at Next. Think flowers on royal hearses and ten-minute silences.

Conspicuous compassion, as described by West, is a mawkish ‘me too’, whereby the collective forms in an extravagant display of ‘grief-lite’. Strangers coalescing to cry over strangers. Make of that what you will, but how they come together is what makes his opinion interesting. It’s the idea that the conspicuousness of the individuals’ emotional response is the qualification for belonging to a particular social group that says ‘I care’.

Conspicuous connection

In contrast, conspicuous connection in the social network says ‘I care’ in a very different way. It satisfies a quite different need: to define yourself to be more popular than others. Conspicuous connection doesn’t necessarily speak of influence, which is a quite different metoogorithm , but it definitely speaks of volume. It says ‘I care that you ‘like’ me’, and it is an evolved ranking system that simultaneously holds no value and means everything.

You could argue, in hindsight, that the volume-driven connection model that was first massively popularised by MySpace was a kind of post-modern ironic, generation Y in-joke, as the friend numbers passed from ridiculous to sublime and back again. There was no real connection in MySpace. I was more like stumbling into the biggest teenage house party in the world. There wasn’t really any social collateral in the numbers, it was just a bit of a laugh. Friends were added, rather than tactically coveted.

As Facebook really told hold, rubbing MySpace’s face in the corporate sand and as Twitter appeared as the curious IM/blog hybrid it was ok to admit to, then conversion tactics really emerged. Driven by the inflation and recommendation model of the herd and the revenue from ads for baldness remedies and weight loss (is that just me?), marketing strategies developed to maximise, monetise and commoditise the network. One of the primary strategies was volume. And that is why conspicuous connection is so prevalent.

Conspicuous connection is the manifestation of the desire to be seen to be a social prime mover. Influence is hard to measure. Numbers describe a kind of brute-force reach. Consequently, the larger the numbers, in theory, the further the reach. Which is why elementary volume tactics, developed by gurus, used by the rest of us, account for a sizeable proportion of content itself. Following, liking and connecting, is what creates your social mass. In some cases, the mass is so large it creates its own social gravity, sucking in the rest of us. It’s this planetary tipping point that completely alters perception of influence, and so the very act of asking other to get you there is now an acceptable strategy.

It just doesn’t appeal to me. But then, you’re probably not reading this.

Writing to be read: A workshop on being a better writer

Martin Belam and Cennydd Bowles have written popular and successful books, articles and blogs on user experience. On Tuesday evening, I attended a writing workshop, where they shared tips, tricks and best practise for ‘better writing’.

I write too much. When I write about an event, I fill the page with clever, but meaningless sentences. Seeing the details of the workshop, I thought it would be a great way to learn from others and share opinions on what makes a better writer. It ended up being all that and more. It was an insight into methods and practices that Martin and Cennydd use in their own writing, highlighting that personal approaches to writing differ, but common creative techniques and some rigorous editing can nearly always improve output.

First off, Martin shared some of the tactical armoury he has developed through his own writing. He focused on tips and tricks for writing to be read and was able to provide some excellent examples of the dramatic impact simple devices can have. Some of his advice was common sense, while some was quite crafty. Some was plainly evil, but, nonetheless, common practice, when writing with particular targets in mind.

Cennydd, on the other hand, wanted to help us understand that after writing, the real work starts. Editing your content is just as important as writing it. Through a series of classic examples and anecdotes from his own experience, he gave practical advice on analysing and improving your own writing, through careful, considered editing. In common with Martin, Cennydd also was keen to make the most important point of all: if you can’t speel, please don’t write, especially if your grammar do suck.

It was thoroughly enjoyable evening, with practical, actionable advice. Clearly, there is no one ‘right way’ to become a better writer, but if you can learn from others’ experiences, you can, at least, take steps in a better direction.

[This post is an edit of the previous post ‘This title is clever but pointless and inefficient’. It is an attempt to put some of the learning from the writing workshop into practice and so it’s not a great post, more of an exercise. If you prefer one or the other, leave a comment. You might not like either of them, which is more likely]

This title is clever but pointless and inefficient

This is the post I would normally write about being at an event in the city with a collection of like-minded individuals who were compelled to attend to on the promise of solace at their smiting of writing with encouraging words from the scribers of note that can say what they wrote with articulate summary, a sprinkling of chummery and, not least some encouragement, wrapped up in wit, delivered in earnest, with meaning, to whit, I give you a paragraph to be used as example, to print and to squint at in lieu of a sample of how you could simply just dribble away like a gibbering goon for the rest of the day.

Except, I now know better.

This evening I attended a workshop run by Martin Belam and Cennydd Bowles, which, ostensibly, was about being a better writer. That sounds like a rather lofty and grandiose concept, but, you know, I like those. Realistically, the workshop was more about personal approaches to writing, learned writing skills, need-to-know and evil-to-use devices for being read, and a heavy dose of editing. Oh, and spelling. And grammar. Which, I plainly flout irreverently and irreconcilably and even irresponsibly. In fact, there were so many golden nuggets of ‘better writing’ advice that I didn’t even have time to flippantly flap about it on the twitter.

Not really knowing what to expect from the evening, I did approach it with an open mind, and an open bottle of Corona. I was hoping that I might get some opinions other than my own on what might constitute good writing and take those opinions away to inform my future output. I did get that, but I also got a rather delightful insight into the methods and practices of two writers that I rather admire. If were to make some dubious football analogy at this point, which I am going to, I’d suggest that Martin’s approach was that of a wily, crafty, tactical midfield genius, who has a great eye for an opportunity, knows all the tricks and can pick out the killer pass most of the time. He’s always the first man to be picked, notwithstanding his occasional tendency to argue the toss with the gaffer over formations. On the other hand, Cennydd would be more of a silky, clinical, methodical kind of player. While apparently effortless in his command of the ball and organising the team (for he does wear the armband), he will be the one on the training ground under the floodlights at 2a.m., repeatedly kicking a ball at a wall until he can predictably hit the same brick every time.

All of which is just a way to say that when describing how to be a better writer, you necessarily end up describing what you’ve done to try and be a better writer yourself, and this will be different depending on who you are. Martin and Cennydd described quite different experiences and approaches, but they shared a common aim. Clearly, there is no right way to become a better writer, there are many right ways. However, what this evening demonstrated is that if you want to focus on a few of the many, some of those right ways are more righterer than others.

Tomorrow, as an exercise, I shall mostly editing the life out of this post before publishing it again. It will be like harvesting antimatter with a sock.

overloading my function

since waking up in a real job where I do proper work and stuff, I've been spending less and less time expounding on such hot topics as situational awareness or pressing buttons in a manic fit and when I have managed to construct a few over-long run-on sentences, I've mostly been doing it for my current employer who has kindly let me do so in between the other bits of time when I'm actually doing the work. which is to say, I've not been writing here for a while. which is fine, because I've been busy, and I've been expressing my ideas and thoughts somewhere else.

now I've settled into some kind of cadence with regard to writing, and since the blog I write for my employer is a shared blog, and there's any number of brilliant minds there who can contribute, I'm currently compiling drafts of thoughts of ideas that will never get published unless I funnel them into an appropriate bucket, which is where this am is, right here. so that what I shall be doing.

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.

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.

joking aside

I rather like using real-world, but made up, examples in prototypes, wireframes, mockups and other user experience bit and pieces. I think it provides a reviewer with a content familiarity that means they are not distracted by confusing 'Sample 1, Sample 2, Lorem Ipsum 7' style placeholders. I mean, are those labels important, or is a reviewer expected to try and read a bit of Latin to get some context around the content blocks I've scattered around? Much easier to use a few scannable labels and text areas to allow a reviewer to filter and forget, rather than expect them to somehow instinctively understand that the drop-down list of 'Attribute 1' to 'Attribute x' that you've presented them with is just to suggest an interaction style and that the data isn't important. Just ignore the data. No, it isn't actually going to say 'Attibute 1', that's a placeholder. Well, it will probably be 'Edit', or 'View' or something. Look, we're getting away from the purpose of this review. etc.

However, there is another reason to use real-world, but made up examples, which is not directly out of the usability engineering manual. Its where you put the jokes. That's not to say the placeholder text for the latest portal home page prototype for your financial services client should start with 'There was an Englishman, an Irishman and a Scotsman...', but there is a little bit of me that wants to leave the occasional blipjoke lying around for anyone determined enough to look at the 3pt type in the sub menu of the fly-out on page 17. Its a bit like that bloke in Blade Runner leaving a little origami joke in a abandoned lift shaft. It doesn't matter if you miss it, but there's a nice little subtext to be discovered if you want to.

It goes back to my final year usability engineering presentation at university which included that Framemaker clip art of people with no faces, and all I could think of doing to lift the tedium of my Jakob Nielsen thesis was to add a speech bubble which said 'I've got no face'. At that point in the presentation proper, I left it unreferenced, projected on the wall, as I wittered on about interaction models for process management application interfaces on UNIX, and I saw the sideways glances to each other of my tutors and the slight curl of their 'snapped to geometry' mouths and I knew they'd discovered it. They sat so far forward in their chairs from that point on that I could see the labels in the necks of their C&A shirts. I knew I'd got a first.

Actually, I cocked up my computing maths module, so I only got a 2:1, but hey, who asks about your degree once you've finished it? Anyway, back to the jokes, for this morning I came across a rather nice one, which prompted me to blurt all this nonsense. If you take a look at the Thunderbird 3 Features page, there's a little example image of what those evil phishermen get up to and how Thunderbird protects you from it. What I rather like about the example is who its protecting you from. Correct me if I'm wrong, but someone had a little smirk putting that example together.

wireframe storyboards

someone told me the other day, well, it was Chris actually, that they liked the wirefames I was working on because they told a good story. they're not the actual words he used, it was much more thoughful and pondering on the back foot than that, but that was the gist of it. either way, that comment resonated with me, if I allowed to use a word like resonate, or resonated, because it captured the essence of what the wireframes were about. I've produced wireframes many times in the past that do just describe the physical location of application elements and the specific interactions that are required to be supported. you know, like, 'this button can only have 2 words in it, it is next to the other button, and when a user presses it, the four horsemen of the apocalypse gallop over he horizon, which we will probably implement using AJAX'. that kind of thing. my preference, however, is to develop wireframes that do that, to a lesser extent, but are much more like storyboards that describe a sequence of events in a way that can be easily visualised. now, I'm not talking about a set of images that describes Avatar 2 - All Your Trees Are Belong To Us, but the storyboard metaphor works at a much simpler level where I can walk stakeholders through a visualisation of the key interactions, including detailed UI elements, that, I think, makes understanding the interactions and changes in state much easier to grok, if I'm allowed to say grok, which I just did, kind of out loud. they're closer to design comics than wireframes, except they have wireframes in them. but with speech bubbles.

it doesn't work for everyone. I'll work on these with interface designers and application developers who will undoubtedly need to understand exactly how I anticipated that left-hand tab device working when it appears, in my wireframes, to overlap the chrome, or something, and 'wanted a wireframe, not a bloody AHA video', but hopefully, providing the context within which the interface elements sit and the describing their interaction through the storyboards, it all makes more sense than just presenting a page with a static diagram on it and saying 'build that please'. I'll soon see.

android user experience

see what I did there? no? it doesn't matter, you're not even reading this.

since I've recently twisted my own arm into spending more than 2 quid a week on my mobile phone, which was actually 2 quid a week on a sim card which was hoofed into a handset from 1999 running symbian s60 which I didn't like when I was using it and like even less now that I'm not, I've been wondering how I might somehow get into experience design for mobile platforms. I've been designing for web and web-based channels for donkey's years and more recently working on complex applications for trading platforms, but I've not really delved deeply into mobile as yet, other than the wap sites we pushed out for Sun Microsystems many years ago which amounted to 17 links in 5 languages that didn't really go anywhere, but we did make the logo really much smaller than we were supposed to, which, in itself, was a triumph of vectors and transparency.

a few weeks ago, I was interviewing for a user experience design position with Qualcomm, which was to be working on their next-generation mobile platforms alongside and incorporating brew, plaza and lots of other nice things that you rarely see in carphone warehouse, but that position went the way of many other full-time permanent user experience positions. that's to say it didn't go anywhere at all. I was phoned before the second interview to say that the position had somehow vapourised internally by law of the corporation and that they were very sorry but it just doesn't exist now so you can't do it. despite it not coming to anything it did at least pique my interest, since I did my usual copious research on the subject in order to perform well at the interview I didn't end up doing.

what has piqued me even more, if there are levels of pique, is that when I started my current position at Tobias and Tobias, working for financial services clients in the city, was the fact that not only does almost every single person on the train, on the tube, walking down old broad street or sat in bishopsgate, own, and is permanently conjoined with a smartphone of some descrption, they own, and are often conjoined with a smartphone of some other description. at the same time. and three on the go is not as uncommon as you might imagine, or at least I imagined. for at least 70% of these people, bleating into an iphone is their preferred interaction, for which the pied piper of hand things is undoubtedly most pleased, but other smartphones are available. you know that. right? and with all these smartphone appendages dangling in front of me, I feel like I'm missing a trick if I don't get some kind of experience designing for those platforms.

now I'm one of those people doing the train, tube, hammersmith, broad street, bishopsgate, liverpool street, tesco thing, I thought I really should get some kind of proper phone which lets me monitor trades on an AMOLED screen or something. or at least doesn't hang for a full minute when I send a text. since I also have a tendency to avoid technology trends (meaning, usually, I can't afford to be an early adopter), I had, a long time ago, discounted an iphone. actually, I like iphones, but anything that requires me to use bloody itunes just doesn't make it onto any list I have. apart from the list of things I won't buy that I have. and, since I'm already a google person, I was already looking for a phone built around a mobile platform that integrates all my googlist activities which of course is the moble platform that google make. it was really just a question of handsets and platform versions. which, granted, isn't an insignificant consideration. suffice to say, after I'd bought a pile of 'what mobile' magazines the size of a small child and reviewed acres of adverts with the occasional technology blog in the middle, I'd determined that the HTC Desire with Android 2.1 was the very thing. which it is.

I really rather like Android. I really rather like HTC's Sense UI, although it really doesn't do an awful lot after you've worked out you don't need to flip between 7 home screens that often. and I really rather like the Desire, even though its a bit, well, brown. all three together, notwithstanding the usual caveats around battery life, seem to support an all-round user experience that suits the way I want and need to use my smartphone to do the things I bought it for. my most basic requirement was for excellent support for multiple email accounts that exist on multiple servers. I was also looking for excellent social network integration. I was also looking for excellent clocks. truth is, limited as the Android apps store is, there's just enough there to enhance the user experience by one or two degrees. mind you, the apps bundled in 2.1 and the google support built-in, means that I'm pretty well set up without needing to go anywhere near the app store. unless I want better clocks. for which there is probably an app. called 'better clocks'.

in a nutshell, which is kind of what my new phone reminds me of, first impressions of the Android user experience on the HTC Desire are very favourable. I've had a week to do the thing where you turn everything on and then turn everything off again. I've tried all combinations of widgets, programs and shortcuts. and turned them all off again. I been through every single setting screen and religiously observed the state and behavioural changes that occur as a result and determined whether I like those changes. I've settled on a default configuration for everything. I've installed the advanced task manager to kill everything I've left running, because, excellent as multitasking is and nice as it is to have updates and notifications going of all over the place all the time, is does rather reduce the usable uptime.

next step is to work out how I might begin to design and build something that runs on my own phone, just to go through the development process. with all that spare time I have. I'm writing this on the train you know. and my tea's gone cold.

wireframe data for situational awareness

if that title means anything at all. I'm quite pleased with it, but I suspect I just completely made it up, but then I suspect Jakob Nielsen completely makes things up sometimes.

as I'm constructing multi-state wireframes for a client, we're uncovering all sorts of user expectations that we simply hadn't considered when we started. which is nice. we also uncovering lots of interaction issues that we didn't know we'd have because we didn't really know what components we'd be using. which is also nice. more interestingly, we're finding that we're discovering some assumptions about behaviours are not correct and that is being uncovered by the made-up data I'm cramming into the wireframes to illustrate real-life scenarios.

in previous wireframe specifications I've completely abstracted the data into 'item 1', 'attribute 1', 'attribute 2' and 'metadata x' type labels, which do make your wireframes very neat, which I do rather like, but don't adequately convey to the client just what they might expect to see at a particular component or object level, in a particular state. I don't know all the data attributes in a complex trading system, of which there probably thousands, but I do know at least the highest few levels of the taxonomy that enable me to make reasonable assumptions about what is a meaningful and relevant set of data for a given object in a given state. so I'm throwing a few of them into the wireframes to illustrate state changes and assess user expectations.

while I was thinking this would be useful to demonstrate real-life application states, I was really using it as a device to increase the comfort level of the clients, by enabling them to make the subtle change in situational awareness from abstract to operational, which sounds like a grand statement, because it is. I tried to make it sound more like a joke, but I couldn't work out how do do that and still make the point, which I'm now veering from. what it actually uncovered is that the assumption I'd made about some of the metadata that might be attached to a particular item was, in fact, not quite correct. that's not to say it wasn't correct metadata, it just wasn't the metadata that users would actually find as useful as other metadata. which is fine. that's why I sit with the clients and clarify their expectations. but the net result is much more than just me going back over 17 pages of visio layers and multi-clicking into shape groups to select the attribute text.

the subtle difference in the choice of metadata that is meaningful at that particular state of a particular application panel didn't just change the label, it changed the whole focus of a subset of user interactions. what we had assumed might be a focus on creation date of an object, was actually much more about the distribution of that object, meaning that we're not tracking the object by time, but tracking it by recipient. its not when, its who. and when that change is extrapolated across functional areas such an entry points to searches, reporting, and at a more granular level, iconography and semantics around context and labelling, it changes much more than just shape 97.

so its as well that I used that real data, even if I just made it up. 'attribute 1' just wouldn't have prompted the discussion. I mean, I'd be finished by now, but we'd be building something inherently broken. like my computer. which is a different story.

hidden complexities

well, they're not very well hidden. I mean, you can't hide things you haven't defined yet.

I'm currently developing wireframes for UI specification based on user activity flows for applications for a client in financial services which is a sentence a bit more complex than I had anticipated when I started typing it even though I suspected there were elements to it that I hadn't even realised might be necessary in order to provide context that might make it rather more full-featured than the initial scope I had in my head. which goes some way to providing a metaphor for the user experience design conundrum I'm facing, if, in fact, a conundrum can be faced. its not an unusual problem. I'm designing a solution for a problem that can't quite be fully articulated. as I iterate on user interaction descriptions and map out user action flows and try to develop wireframes that support those interactions that can be translated into functional requirements for application development, its clear that the initial, narrow scope for must-have features for go-live of version-one don't tell nearly enough of the story to enable me to successfully capture all the core interactions, let alone the extended feature set that adds the value to applications that might actually convince the business that they really should use it thereby making all this effort worth making.

and this is a complex environment. it is a number of degrees more complex than most web-based, rich internet applications. as a single application that is part of a broader application framework that supports a wide range of trading activities, it is actually a quite small, discrete deliverable, but even that small, discrete deliverable, in the operating environment in which is is embedded, has an interaction model that is as big as you feel the need to define. you could easily take a number of weeks or months refining the activity flows, building scenarios, iterating wireframes and doing all those things you do to try and ensure that the user experience is as engaging and intuitive as is humanly or machinely possible and still, on each iteration, and at every review meeting, you'll find that there is another enormous chunk of user operations that you didn't know about yesterday and that chunk begets another chunk and that other chunk requires an altogether different contextual description to enable you to understand its operation and how the user interaction model might need to be considered if, indeed, we are to include this chunk you've just told me about in the initial release, which we are, because we actually want it all now.

but this isn't a bad problem. this is a good problem. as a user experience practitioner, the reason I do what I do is that I like to solve problems and provide elegant solutions. what I don't like to do is take somebody else's solution and just draw boxes and arrows around it. in this case, I get a complex problem and I'm asked to provide a simple solution - an excellent user experience - and how I solve it is up to me. perfect. I'm travelling more than five hours a do to do it, and they want it yesterday, but, really, minor irritations when to put them on the balance against job satisfaction.

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?

gainful

as in employment. I've recently started working for Tobias and Tobias in London doing lots of nice user experience work for some rather nice clients in the city and its a rather nice change from just looking for work in London doing lots of nice user experience work for rather nice clients in the city.

its a significant change from the working environment I have been used to for the last few years, in terms of office space (there is some), project management (there is some) and stakeholder relations (there are some), but the core requirements of the role are essentially the same, that is, to understand the business requirements and define the user experience that supports and encourages engagement, streamlines interaction, and drives business growth, oh yes. and gets it finished by last thursday. based on the changes we just made to the requirements. in the meeting you weren't at.

that last bit was a joke. I was at the meeting.