How I got found as a user experience designer

July 19, 2011

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.

listening post: the rakes – 22 grand job

There is no user experience design process

June 24, 2011

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

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

Building a design framework

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

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

Framework schramework

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

listening post: u2 – friday muddy friday

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

June 23, 2011

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?

listening post: holy ghost! – say my name

Undefining ourselves: More might be less for user experience design

June 17, 2011

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.

listening post: new order – senses

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

June 9, 2011

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]

listening post: the soft moon – circles

Expose yourself – design workshops in the real world

April 8, 2011

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

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

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

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

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

Lean UX: The UX you wish you were doing

March 2, 2011

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

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

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

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

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

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

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

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

View more presentations from Jeff Gothelf

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

Building theme-based information architectures

January 31, 2011

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

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

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

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

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

inheritance in user experience design

August 2, 2010

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.

listening post: orbital – the box (part 2)

just try everything

July 15, 2010

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

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

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

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

listening post: nothing – I deleted it all

Things what I writ