Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Designing better user experiences (it's your job)

by Frances Berriman on Jun 14, 2012

2,689 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

File a copyright complaint

3 Embeds 54

http://lanyrd.com	47
http://www.linkedin.com	4
https://twitter.com	3

Statistics

Likes: 5
Downloads: 1
Comments: 0
Embed Views: 54
Views on SlideShare: 2,635
Total Views: 2,689

\n
Hello, I’m Frances. And as I’ve just received the crown for palest person currently in the state of texas, I’m obviously from England, and I live in London.\n\n\n
I did my national service, the first time, as all web developers in London seem to, at the BBC \nNotably Javascript Library, Glow with smart folks like...\nSome of you may know me from mfs community\n
I work for the cabinet office, in the UK government - in-house, not as a contractor, in a new department known as the GDS. First thing we’ve been doing is what we call “GOV.UK”, which is a single domain project to unify the government’s digital services under one URL. A Digital first strategy, built in a sane way to save money at the same time as making people’s lives better.\n
So, although I write Javascript and this is a Javascript conference, I’m here to talk about user experience - ultimately, because from my own experiences with successful projects, particularly within the government digital service, it’s become clear to me that unless you put UX first, your product does badly. In fact, if UX isn’t front of mind, I’m not really sure what we’re all doing. It’s just so fundamental.\n
I always assumed that over time I’d become more specialised. In fact, I think that’s something I actively sought after. I thought it would make me better. \nI’ve worked in big places, like the BBC, that encourage specialism, that actively segregate their content folk, from the designers, from the guys on the client-side from their backend devs. \nAs i’ve moved out of that sort of env, I think I’ve become more generalised, but I am a believer in specialisms. \nThere’s always going to be one thing you like better or can do better than everyone else on your team, and that’s your specialism and that’s where you do all the great work understanding the very best way to be doing that particular thing you do with whatever the new shiny is that week, \nbut I come with a warning: actively ignoring all the roles around you is a sure fire way to ensure you’re going to make a crappy product. \n
So, I see a lot of people in the industry who call themselves “UX specialist” or “UX designer” or some version of that - and I’m sure there’s a few people in the room now who go by those titles. I’m going to say some things that suggest calling yourself that is unwise. Just to be clear before you get angry - I’m not saying it’s bad per say and I’m not up here to get lynched - I’m here to be on your side and get the rest of your team to pick up their slack. In fact, I think it’s a good sign - the industry at large has acknowledged that a good user experience is not only desirable, it’s required, so much so that we’re going to assign an individual on the team to make sure it happens.\n
But UX shouldn’t just be a specialism - we should all know what a good UX is, more so than say a UX guy needs to know about JS. And I’d say, most simply, it’s making a site that works well for the needs of the users you’re providing a service to. but with that, a good user experience is the cumulative effect of everyone on the team doing their best work. One weak link, and the experience for your users suffer - whether that’s a slow response time from your servers or a banner image that makes your retinas bleed, or text that’s impenetrable. I’m sort of sick of saying “UX”. The more I say it, the less it makes sense and starts to make me feel a bit ill. If we’re not all making websites that work well for our user base, what exactly *are* we doing? \n
So, my problem with the title “UX designer”, or shooing it away as one person’s responsibility, is that it comes with a risk, is you’re letting everyone else on the team off the hook for their part in making an experience great. I’m fed up of seeing user experience being lumped in with visual design and only seeing talks on it at design conferences. And I don’t think that’s right. I’m pretty fed up of being introduced to people who claim to “just make things pretty” or “just do...” X. I don’t care if you only write Javascript - UX is your problem too. A user experience, of some kind, is fundamentally what you’re doing all day. “Good UX” doesn’t exist, only “Good”.\n
So, I’m not a UX designer. I’m a maker and I lean on the people around me to do their best work and together we try and make great things, but we can only do that if we all understand fundamentally what the overall user experience goals are.\nI’m just going to go through some of the practical ways that groups of developers and designers can get on the same page and make lovely, useful, products.\n
Products are a team sport\nAs a cross-discipline team, at GDS, which included traditional visual designers, front-end developers, back-end devs, project managers and owners, as well as content creators, we - that’s the royal we of the UK government - came up with 10 principles that came from how we went about designing the single domain project - with the idea being that in future, others can adopt these principles. \n
The principle behind the principles, if you catch my drift, was that we’d never recommend anything we hadn’t actually tried and tested, so we know they work, nor would they be a set of rules to lord over a group - we wanted them to be a set of guidelines that people would be actively excited by and want to aspire to - more carrot, less stick, more do, less don’t. \n
A ton of common sense.\n
The fascinating thing about common sense is everyone thinks they have it, but very few seem to act upon it. We found that talking to other groups of people trying to build digital services that although they can see how the advice we give is useful and practical, they fail to follow through. And we’re not the first to notice this effect. A paper by IBM written in 1985 (1985!) on this very topic, asked designers about what they thought made good products.\nDesigners agreed that the 3 design principles from IBM were very good, and common sense,\nPreviously asked - only 2% could name methods for building good products that in any way matched against apparently “common sense” principles.\n
One of the other findings from IBM, which closely matches our experience, is products only succeed when product teams are enabled to worked together.\nIntegrated teams make everyone more accountable and accountability improves quality.\n
I mention this research, and our own motivations, to urge you to consider how much good advice you actually act on and to think about these principles and how they apply to what you specifically do day to day.\n
So, these are our principles - they’re designed to apply to any discipline.\n
This is the most important one. By needs I mean what Tiffany Conroy at Front-trends recently referred to as “goals” in her excellent piece “Design processes, not interfaces” \n
And goals are simply: what is the user trying to achieve. GDS: What are their needs?\n
We were lucky - we had a crap ton of information to start with, from the site we were replacing. We kinda had a feeling for what the ‘needs’ might be. We spent a lot of time doing card sorts to identify what needs the original site covered and what new ones we may need, and which were superfluous or duplicates. However, we built an entire system just to handle the needs, to more easily be able to track which were correctly covered in the new system.\n\n\n
And from this initial process of identifying what our users are actually trying to get done we can start asking questions. Are they trying to pay their taxes? Do they want to play your game? Are they trying to order a book? In our case, they were mostly around finding information - my favourite one being this - What do I do if I find a whale, and it’s dead? \n
It turns out it’s “Call the natural history museum” in London! That’s an actual need. Turns out living on a tiny island still gives you a lot of coastline for things to wash up on.\n
I don’t mean the obvious: stop working weekends. Go outside, you freaks. I mean, focus your user journeys, take away things that don’t matter. You might really really care about the fancy fade effect of the drop-downs when someone mouses over them, but I guarantee, most of your users do not give a monkey’s. If it’s distracting from the goal, get rid of it. \n
I think the most well-known success story of the “do less” mantra is probably still flickr - they got it from day one. The primary focus is the photography - let’s make it shine. Gallery walls are white for a really good reason, and even though Yahoo seems destined to squash them, their iterations to this day continue to be drawing focus to the images and hiding away interactions with good use of JavaScript for menus and such.\n
And it doesn’t just go for visuals - it goes for your content. The specific application of the Do Less rule for our government work was “The Government should only do what the government can do”, which is a tongue-twister way to say “leave it to the experts”\n
My favourite was probably our old winter advice page - the government recommended that you dress more warmly. Essentially, put on a jumper! Really? That’s the sort of advice that the government is not supposed to be handing out, I hope they have more important things to be thinking about - that particular buck stopped with you mother. As such, the new site got rid of that and some other information that other sites, people and organisations offer more expert, complete advice on. It did less by focussing on what it should be offering.\n
Science is on your side. Embrace analytics and find out every last drop of information about how your services is performing and use that to make your decisions. Brand new and don’t have any data? Ask questions, gather feedback on the idea, get something out there as soon as possible so you can start working out how to shape the concept.\n\nhalf\n
We use google analytics, of course, but we also spend significant periods of time in user testing - either formal, organised testing, or guerilla testing with whoever we can get our hands on. The latter actually tends to be more interesting - we meet people in libraries, for example, using the internet for the first time. I’m a real people watcher, so If you’re okay with looking a bit creepy, hang out somewhere with lots of the public using the internet, like an apple store (as if you don’t already) - you’ll get to see lots of people using computers they don’t have at home a lot. You might be surprised how they use peripherals and applications.\nJolt out of comfort zone. Don’t be too weird about it. don’t tell them i sent yuo.\n
This very much builds up on principle 2 of doing less - but goes on to include taking the complexity out wherever we can for the user. It’s simple things like not clearing a form when a user makes a mistake on submission, maintaining state, to taking people through complex applications and purchases. If they’re giving you money, for example, making it really bloody easy.\n
A great quote that applies both here and with doing less: \n"Simplicity is not the absence of clutter, that's a consequence of\nsimplicity. Simplicity is somehow essentially describing the purpose\nand place of an object and product. The absence of clutter is just a\nclutter-free product. That's not simple. The quest for simplicity has\nto pervade every part of the process. It really is fundamental."\n\nA quote from Jonathan Ive a couple of weeks ago in the telegraph summarises.\n\nhttp://www.telegraph.co.uk/technology/apple/9283706/Jonathan-Ive-interview-simplicity-isnt-simple.html\n
I’m probably talking to a room of people that already get the launch early principle - but it can still be a hard sell for many of your colleagues. The designer won’t let the site go out until he’s told you how many pixels he wants you to nudge the logo in by, and the boss wants to sign it off in triplicate. It’s a pain and it doesn’t have to be like that. You will *never* know if the site works until it’s out there and that’s your main selling point. If you can give everyone access to the analytics, because you’ve done principle 3 of designing with data, they’ll be more likely to want to change things to see how that affects the graphs. \n
We start by building a minimum viable product. It will achieve the basic aspects of whatever we’re trying to create, get it out to the rest of the team and if possible real users, and iterate from that. We often throw away 2 or 3 minimum viable products before we’re able to settle on a solution that we develop. As soon as we consider it usable enough to be labelled “alpha”, it goes out into the wild.\n\n
Accessibility. For some reason, it continues to be the unglamorous end of business, and unfairly so, given how fundamental it is to what we do. That we all still treat it as an added extra or a ‘nice to have’ seems insane. Assume from day 1 that your service will be accessible, both in terms of the range of users that your thing’ll be used by, and the huge variety of devices that it could be used on, and you’re gravy. “Accessible” sites tend to work better for *everyone*. They’re inclusive, not merely patched for a perceived minority. This is definitely not optional, people.\n
And this isn’t nampy be nice stuff - Do you think you are to think your users are only people like you, with the best technology? You need to be doing right by all of your users, particularly if you’re providing access to information or you’re trying to sell a thing. At the very least, both the US and the UK expect you to comply with disability legislation. Having said that, although we “comply” with WCAG, we rarely reference it. It’s been our experience that many of the guidelines are based on academic ideals rather than actual user research, and as such, we tend to go with our instincts and results and ignore guidelines that don’t work. That’s okay. Pragmatism is the aim of the game, and you’ll never know for sure if it works until you get some people on the site.\n
Context means a couple of different things in this principle - both about how you work, and what you produce. \n
I’ve spent the entirety of my career battling against the mini-waterfall models that seem to occur within the smaller disciplines - we say we’re agile, and we’re iterating, but the designers still chuck photoshop files over the wall after they’ve been signed off. The BBC, in particular, was very much of that nature. These little waterfalls are very much like factory production floors- something turns up on the conveyor belt that you have to buckle together, but you can’t see the bigger picture. Anyone on your team should know what they’re working on and why, from the user’s perspective. So, the waterfalls need to stop, and a really good way to prevent it is to tool up the designers to work in the medium they’re targeting - the browser.\n
Divya has an excellent talk at the moment full of resources, but the bare bones of this is that you need to understand your medium. Photoshop and the ilk are design tools for print mediums that in no way fully hope to explain the complex interactions that occur on most websites, nor can they hope to represent every device and context the site is likely to appear on. Design for the web is fluid, and it needs fluid tools to explain that.\n
We’ve made moves to help those that aren’t as tech-savvy to get into making sites quickly, in the browser, by building up a little prototyping suite - powered by jekyll and published to heroku. It gives a really simple, light-weight way of building something that looks and feels on-brand, with the main shared assets etc. All of our designers can wrangle CSS and HTML as a minimum, even if not to production standards.\n
Three questions you should ask yourself about context. How - device, responsive design. It’s less about making something work on a mobile, let’s be honest, your site probably already does - but more, what should I do differently, other than layout, on a different device? Think more responsive context switching. \n\n
It’s the kind of thing you can have a lot of fun with, from having a conference website that behaves differently throughout the day. Imagine my delight at 8am this morning, logging on to the TXJS website and finding it’s time context aware and scrolls you down to the next thing on the schedule (and that I was late). Way to go. \n
to an example from gov.uk - one of our most popular pages is when is the next bank holiday? Normally, we very clearly show the next one - but visit on the day of a holiday, and it’ll show you it’s today with a little bit of bunting flare. This is something the hotel industry calls a “delighter” - returning to something you know well, and finding a nice, little, surprise to lighten your day. And this attaches itself nicely to the next principle.\n
Because you’re building a larger service that goes out into the real world. As the internet becomes less a thing you go and interact with, and more the pervasive constant companion, coming to you from your computer, laptop, phone, watch.. microwave.. we’re not designing websites anymore, we’re designing digital services, with the website being just one sliver of the service we’re providing.\n
I hate to break it to you, but your site probably isn’t the destination. Your users didn’t come there because they really like your logo - they’re doing something as part of their day. Pay a bill, have a conversation, discover a new band - their journey may begin with a search engine, but end with a visit to a physical location. You’re enabling them to do something more than your site provides, in some way, most of the time. The more you can do to seamlessly move your users experience from one context to another, the happier they’ll be.\n
What this essentially comes down to is what is the point of a brand? Generally, it’s to build up loyalty and recognition and with that a level of safety and security. Beyond that, your brand guidelines should never stand in the way of building the most accessible site you can. You’ll obviously develop design patterns along the way, and they’ll be flavoured with the overall ethos of your site - for example: twitter bootstrap is designed to be very general purpose, but still feels twitterish, right?\n
You want consistency only in the bits that matter - buttons should appear in expected places, navigation consistent and explanatory. You don’t have to be a slave to a single layout - build something that works well for the specific task at hand. For us at the Government, this has meant building a suite of sites that are recognisably a family - thus building up the trust we require, but tailoring individually for different audiences and services.\n
That goes for internal as well as external. Have mailing lists for your teams, but make it so anyone can join them, whether they’re on that team or not. We use Google Groups for this, so anyone can voyeuristically take a look at what we’re up to. Private lists for group disciplines tends to breed private attitudes. Similarly, whatever you can put in the public domain for your peers to see, get out there. We’ve switched to GitHub, with all public repos except in a couple of small exceptions where we have sensitive information that we can’t out out yet. We accept pull requests and don’t want to wait for the FOI requests - it’s already there. Just do the nice thing!\n
And that’s really why I’m here at all. Sharing the common sense rules and getting everyone on board with really committing to having their whole team involved with making great user experiences is the best way to build a better web for everyone. \n
So, to summarise before I go - you’re part of a team, and everyone on your team is responsible for building great products. Take these principles with you, or work out your own, and don’t let the specialism you contribute to your project down by not considering the user throughout.\n
I’ll put up the resources and links I mentioned after this evening’s merriment, but feel free to find me at the after party if you have any questions. Thanks!\n

5 Likes

Simon Pan, User Experience Architect at Vivant 1 week ago
Chris Atherton, User Experience Architect at numiko.com 1 month ago
Chris Schmechel, User Experience Architect at Olympic College 2 months ago
Jonathon Colman @jcolman, Principal Experience Architect at REI 2 months ago
Mike Atherton, User Experierence Designer at RedUXD 2 months ago

Designing better user experiences (it’s your job) Presentation Transcript

BUILDING BETTERUSER EXPERIENCES(it’s your job)
Hello,I’m Frances
TXJSTXUX
Specialisms are great, but...
UX Designer
What’s the point?
You’re letting everyone else on the team off thehook for their part in making an experience great
UX Designer
Products are a team sport
Carrot > Stick
A ton of common sense
Common sense ain’t that common
Integration and accountability
What are you doing to make your users happier?
10 principles for everyone
1START WITHUSER NEEDS
What is the user trying to achieve?
2 DO LESS
“The government should only do what the government can do”
3 DESIGN WITH DATA
4 DO THE HARD WORK TO MAKE IT SIMPLE
"The quest for simplicity has to pervade every part of the process.It really is fundamental." - Jonathan Ive
5 ITERATE. THEN ITERATE AGAIN
MVP > Alpha > Beta > Live
6 BUILD FOR INCLUSION
User research > Academic ideals
7 UNDERSTAND CONTEXT
Hidden waterfalls
Design in browser
Jekyll + Heroku = easy, sharable, prototyping
When? Where? How?
2012.texasjavascript.com at 8am this morning!
8 BUILD DIGITAL SERVICES, NOT WEBSITES
Your site isn’t the destination
9 BE CONSISTENT, NOT UNIFORM
10 MAKE THINGS OPEN: IT MAKES THINGS BETTER
Commit to better experiences
Be part of the team
Thank you.fberriman.comfrances@fberriman.com@phae

Designing better user experiences (it's your job)

by Frances Berriman on Jun 14, 2012

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 54

Statistics

Designing better user experiences (it’s your job) Presentation Transcript