10 tips for UX Freelancing

Every now and then I’m asked for advice on getting started as a UX Freelancer. I tend to say the same thing most times, so I thought I’d put them together here for future reference and for the benefit of anyone else who’s thinking about making the jump (or who has made the jump and wonders whether we see the world the same way….)

I offer no guarantees about any of these tips, all I can say is that they have worked for me and that they form the basis of my ongoing approach to UX Freelancing. Some of these I’ve known since the beginning, some I’ve learned, most often the hard way.

In presenting these tips I am speaking particularly to those people who think of freelancing as I do – working for multiple clients on multiple projects (not always at the same time) in the course of a year, not taking a series of long term full time contracts.

If you are also a freelancer and would like to offer additional or alternative advice please do feel free to add your comment below.

1. Why are you doing this?

Why are you choosing to freelance? Is it for a better balance between work and the rest of your life? For riches and fame? To have more control over the work you do? There are lots of reasons why people choose to freelance (some of the more or less based in reality!). Think about why you’re doing this and then think about what decisions you’re going to need to make in order to achieve this outcome.

It is crazy how many people start out freelancing imagining spending Tuesday afternoons in the local cafe reading – because they can. Then end up working more hours than they’ve ever worked in their life and never going anywhere near a cafe or a book.

What are your ‘project goals’ for becoming a freelancer? Make some ‘golden rules’ that will ensure you can achieve these goals. You’re in control now, so be proactive about it and make life/work what you want it to be.

2. Finding work: Build a good network, do good work

The best way to get good work is to make friends with other UX Freelancers who are good, get busy, and want to find a good home for work they can’t do.

Actually, I don’t get much work this way personally, but I pass on quite a bit and see several other good UX Freelancers doing similar.

The *really* best way to get good work is to do good work, and to have other people talk about your good work to others who may wish to hire you. I think this is how I’ve gotten most of my work over the years and I hope it continues this way.

(You may have noticed that I do not recommend contacting recruiters, not even for ‘safety’ for your first job. All evidence I have seen indicates that you are unlikely to get good/interesting UX work as a freelancer from recruiters and you are more likely to be paid less than you’re worth.

Although, I have also heard evidence that recruiters over charge for UXers, this has only ever come from someone looking to hire, not be hired. If the only way you can get work to start your freelancing career is through recruiters I’d be tempted to re-think freelancing altogether).

3.  Be visible.

Being a secret freelancer is not a good strategy. There are several different ways you can be visible, choose the one or more you find most comfortable. Options include but are not limited to: write a blog, be active on Twitter, speak at conferences & other UX events (large and small), attend events and talk to people, contribute answers on UX related email lists, forums, Quora etc.

When being visible, the best way to do so is to contribute to the body of knowledge of your UX community. We don’t really want to hear how fabulous you are (I’d rather hear that from your previous clients or colleagues). We would like to know what you’ve seen that’s interesting lately, why it’s interesting, what you learned from a project etc.

You don’t need to be a massive self-promoter. I’d advise against blatant, unhelpful, self promoting, but being visible (particularly being digitally visible, Google-able with positive and relevant search results ensuing) is important.

I find that by sharing my work, my process and my learnings (as much as I’m commercially able to) I negate the need for preparing and maintaining a CV or shiny portfolio. Your mileage may vary.

4. Position yourself.

If I know what kind of projects you really like (and are really good at doing) and I hear of a project like it, I will think of you immediately. Apply the same approach to positioning yourself as you would to your projects.

Don’t try to be everything to everyone, think about the kind of work you’d rather do and let people know that’s what you want. You might end up doing all kinds of different things, but you’ll become a go-to person for your particular niche, and that way, stay top of mind.

5. Don’t take work you don’t really want to do.

It is really hard to say no to work when you’re freelancing. Really hard. It takes a while to believe that work will actually come to you when this project is over and that you will be able to pay your rent/mortgage etc. Don’t panic and take a project you really don’t want to do. There are two reasons for this:

Firstly: It’s really hard to do good work on a project you don’t care about. The quality of your work is critical to your future success as a freelancer. You can’t afford to do a bad job (not if you can possibly avoid it).

