user experience

Post navigation

I’m writing this post while attending Cognitive Psychology UX Bootcamp. This is an exercise that we’ve been set to do and I’m working with Tara and Jerome of Ribot. This is the incredibly laymans version after half a day of the two day program so don’t take any of this too seriously. If you disagree with any of this, you can take it up with our Bootcamp trainer, Joe Leech:)

Tips we’ve learned so far:

Limit the line length to around 95 characters per line, allow plenty of space between lines, make sure the colour contrast is sufficient and be aware of the impact of colour choice and colour blindness

Aim for a reading age of around 10yrs (using the Flesch-Kincaid readability test), especially if your audience is multitasking

Write using upper and lower case unless you want people to read REALLY SLOWLLY and find all your typos

Don’t put lots of flashing stuff in the peripheral view but also don’t rely on something animating to grab attention in my field of focus

Try to keep hyperlinks on the same line (not broken over two lines), and don’t put too many links off to other pages/sites if you want to keep people focused on your article (hyperlinks create a fixation point and draw attention)

If you want to look smart on your blog, include a photo of yourself that is closely cropped around your face. If you’d rather look less intelligent (and possibly more sexy), include a photo with more of your body in it (Note to self: get new profile photo).

Group similar things together, make use of established/known patterns.

Make sure any buttons are sufficiently large targets (ref: Fitts Law)

Encourage psychologists to do a lot more research about the effects of design on reading on the screen because there seems to be a lot of things we don’t really know for sure.

I was invited to speak at the MonkiGras event this week where getting a little sweary and ranty is kind of encouraged (it goes well with the craft beer consumption that is an integral part of the conference mix). This was my contribution.

When I checked the agenda to see what I was supposed to be talking about at Monkigras, I saw that I was down to talk for 15 mins about ‘Crafting Good UX’. Where to start. I suspect James expected me to come up with something like this post that ReadWriteWeb published the day before my talk: Five Signs of a Great User Experience If you’re interested, the five signs (aside from simply *being* Path), are:

An elegant UI

Being Addictive

A Fast Start

being Seamless, and

It Changes You

I hate these kinds of lists. You look at them and you go – yes, that makes sense doesn’t it. We just need to do those things and we’ll have great UX. Simples.

If only that were true, we’d be overwhelmed by UX amazingness. Instead, here we are, using the same handful of good examples in ever conference talk or article written about User Experience this year.

It’s not that simple right. So, I changed my topic to ‘Why Most UX is Shite’. The audience was people (especially developers) from start ups, open source and enterprise software – I figured this topic would probably resonate with them.

Now, there are plenty of ways you can make a user’s experience of your product rubbish, but in my experience, there are a handful of serial offenders. These are not things you can add to the backlog and bug fix next week, but if you know what they are you can stop wasting time fiddling around with things that, ultimately, don’t matter if you don’t get these other things right.

1. You’re not making decisions (so you force the people who use your product to make them instead)

So, this one I see ALL the time.

From a start up who doesn’t want to rule anything out of its value proposition so doesn’t really know what it is so, as a consequence, no one knows what problems it’s solving so they don’t engage. To open source software that tries to be Rails and WordPress at the same time and is consequently a usability pariah. To a page that is so full of content with no hierarchy, or a form with too many fields, meaning the customer gives up and goes somewhere that makes mores sense.

Decisions like: WHAT A COMPANY STANDS FOR, or WHAT WILL NOT BE IN THIS PRODUCT, WHAT YOU WANT PEOPLE ON THAT PAGE TO DO, or WHAT THE BEST PERMISSIONS SETTING FOR MOST PEOPLE. These decisions don’t get made, and these are reasons that people look elsewhere.

You can’t designs something if you don’t know what it is. If you don’t have constraints or priorities.

Here’s the choice – YOU make your end users choice easier and you’ll have more customers.

This starts at the top. What does your company do and not do. What does your product do and don’t do.

Get a vision already.

These decisions don’t happen because people and companies are too gutless to make them and to potentially be wrong.

From a UX perspective you are BETTER to make them and be wrong and then make a better one based on what you’ve learned than not make them at all. Preferably in testing, BEFORE you inflict it on your paying customers.

In reality tho, most people are much more interested in their own careers – not being wrong and getting a bonus – than they are in really delivering good user experience for their customers.

You can probably get all pedantic on this with me, but but make sure you understand the point I’m trying to make here.

As a designer, there are two sets of people who will influence you: the end users you’re designing for, and the stakeholders who you work with every day, who you want to impress and have a good working relationship with, who will write your performance review and recommend you get a bonus, or not. Who will think you are cool in the open source community or a pain in the ass.

