Category: soft skills

Don’t give up.

Leisa Reichelt3 Comments

Don’t give up.
Don’t let yourself be convinced that this is just the way it has to be.
Don’t stop asking questions.
Do ask for what you need to do the job well.
Do trust your instincts and your experience.

Pay attention to red flags.
Work with people who care.
Conduct experiments.
Don’t take yourself too seriously.
Remember that confidence and competence are not always related.
Always be learning.

Ask dumb questions.
Maintain naivety.
Be able to explain what you’re doing to a five year old.
Make sure you know why you’re doing it.

Your life is a design project.
There are many possible solutions.
Don’t just accept the default settings,
be creative, imagine alternatives.

Don’t give up.

I wrote this for the Pastry Box at the end of 2012 and accidentally stumbled on it today.  I still say most of these things to myself most weeks.

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.

Some thoughts on mentoring

Leisa Reichelt5 Comments

As we’re getting into the tail end of the year it’s become apparent to me that one of my themes for this year has been mentoring.

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.

What’s your T-shape?

Leisa Reichelt3 Comments

I spent a few hours last night beating myself up for letting my HTML and CSS skills get so rusty that I now need to dedicate a significant amount of time getting myself back up to date in order to be able to do a halfway decent job of coding my own prototypes.

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!)