Secondly: It is a little known fact that the universe conspires against freelancers who ignore this tip. Just as you’ve become contractually obligated to work on the most boring, tedious project ever for weeks into the future, you will be offered the Project Of Your Dreams. And you’ll have to turn it down (or, at least, you should – skiving out on projects at the last moment or worse, when you’ve just started, because you’ve got a better offer is pretty bad form). I can’t begin to tell you how awful this feels.

6. Don’t overcommit.

See above re: it’s hard to say no to work. Also, projects always take longer than you think they’re going to. This can lead to working every hour god gives you. This is not good.

It is not sustainable to work ridiculous hours indefinitely. You will probably have to do it sometimes, don’t make it a way of life. Your mental health, family/social life and the quality  of your work will all suffer. Even if you say ‘screw my mental health and family’, the quality of your work is the indicator of both the volume and interestingness of your future work. Don’t do anything to jeopardise that. (Like, say, working at 3am on a Saturday morning when you’ve already clocked 80hrs or more that week).

Try to over estimate the time you’re going to need to do a project (then you may just get it done in time) and do allow yourself some downtime to remain sane and relatively fresh.

7. Don’t over complicate the legal/financial aspects.

When you’re starting out (in the UK at least) all you need to do is register as self employed. You don’t need to register for VAT immediately (although it does feel weird charging no VAT and clients do ask questions), you don’t need an accountant or a limited company immediately. Take it easy and scale things up as you need to.

Do make sure that you are tracking your time and your invoices properly. There are millions of options for this. I have used FreeAgent since I started out because it allows me to do estimates, invoices, time tracking, maintain a client list, and automates a lot of my tax and it comes with a pretty delicious user experience. It’s not the cheapest option but it has worked well for me (and now that I have an accountant, they can log in via an ‘accountant login’ and get everything they need automatically). Paired with an iPhone app called Out Of Pocket which integrates to FreeAgent and lets me capture my expenses on the fly, I’m  much better at my accounts than I ever thought possible. Accounts are almost fun.

Except for the tax-paying bit. (On that note, don’t spend your taxes, or you’ll find tax time rather painful. (Speaking from experience here)).

Get Professional Indemnity insurance. Hopefully you’ll never need it. Some clients will require it.

Don’t stress out about contracts, stress out more about choosing the right clients and managing their expectations by communicating well throughout the project. You *really* don’t want to get down to enforcing a contract and in most cases, the cost involved in pursuing things legally outweighs any financial benefit.

I probably shouldn’t admit this but the only time I tend to sign a contract with a client is if they have one they want signed. Most projects I do without a contract. I work hard to make sure my client understands how we’re going to work together and what they’re going to get – almost invariably this changes as we get to know each other and our project better.

If things start feeling dodgy, in any way – stop working and start talking. Invoice regularly, make sure you are going to be paid. If you don’t think a client is going to come good with the cash, ask for a payment upfront (again, this is something I do rarely tho’ I know it is standard for others), and put them on short payment terms. Or better still, don’t work with them. Writing off invoices is very depressing.

Be aware when invoices are overdue and don’t be shy about chasing them up with a friendly but timely email.

In my experience, if you choose good clients, you don’t need to worry too much about getting paid.

8. Value yourself appropriately.

When analysing the recent UX Freelancers Rate Report data, the thing that most struck me was how apparently random our dayrates are.

A lot of really good people are charging a lot less than they should and a few are apparently charging more than they’re probably worth. Now we have some idea of what we’re all charging – be informed and charge yourself out appropriately.

Once you’ve set your rate, keep track of how many people simply accept it and how many wince and complain at the rate. (Exclude recruiters from these calculations). If more than 1 in 4 wince, you may need to lower your rate a little. If fewer than 1 in 4 wince, you may need to put your rate up.

9. Don’t do freelance work and look after small children simultaneously.

See above re: overcommitting. I’ve tried it. It’s horrible for everyone involved (you, your client, your kids). Get childcare (and curse that it’s not a deductable expense).

10. Take the lead.