End users who you probably don’t get to see all that often, co workers you see every day.

Which do you think will have most influence?

I would LOVE to believe that all designers are able to put the end users needs ahead of their own personal ego, or their end of year bonus, but, let’s be realists. If you’re my boss and I know what’s going to please you, your opinion is going to be influential. Chances are strong this is not going to lead to your product having better user experience.

If you’re not an end user of the product (really), or your not regularly talking to or observing your end users to understand how to design for them, seriously consider holding your tongue rather than giving your opinion.

3. You don’t measure it (you’ve probably not even defined metrics for ‘good experience’ let alone tried to gather data for it )

You hear talk of the ROI of design every now and then but in reality, Most organisations do very little about trying to measure how well they’re doing in giving their customers or end users a good customer experience.

Most companies have no clue about the acquisition cost or lifetime value of their customers, who their most valuable customers are, what behavioural characteristics map to high value customers. This is because, historically, we do functional accounting rather than customer centric accounting.

Sure, there are lots of challenges in measuring User Experience, making numbers of it, but it’s super important. Your Net Promoter Score is only going to get you so far.

if you REALLY want to craft good UX you need to understand what people are doing and why, how effective your current UX is and what difference an investment in improving it could have. In NUMBERS. because, really, that’s what companies care about.

4. You don’t really care (companies who really care shape their organisations, their accounting systems, their culture around their customers)

This brings us nicely to the nub of the issue. Most companies don’t really care. They pay lip service to UX because everyone has started saying that UX is important and because apps like Path look cool don’t they? We need to look more like that.

Why can no other company do design like Apple despite lots of companies doing their utmost to rip off the iPhone?

Because the iPhone is a symptom of a company that massively cares about the user experience that their customers have with their products. Apple structures the operations of its entire organisation to support the creation of these kinds of products.

This is not new, we know this, right? but how many big corps do you see trying to copy Apple’s organisational structure, or the way they do communications and accountability, or where design sits in the organisation?

Pretty much none. Because there are too many people in cushy management jobs who have no clue how to operate in this new kind of environment and are too pleased with their current set up to make such big changes. And because most companies are too scared of what shareholders would say about making such radical changes that will cost money in the short term to make money in the long term (I give you Apples most recent balance sheet in response to that argument).

At the end of the day, most managers care more about this stuff than they do about UX. End of.

The UI is a symptom of organisational culture – you need to get beneath the skin to craft really, sustainably good UX

There are no Five Simple Steps to making your UX fabulous, there is no simple fix. All of these things are hard and most of them start much higher up in the organisation than the average UX designer ever gets to.

Good UX is cultural. If you want to hire a freelancer to ‘do UX’ , it’s like putting a plaster on gangrenous leg.

Design good organisations so we can design good User Experience

If you want better UX, stop looking at your design team and whichever new sexy UI you’ve seen this week, take a long hard look at your organisation and whether it caring about UX is part of its cultural make up and what evidence there is, beneath the interface, of this being true.

Go design some good organisations so that we User Experience people can make you some properly good UX.

I posted a note on Twitter earlier today about a friend of mine who calls himself (at my suggestion, having worked with him and knowing his skill set and interest) a UX Developer. Several people suggested in response that a UX Developer was not really a thing and that the term was either pigeonholing, unnecessary, redundant or ‘so 1996’.

With respect, I disagree. UX Developers are definitely a thing, and more than that, they’ve become an essential part of my project team mix, especially when I’m working on the UX of an application style system (which is more and more the case).

I’ve been fortunate enough to work with front end developers who have plenty of sensitivity to creating good user experience for as long as I can remember, it makes perfect sense that most front end developers are more interested in UX than those whose work doesn’t touch the UI. These are great front end developers, but, by my definition, they are not UX Developers.

A UX Developer is all of that – a front end developer with a sensitivity and talent for crafting a UI that is going to be better to use – but in addition to that they have a declared interest in understanding more about the User Experience work that goes ahead of the UI design. I doubt many of them would ever be happy doing pure user research, but they’re probably keen as mustard to run some of their own usability tests, guerilla or otherwise. They’d probably go nuts having to do some of the workshops and stakeholder communications that forms a key part of the garden variety UXer’s role, but they want to understand the strategy and customer insight that is driving the bigger picture product decisions.

There are different layers of user experience – these layers sit on a continuum between the pixel and the person.

UXers like me sit further toward the ‘person’ end of the scale, focussed on understanding end users, stakeholders, and what is going to work well for them as a wholistic experience. UX Developers are situated much closer to the pixel. If you’ve met a UX Developer, you will not be surprised to hear them tell stories of videoing a transition in an application so that they could slow it down enough to understand how it was working so they can recreate it. It’s what they do.

