UX vs Strong personalities — #3 The obstinate developer
Developers are the ones that bend technology your way. Without them your design will never see daylight and forever remain just an idea. You need a good relationship with the developers and understand their needs and passion to be successful. There’s a wide variety of personalities of developers and if you identify what types are in your team, your work as an UX:er will be easier and more successful. With a not-so good relationship your design risk ending up flawed, compromised or totally devoid of user value.
Some developers are very interested in UX. Some have even worked as UX:ers, whereas others couldn’t care less about the users and only take pride in writing beautiful code. Learn your team members and turn that into an advantage — include interested developers in UX activities but let the non-interested be. Even though you might reason that all developers should care about and be interested in the users’ best, you will still find those that are only interested in their code.
Still, you have to make sure that your design is implemented as intended. It takes a lot of unnecessary energy and time when things are not implemented according to design. Remember that the most time-consuming part of system development is the actual development. If the developers understands your design and the rationale behind it, they will implement it more correctly and less time will be spent on development and test. Not to mention frustration and irritation.
If you are a serious UX:er, you don’t only care about research and design. A serious UX:er also cares about the end result and all major events downstream that lead up to that. The main event is development. That is when design is being converted into code and during that period a lot of problems can arise. If you are not present when decisions are made your design can quickly deteriorate.
Sometimes developers can be a bit obstinate and act as they wish. I once had to bribe a developer to implement my design. He (a very young guy, straight out of university) argued that my design was unnecessary and did not want to implement it. Looking at this specific part of the system I was bound to agree, but for the system as a whole it was necessary to follow the design guidelines. I did not want to involve his boss so I choose to solve it in another way. In my home country, in late spring, there is the waffles day where all restaurants serve waffles after lunch. Timely, this day appeared and during the lunch I offered to fetch him waffles if he implemented the design. He accepted and after that he did all design as specified.
Another developer I worked with was a deep thinker. He was a great developer but living in his own world sometimes caused problems. A design I had made was implemented by him and he reported that everything was going as planned. At the following demo (with external stakeholders) the PO was walking through the newly implemented parts and as he was familiar with the design he knew the system behaviour. At least he thought so. When he approached the specific part the mentioned developer had implemented, the cursor unexpectedly changed into a pen. Luckily, on his spare time the PO did impro shows and had no problems explaining why it did so and the demo progressed as if nothing had happened.
Afterwords, he went up to the developer and asked where the pen had come from. The developer explained that he thought that it was hard to see that you actually could edit that specific part and so he changed the cursor into a pen. I heard the conversation and said that I agreed and it was a great initiative, but why didn’t you tell us?
The next external demo, the PO was approaching the part where the cursor turns into a pen but was caught mid-sentence when the pen did not appear. There was no longer a pen. He managed to anyway do a great demo but afterwards again approached the developer and asked why there wasn’t a pen anymore. The developer said that as we had been so upset last time he had changed the cursor back to default. Again by not telling anyone.
One project I was involved in, the team needed three times to fully understand the design. First we had a workshop with the entire team, the PO explaining the business and me telling about the users and showing some preliminary designs. Feedback was collected and acted upon resulting in design changes. The second time was during sprint planning when the updated design was shown and walked through. The third time was when an individual developer selected a new task, he/she was to get a reminder by either me or the PO.
In the beginning of the project we did not have all these three times of gradual handover. Instead we had lots of confusion, bugs and errors. By expanding the handover parts we could see this reducing and by the time we had three parts everything was working well. Later on in the project when we, due to whatever reason, did not have all three parts we were back in confusion, bugs and errors.
Looking at resources and team spirit, the three handover parts was a major success. Developing the wrong things, testing and bug reporting, prioritizing bugs, re-coding and walkthrough with the developer took a lot of time and frustration. With this team, we eventually reached a high level of understanding, involvement and delivery, in large extent thanks to the three part handover.
During the sprints, when the developers are hard at coding, you should show that you care and support them. Be present at daily stand-ups (if you’re not already are), tell them about your work and listen to them describing their work. You might hear insecurity, frustration or even anger and that’s when you step in and offer to sit down with them and walk through the design and what’s been preventing them from progressing.
I always try to sit among the developers to bolster the team spirit and be available for questions and discussion. In organisations where there is a central design department you could split your time between your design colleagues and your team. If you only hang out with your fellow designers, you’ll risk being seen as an outsider by your team members, which will affect your trustworthiness and their willingness of asking you design-related questions — they will just go their own way.
My headphones are of a model that is not closed so a lot of background noise leaks in. This is a problem for anyone that wants to work undisturbed but for me it gives an opportunity to listen in on developers talking. As soon as I hear developers say something like “how is this supposed to work” or “did you understand this bit”, I take off my headphones, walk over and ask if I can help. I did this numerous times in this project and it was always appreciated and solved the problem in a couple of minutes.
When there is a distance between developers and UX — time difference, geographical, trust or availability — there is a risk that a developer takes his/her own decision without asking you. If you make sure they always contact you, even if they think that an issue is too small, you can catch and act on potential large problems early. Make sure that you have time for the developers and are not fully loaded by new and exciting stuff. In my time planning I always include the task developer support committing me to respond quickly to my team members in need.
I always try to include interested developers in the design process. I make them meet users, I include them in idea generation and make them observe in user tests. Spreading the knowledge of the users gives the developers a much better understanding and also a sense of involvement resulting in a better solution. When developers tell me that my design or ideas does not support the users and argue from user insights, I have succeeded. Then I know that the project has potential for success.
Design studio is a great method for brainstorming and involvement, letting all voices be heard and all ideas to be researched. Mind though, that Design studio does not suit all — I’ve had people leave midways. In a fast paced storming session not all people feel comfortable, some people want calm and quiet to be able to produce ideas.
The second most important relationship for a UX:er is to developers. (The most important is to users). The developers can make or break your design and to be successful you need to understand your team and involve them appropriately. By doing so, not only will the end-result be better, you’ll get there faster and it will be lots more fun.
