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.

This year, I’ve been doing a bit of mentoring.

• Quite a number of my commercial assignments have had a mentoring ‘skew’ to them – rather than project work, my mission has been to try to impart as much of my knowledge as I can to a person or team.
• I’ve had the pleasure of working with interns on two of my projects this year (which is pretty unique and fortunate for a freelancer).
• I’ve been involved with the Information Architecture Institute’s mentoring scheme (you need to be a member and be able to remember your login)  which has given me the opportunity to compare notes with a number of up and coming UXers in the UK.

I’ve also been fortunate enough to be a ‘mentee’ (is that the opposite of mentor?) on several occasions – mostly when I’ve just straight out asked people if I can have some of their time to talk about a topic that’s on my mind and that I could use some extra perspective or experience on. In addition to this, there are dozens of people who unknowingly act as informal mentors to me as they share their experiences on Twitter, in books and at conferences.

What I’ve found really surprising is that in both the mentoring and mentee situation, I feel like I’ve been the one who has benefited.

Obviously, in the latter situation, I benefited from the kindness, experience and wisdom of those who were willing to do a Skype call with me (that’s the usual format of my mentee-engagements). It was where I was acting as the mentor that I was really surprised.

There’s a saying ‘if you can’t teach it, you don’t know it’. I’m not sure it’s entirely true but there is a special kind of knowing you get from having gone through the process of thinking about how to communicate what you know to someone else.

It does something to the way you know things – firstly, it makes you more aware of what you know, which is gratifying and confidence building. I think it also makes your knowledge feel more accessible and more valuable.

If the majority of the learning you’re doing these days is informal and self directed, you may find that mentoring is almost a way to give yourself a mark out of ten, an end of year exam, a sense that you have actually accomplished some learning and know a bit about what you’re talking about!

So, I want to take a moment to thank my mentors, and to ask you to think about how you might be able to participate as a mentor.

Do you have opportunities where you could invite an intern to work with you and gain invaluable experience? Can you offer some time to be a more formal ‘mentor’ to a UX newbie? In my experience, it can take as much or as little time as you want it to and the benefits to all involved are significant.

And yes, you probably do know enough to be a mentor – the best way to answer that nagging doubt is to give it a try. I bet you’ll be pleasantly surprised.

I frequently see other UX practitioners being beaten up on mailing lists because they don’t have a traditional design background, or visual design talent, or know everything there is to know about accessibility.

Interestingly, I rarely see us beating each other up for having poor client communication skills or project management skills, or uncreative or inappropriate strategic direction (or no strategic direction at all), but perhaps that is because these things are more difficult to measure and judge.

Here’s the thing though – these are just a tiny few of the skills that are tremendously useful if you want to be a good UX practitioner. And there are many, many very important ones I haven’t mentioned at all. How on earth is anyone a good UXers when there is no way in hell we can all be good at all of these things?

Truth is, we can’t. The sooner we accept this the better, and the sooner we embrace our own and others ‘T-Shapes’ the happier we and our clients will be.

I learned about the concept of T-shaped Information Architects and then T-Shaped UXers from Peter Boersma. The general concept is that along the ‘short’ bar of the T you have all the skills/experience that a UX practitioner needs – everything I listed above and more… if I made a list I’m sure we’d just spend time adding more and more to it.

Then we each have a ‘long’ bar of our T – your long bar is made up of those aspects of UX that you particularly enjoy, have aptitude for, and enjoy doing. That might be coding prototypes, it might be typography, it might be visual design, it might be research, it might be managing teams. As far as I can see, as long as you have a certain amount of experience and knowledge in each of the ‘essential’ elements of the short T-bar, then you can choose any of these to make up your long T-bar.

None of us has any right to tell someone who has different elements in their long t-bar that they are any less of a UXer than we are. Any one who does is, I suspect, either insecure about all the elements they’re not so great at, or unnecessarily proud of the few things they do well. Or don’t realise how much there is to know about if you’re going to be any good at this at all.

And then here’s what we need to do:

• Choose our own long t-bar.
• Become really great at what we really enjoy.
• Tell our clients where our strengths and weaknesses lie.
• Choose projects and teams that work to our strengths and give us opportunities to work up more experience and knowledge in areas we’d like to move from our short bar to our long bar.
• Network  with peers who have different things in their long T-Bars and work with them when we need to fill in gaps.
• Embrace our differences, stop shouting criticism at each other, be encouraging.