When I think about the (thankfully only occasional) projects I’ve worked on that didn’t go as well as I’d like them to, it was almost invariably because I was looking to my client to take the lead, to tell me what they wanted to do, and then for me to act on instructions. In every case, whether the client *thinks* they know what they want or if they haven’t a clue, you should be proactive in setting out the process or project approach that you think will give the best outcomes and make the best use of resources.

Your client is almost always paying a premium for your services as a freelancer – this may be because they’re desperate and this is the only way they can get the UX work done, but hopefully it is because they are looking to you to bring some specialist skills to their team. Give them their money’s worth and make the most of your time with them by being proactive and helping them use you well.

So, that’s it. Almost everything I’ve learned about UX freelancing that I can remember today. Let me know how much of this resonates with you or not, what I’ve missed (I know there’s lots!)

Five community challenges for design in Drupal 7 & beyond.

This week sees the release of Drupal 7 – a big event for the Drupal community and also individually for myself and the team at Mark Boulton Design as we worked together with the community on the D7UX project which aimed to significantly evolve and improve the user experience and usability of Drupal.

I’d like to start by congratulating the community on coming together to once again significantly improve Drupal and give it all away for free. Let us never forget what an amazing thing open source software development is.

The last couple of years have been interesting both as a participant and as spectator (because I do feel as though I occupy both of these roles, as incompatible as they may seem… many others who have attempted to participate as a designer in an open source community can probably empathise). It has been exciting to see Drupal embrace the idea of design and user experience as vocally and visibly as it has. I think this visible and actual (financial) commitment has really paid dividends although – as ever, the numbers will ultimately tell that story.

There have also been some fairly significant frustrations. I hope that as we raise a glass to celebrate the release of Drupal 7, we also take some time to resolve to think about how we can make design work even better in this community (and all open source software communities).

To that end, here are some challenges I’d love us to attack:

1. Designing participation for designers

Issues queues and IRC are the traditional communication environment for open source development. If you want to be involved in design for an open source community that’s where you need to be.

During D7UX I was there all the time. Since then – not so much.

I have no idea how people keep track of what’s going on in the issue queue – on it’s own, it doesn’t work (unless I’m doing it all wrong?). You need people to ping issues at you in IRC (or elsewhere) to make sure you know what’s going on.

Being on IRC 24/7 is just not an option for me – much of my work is done away from my computer (sketching, running workshops, doing research) and when I’m at my computer I need to be focussed – IRC is not good for focus.A culture of participation that is designed around IRC and the issue queue is not compatible with getting designers to participate in design problems at the right time (that is, toward the beginning, not at the very last moment).

We need to come up with a way that is more proactive – that goes out an pings designers who might be interested in participating, rather than relying on them coming across something in a timely manner.

Yes, this means changing the way the system works because designers have special needs. Do you want good designers to participate in a meaningful way?
Deal with it. (And yes, we’ll help you design this change. Happily.)

2. Recognising participation for non-developers

At this point I’d like to give the accessibility team, the security team, the documentation team a shout out and congratulate them for their brilliant work on Drupal 7.

I regret that there are probably more people whose lack or recognition I am currently perpetuating, because in Drupal, if you’re not listed in the commit message, your contribution, literally, doesn’t count.The Drupal community subscribes to the saying ‘talk is silver, code is gold’ and there’s been no better demonstration of this then the various thank you pages that have been posted recently using the list of commits to Drupal 7 as an indication of the amount you have contributed to the project.

This means that someone who, in a few hours here and there, submits a handful of minor patches is more recognised than someone who spends hours every week taking all kinds of flak from the community trying to educate them on the importance of accessibility, or explaining a design pattern, or reviewing Drupal.org  and organising the design and content work required in preparation for the product launch. For many of us (and in fact, probably for developers as well) there is a whole lot of thinking and talking and sketching and research that happens before any code is written – actually writing the code is (sometimes) the easy part.

We need to change this culture. We need to make non-code contributions much more visible and recognised. (And this can’t be achieved by simply sitting in IRC 24/7 having a presence and ‘gaining respect’).

Yes, again – people who don’t write code have special needs.
If we want more of these people we need to  change the environment because these needs will not change.

3. Maintaining coherence without ‘owning’ design

Design ideas in the Drupal community need a maintainer, just like core or a module or any important piece of code.