UXers like me (and I’m all about Prototyping in Code, I’m just not particularly good or fast at it) work very well with UX Developers. Trying to get the finest details of the UI right is not something that someone with my rudimentary development skills should be doing, and frankly, it’s not where my real strength lies. With a UX Developer on my team, I can involve them in the strategic / research aspects of the project as a second pair of hands, then work with them to create prototypes quickly, moving from sketches direct to code – and really nice feeling code – quickly. Eliminating the need for putting myself or my stakeholders through the wireframing process and being able to iterate on the ‘how it works’ part of the design from almost the very beginning.

The UX Developer, having been involved in the UX process from the beginning of the project, understands the rationale behind the product and design approach and is able to make good, consistent, UX decisions without needing every piece of UI defined. In fact, in my experience, they’ve probably made better design decisions than I would have made… well, sometimes.

Is UX Developer a synonym for interaction designer? Perhaps, except that it makes strong front end development a critical part of the skillset, which I think creates a completely different team dynamic and quality of interaction than an interaction designer who uses prototyping tools like, say, Axure (and there are still plenty of those). If you can’t produce high quality, production quality code, then I don’t think you’re a UX Developer. (Although, you may well be a perfectly competent Interaction Designer ).

How do you work with a UX Developer?

get them involved in the strategic parts of the UX process – defining the product, the audience, the research, all the fun stuff. Let them increase their UX skillset and make sure they understand WHY things are happening the way they are in the project.

sketch together and get prototyping in code as quickly as possible. This is not a senior/junior relationship, this is the dovetailing of compatible skills to get to a better UI, faster.

share ownership of the UX, don’t feel like you have to make all the design decisions, let them own the finer details of the UI and you focus on the bigger things (that are actually pretty hard to stick to when you do get to obsessing about the details on the interface)

allow yourselves to push and pull focus from the strategic ‘person’ level to the pixel level – it is difficult for one person to maintain focus on both ends of the spectrum at the same time – a team like this helps enable this rapid shifting of perspective more effectively.

A UX Developer is not a silver bullet. You can’t work this way on all kinds of projects for all kinds of people, and it can be hard to find a good UX Developer to work with. I’m a freelancer, so I used to travel solo from project to project, but since I’ve started working with UX Developers, I now like to BYO team (where possible) and an essential member of my UX posse is a great UX Developer.

I had the opportunity to attend Drupalcon London this week and to talk some more about the Prairie Initiative – what is is, our goals, and the progress we’ve made so far. Unfortunately the audio in the session recording was very poor, so here’s an outline of what I presented.

Recently I came across a ‘register’ page on a Drupal site that was obviously Drupal (in a bad way). I thought – I wonder what it would be like for people who don’t know anyone in the Drupal community to come to Drupal.org and try to find how they can contribute their time, skills and experience to fixing the design of that page.

Try this exercise – go to Drupal.org homepage and log out. Now imagine you’re here looking to help out in whatever your area of expertise is (if you can’t think of anything, just pretend you want to help fix the usability and layout of that register form). Where would you go?

If you headed into Support and Community (which is probably the most sensible option) you’re hit with walls of text, no keywords that confirm that we want people like you and where you should go. Very little sign of a community at all, basically just a list of channels. It’s less than inspiring and a little intimidating.

IRC is not a solution – it scales badly, it’s intimidating and unfriendly if you’re new and unknown, and for a great swathe of us, it’s very unfamiliar.

Groups – try going there and logging out. This is also a pretty poor introduction to the community for newcomers.

Forums are also pretty haphazard and not really a recommended entry point.

If you decide to ‘register’ (for what, it’s not really clear) you enter a process that is riddled with small but unrelenting errors or bad experiences – from the lack of client side validation on the forms, to the ‘access denied’ heading once you’ve completed the form successfully, to the personality free email you receive (and the fact that we have even designed the sign up process this way – making the user do the work to reduce the spam on Drupal.org presumably)

Having completed the registration process, you’re left pretty much stranded on the final page (which announces that it’s unsubscribed you from a mailing list you’ve never heard of) – the dashboard for newbies doesn’t take advantage of a great opportunity to help you get started. Fortunately, in the journey that I was exploring – search does work, and if you make your way to the Usability Group page (which has been pretty well thought out and structured to be newbie friendly), you’re set – you can actually find some likeminded people and start finding your feet in the community.

These are all little things – things that could reasonably easily be fixed. And some might say that if you can’t handle this then you’re probably no use to us anyway – Drupal gets a whole lots hairier than this! And that’s a fair point – afterall, if you do make it through the onboarding experience, sooner or later you’ll meet the issue queue….*gulp*