Yes, I know I should have done a diagram to go with this post. I’ll do that later if I get some time (or you’re welcome to make one for me if cool diagrams are in your long T-Bar!)

Donna says:

The person creating the IA must genuinely care about understanding the people who will use the site, and be willing to represent their needs (and go into bat for them when the pressure is on).

I think there is a very important nuance in what Donna has written here. Notice that she doesn’t just say ‘it’s important that you try to understand the people who will use the site’ but rather that you ‘genuinely care about understanding’ them.

Look for definitions of empathy and one word comes up repeatedly – feelings.

As UX practitioners, we seem to be on a constant drive to validate our work with number, processes, techniques, deliverables. This is all very important, and let’s continue to do that. But don’t let’s think that identifying pain points in a user journey through site usage analysis is the same as actually witnessing someone experiencing that pain.

Let’s not become caught up in simply designing to achieve numerical goals associated with user behaviour. Rather, let’s design to see the smile that spreads broadly over someone’s face when they’re able to achieve something they didn’t think possible, when they feel empowered, when the design surprises them in a good way, when it delights them.

If you don’t genuinely care about the people who are going to use whatever it is you are working for, then perhaps you need to ask whether you should be working on that project. Perhaps you need a holiday, perhaps you need a new job, perhaps you’re not actually cut out to be a UX person after all, perhaps you just need to do some more user research work.

Genuinely caring – having real empathy – is something that can’t be taught, but it is something that we can allow, encourage and validate for ourselves and our UX peers.

So, let’s do the work we need to do to gain the understanding we need, and then let’s be properly empathetic – let’s really care about those people we’re designing for. It will make you a better designer, and it will also makes the world a whole lot more interesting when you can see it, richly, from so many different perspectives.

I don’t hear a lot about the soft skills that, in my opinion, are probably more important than all of the CSS, sketching & typography skills you seek so I thought I’d contribute a short series on some of my favourite soft skills, starting with this on on adaptability.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

- Charles Darwin

Best Practice is a concept that you hear of frequently but very rarely see because very few projects are actually appropriate for ‘best practice’. What most projects need is the best possible practice you can fit in to the constraints of the project you’re faced with. There are usually many constraints.

Typical constraints include a lack of time, budget, people, data, cooperation, interest, and understanding of UX.

You can spend your time battling to remove these constraints – sometimes this is appropriate but usually it is not only fruitless but also places you further behind than when you started. Usually, the best thing to do is to sit down and work out what is the best you can do within these constraints and get started.

Adaptability is about understanding and respecting that, for your client, UX is usually one of many priorities they need to balance. It’s about responding to the environment you find yourself in, building the best process, employing the best techniques you can in the best way you can within the constraints you’ve been given. It’s about doing your job entirely differently for almost every project.

Adaptability is about knowing that you’re not doing things the best possible way but, against the odds, you’re getting them done well enough. It’s about being creative. It’s about remaining aware of the corners you’re cutting and factoring them into the analysis.

Adaptability makes User Experience accessible to all projects.

How to be more adaptable:

• DO be as familiar as you can with as many different UX techniques as possible – read, listen, talk to your peers, be active in the incredibly sharing global UX network
• DON’T be precious, or a stickler for process. Don’t expect people to drop everything to do things your way (or the way it says in the book)
• DO keep doing research
• DON’T sacrifice time to do analysis and lots of design exploration (sketch!)
• DO make sure you’re constantly focussed on the end goal – what are you trying to achieve? What is the goal of the redesign you’re doing to that page? What is the goal of that research activity? (Demonstrable victories often buy you more time/budget/participation for future projects)
• DON’T do it alone – share your process with the team and skill them up to assist, look for ways to work together to save time
• DO cut corners – interview less people, recruit less fussily, spend less time, prototype more roughly.
• DON’T forget which corners you’ve cut and why – factor this into your analysis, educate your team on what would have been a more ideal approach
• DO be creative – experiment, try different approaches and see what works, make up new ways to solve problems (and share them back with us!)

Please share your thoughts on how to be more adaptive as a UXer, and also the other soft skills you think a great UX practitioner needs.