How is it that the Drupal.org homepage can be radically changed within the space of a few hours without any consultation at all with the people who did the research and design work behind it? Or even any adherance to the style guide that accompanies it. (Not to suggest that a style guide is capable of providing specific guidance for every possible outcome).

Of course design needs to evolve as the community and product needs evolve. Of course designers need to respond to the competing requirements of end users, developers, and everything else. This is not about design being precious and permanent.

Just because you *can* change the design, doesn’t mean you should be allowed to – not without a ‘maintainer’ of the design giving approval or at least feedback that you can then act on or against. There is no point investing in good, thoughtful design and then not making any effort to preserve it. Especially when the designers who have done the work are around and more than happy to contribute.

This is not about ‘special needs’ – this is about crediting designers with some ownership over their own work. Not wholesale ownership, just a little. Enough to warrant the opportunity to participate and be consulted.

4. Design leadership in open source communities

Reliance on the current model of participation (issue queues and IRC) means that leaders in the design/ux community currently emerge by virtue of presence – being available on IRC and active in the issue queues. You can’t ‘commit’ design in the same way that you commit code, so you can’t build your reputation in many other ways than being there and participating. (The relatively recent movement toward designed distributions is possibly starting to shift this a little, although still relies on code).

This is good because it means that these people are passionate about design and UX in Drupal and show commitment to the project. It is bad because it naturally privileges people who have more available time and who tend to be less experienced. Designing for Drupal and in the Drupal community is a challenging prospect. UX and product design considerations impact an ever increasing audience who rely on Drupal for ever more critical capabilities.

We need to find a way to allow experienced designers (and in this I include UX/Usability people) to play a proactive, leading role in shaping design in the Drupal community at a strategic, not just tactical level, without requiring them to be on IRC every hour of the day and night and having to respond within minutes.

It is not an acceptable response to say (or think) that there are no designers or usability people out there who are interested in participating or that they just don’t have what it takes to stick it out. There’s no shortage of people who would willingly contribute time and expertise and many who, over the years, have attempted to contribute much more.

I’ve been reading a lot about change management lately and one of the keys to successfully making change is making the environment conducive to the behaviour you want to achieve. That’s our challenge moving forward.

I think this is possibly the most important consideration in my list.

5. Defining our value proposition

I’ve said it before and I’ll no doubt say it again – you can’t meet the needs of the wide range of activities of the incredibly broad Drupal audience in the one interface. Not well. Drupal 7 via D7UX is – hopefully- a better experience for both newcomers, content creators and, in some ways, developers. It is nowhere near an optimal experience for any one of these groups, because they have conflicting needs, behaviours, and characteristics.

Drupal is just like most of the clients I’ve ever worked with who are seeking growth – struggling with their value proposition. I’m not saying we need to abandon any one of our audiences, but we need to address them in different ways, not through one incredible interface. Thankfully I’m now able to stop just talking about this and actually do something through the Project Verity theme work Mark Boulton & I are doing together. (It’s really starting to come together now – stay tuned!) We need to define a UX strategy for our key audiences and then optimise the environment for people to design most effectively for them. We need to do that before we start designing Drupal 8.

It has been a great honour to have worked on the D7UX project and the Drupal.org redesign and, through that, to have had the opportunity to work with some of the passionate and talented people who contribute – in many ways – to Drupal, it’s current and future success.

I look forward to having some kind of continued involvement in the community – exactly what that is will depend on how seriously the community takes some of the issues I’ve outlined above. Regardless of that, I’m here – you want some help, you know how to find me.

Cheers Drupal – Congratulations!
Here’s to the success of Drupal 7 and beyond.

I’m thrilled to be attending Drupalcon Chicago in March – I’m even doing a pre-conference training session called What Users Want that I think will be really fun and which is focussed on teaching people to do what I do (UX research and design), especially those who have never done it before (managers, developers, marketers, I’m looking at you!).

Want to talk about this stuff in person? I’d love to see you at Drupalcon. It’s a great conference and, with Jared Spool, Clay Shirky, Mark Boulton, Jeremy Keith, Russ Unger, Karen McGrane and more coming to share their experience, it’s almost a design conference with added Drupal – hooray!