— a UXers guide by Amanda Wright —
1. Respect your developers
As user experience professionals we demand respect for our ‘craft’ and so you should respect your developer’s code. Remember, it’s easier to imagine than it is to build.
2. Don’t throw things over the fence
There’s nothing worse than finishing everything to the nth degree, handing it over to the developers and then vanishing, with scarcely a thought given to the implementation.
If you leave the developers to their own devices, don’t complain when they start to fill in any blanks or make decisions for you. Make sure you are around to answer questions and help with the QA and release process.
Being available post-release to monitor feedback channels can provide you with valuable feedback and help identify bugs that may have slipped through.
3. Work (largely) in parallel
This is a controversial one, particularly in agency environments where signing off deliverables and meeting deadlines is key. Once sketches have been agreed, developers can start thinking about how to structure the application, giving you a chance to move onto higher fidelity wireframes. Once these are agreed, developers can move onto building the interface. This allows for problems to be identified and solutions to be devised as a team (and documented for posterity if needed).
4. Embrace developers’ problem solving powers
We often like to think of ourselves as the champion problem solvers, but guess what? Developers like to solve a challenge or two as well. I’ve found that identifying the areas in which developers can add value, or even just leaving them a little space to make their own mark on the experience, can do wonders.
During implementation, if they identify a problem that needs resolving, allow them to suggest a solution first before you jump in with one of your own, they might just surprise you.
5. Involve developers in user testing
Bringing to life the voice of people who use to your website or service is one of the key objectives for someone in a user experience role. Go one step further by sharing videos and feedback from testing with your developers. If possible, allow them to observe if they have time to attend sessions. Watching people struggle in a user study is worth a thousand times more than just banging on about a user-centred design approach.
6. Use Shared Nomenclature
For an industry that intends to make things clearer, we do love a good buzzword and have a tendency to use lots of acronyms. Using plain language should start when you communicate to your developers and the wider team. The user experience community has recently adopted development terminology and made it our own (Agile and Lean UX spring to mind) so it’s important that everyone is clear what we mean when we use these terms, especially as the mental models can often differ.
7. Make time to share learnings from your industry
Just as you have to contend with countless user experience methods, new interaction paradigms and fine tuning your soft skills, developers (I’m talking largely front-end here) need to overcome the latest browser quirks, keep up to date with new languages and the endless parade of new shiny devices. Both tribes face significant challenges in order to keep up to date. Make time to share what you’ve learned so you both are aware of what’s going on in each other’s world.
8. Learn to be lazy
Sounds a little odd but there is a long running joke that a good programmer is a lazy programmer. Developers will strive to overcome redundancy and automate anything that needs to be done more than twice. Rather than reinventing the wheel, we should look to adopt standard patterns where appropriate and build upon existing user experience work. One way of doing something, is always better than three – especially on the same website or service!
9. Be pragmatic
This doesn’t mean that you should stick to something ‘safe’ when you are designing an experience, it means that you should be realistic about budgets and technical constraints that you have to deal with. A simple, functional and well-executed solution is more valuable to your client or company than a stripped back, half-finished solution that would have been great if all the bells and whistles were included. When it comes down to the crunch, the bells and whistles are always the first to go.
10. Don’t be the “I” in team
As the cliché goes, “there’s no “I” in team. It doesn’t matter if you designed the best experience in the world, if the implementation is poor, slow or full of bugs. You are only as good as the developers you are working with.