The onboarding experience into the Drupal community on Drupal.org is a bit of a car wreck. Sure, it’s just a series of little things that could be relatively easily fixed – that’s not the point. The point is that we either have never bothered to check that the sign up / onboarding experience is any good, or it’s not high on our priority list. No one owns this job. This tells us some interesting things about the Drupal community and sends some messages about what we value:

We don’t really value our newcomers or care about the experience that new people coming to join our community and contribute have when the try to get involved.

We don’t really care about the quality of the products we create and the spaces we reside in (there’s no broken windows policy on Drupal.org), we don’t take pride in our flagship(?) website.

People who do manage to get involved using this process are to be admired for their determination!

There is an alternative onboarding experience – person to person mentoring and hand holding, particularly for those who have been hired by a Drupal shop or are working in an organisation that is adopting Drupal. This is a good process – perhaps it’s the one we really care about? Perhaps we don’t really want people to randomly stumble into the community? Perhaps – these are all questions to think about…

We need to work out what our position on all of this is.

What kind of people do we want to have in our community?

How do we want to ‘recruit’ them – do we want random people coming to the community from our website? (hobbyists etc?)

What kind of an experience do we want it to be to sign up to be a part of Drupal?

What kind of experience do we want to be to be an active contributor to Drupal?

How important is this to us? How much do we care?

It’s ok if we decide we don’t care about it so much. The right answer isn’t necessarily ‘the user experience must be fantastic’ but we should stop paying lip service and actually not doing anything about it, and not committing any resources to it.

We need a vision for what we want the experience of Drupal.org for new and long term contributors to be like.

Backcasting is a great exercise that helps us work out what we’re aiming for and then a roadmap/strategy to work towards that outcome.

For me, I think this is important. I believe that the way our spaces are designed is very influential on the way that we behave within them. Drupal the community and Drupal.org are both pretty good at tactical problem solving, but both pretty rubbish at defining and agreeing and acting on larger strategies.

This is what the Prairie Initiative is interested in – ways that we can design social spaces on Drupal.org that are more conducive to giving new contributors a better onboarding experience and that makes it a better, more productive environment for longer term contributors.

The Prairie Initiative is not a project. Rather, it is a family of projects that share a connection to a common set of goals. The goals of the Prairie Initiative projects are:

to improve the collaboration tools on Drupal.org so that we can do more and work better together and make Drupal better, faster; and

to grow the pool of contributors by making Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing.

Some of the projects within Prairie that we are moving forward with at the moment include:

Topic page – a place where activity from across the Drupal network can be aggregated and people interested in this topic can ‘follow’ the topic. This allows people to self identify their expertise, people to find likeminded peers in the community, people to find mentors, people can more easily keep up with activity on Drupal.org related to their topic.

Profile page – a better designed profile page allowing us to share our expertise and experience and interests and activities within and without of Drupal more easily, and a way to make the reputation system known to ‘insiders’ accessible to those who are new and as yet not well connected to the community.

Issue Queue – exploring ways that we can change the issue page so that it lets us work more effectively together.

Notifications – exploring how we can make it easier to keep up with activity on Drupal.org you’ll probably be interested in without requiring you to be on IRC, have people ping you links, or be scouring issue queues and groups endlessly to keep track.

I’ve been trying to do as much of this as I can in my spare time but – realistically – I’m not a great candidate to help lead this project. It really needs someone who works in a Drupal company and who gets some ‘gardening time’ (or equivalent) to work on community work without having to sacrifice income or time with their kids.

Having asked around a little to see if there might a chance of getting a little financial support so that I can work on this in place of client work, it seems clear that Prairie is currently not a very appealing investment.

I probably need to work on my pitch, I guess, but that’s pretty demotivating. Especially when you not only need someone like me doing cat herding, ‘product management’ and some UX work, but we really also need a tech lead (someone like this who, unfortunately, is much the same as me in terms of having no gardening time).If you’ve got time and inclination to take this on, step up. Otherwise, regretfully, it’s likely Prairie will flounder, as it has for the past month or so after an initial cracking start (this is entirely my fault and not for want of people willing to contribute their time).

I know this sounds like a huge critique of the work that was done by the redesign team and by those who continue to work on Drupal.org – please know that there are many, many things that need working on and people like Neil Drumm and Lisa Rex and others are doing great work that goes largely unrecognised and unthanked. This is absolutely NOT a criticism of their work and I’d like to thank them and the others who are working with them for continuing to incrementally improve Drupal.org.

We might have re-THEMED the entire site but there was a LOT that never had the chance to be reDESIGNED. These are very different things.