Category: interaction design

What is a UX Developer and are they really a thing?

Leisa Reichelt11 Comments

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.

Works for me, your mileage may vary.

Economist/Drupal – Sprint 2 Demo (CRUD-in-place)

Leisa Reichelt4 Comments

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.

Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!

In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.

These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).

Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.

The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.

So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!

Look forward to hearing from you and thanks in advance!

(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)

On documentation (or lack thereof)

Leisa Reichelt10 Comments

I was talking to someone recently about doing some work with them. They said ‘can you send me some examples of documentation you’ve done lately’ – they wanted this to check that I could do what I said I could. Fair enough. Except, aside from the fact that all the documentation I’ve done lately is commercially confidential, so I’d have to hack it around a little to be able to show it to someone else… it made me realise how long it’s been since I’ve actually done the kind of ‘finished’ documentation I used to spend a lot of my time doing.

I just don’t work that way anymore, it seems. Sure, I still do wireframes every now and then, but never a ‘complete set’ and often with no where near the detail I used to include. Why? I think there are three reasons. Firstly, I tend to work on more of a strategic level than a detail ‘exactly where does that button go’ level these days. Secondly, I tend to work on projects where there is no time for that level of detail. And finally – and most interesting I think – I tend to work closer to the production team these days – more often are graphic designers designing and/or developers developing the very same stuff I’m wireframing at the same time. Investing too much in the documentation is a waste of everyones time – much better to do just enough to get them going and then work collaboratively with the team to do the fine tuning.

Personally, I think I should have been working more like this since forever.

Does any of this sound familiar?

‘I can’t work this!’ – iPhone’s cameo in Sex In The City Movie

Leisa Reichelt5 Comments

Yes, I’ve seen the Sex In the City Movie, I’ll admit it. Either the rest of the UX community hasn’t seen it yet or we’re all just ignoring the fabulous user experience moment that Carrie has with the iPhone. For those who haven’t seen it, she is handed the iPhone (not hers) at a time when she urgently needs to make a phone call. She looks at it briefly, pronounces ‘I can’t work this’ and asks for a proper phone.

Unsurprisingly, Gizmodo reported it this way: ‘Confirmed: Carrie Bradshaw is too stupid to work a iPhone‘. Very helpful.

Personally, this was my favourite part of the whole movie (which says more about the movie than it does this particular moment). I loved the fierceness of her reaction to the unfamiliar interface.

It reminded me again that those of us who are ‘into’ interface design are really a fairly small group and how important it is for us to remember that the vast majority of people who encounter our interfaces do so on the way to achieving a task – sometimes one that is urgent and very important to them.

The people who encounter our interfaces in that kind of moment are not going to find them interesting, but an obstacle. And that they won’t take the time to ‘explore’ and ‘enjoy’ and ‘learn’ our amazing interface design.

It would be easy to say that SJP’s encounter with the iPhone showed that it lacked ‘usability’, but in fact it is probably more instructive as to the importance of evaluating usability over a longer term than just a one hour session in a usability lab. As I’ve said in the past, if something like the iPod, and no doubt the iPhone had been ‘usability tested’ using the traditional methods, they no doubt would have ‘failed’ and the world would be poorer for it.

All these things I had to think about because the movie was so disappointing… (speaking of bad UX).