A designer’s road-map to win the heart of the engineer
By: Constantin Dohotaru
Tags: Design, User Experience, Software Development

Can I trust you?

Whichever the case, you need to build up trust that you know what you’re doing. If this seems daunting it’s because it is. For a couple of reasons: first, engineers have sometimes the feeling that they know everything, including design and user experience and while this might be true for some, it is, usually, not the case. There’s one thing to know how to put some HTML and CSS together and there’s a different thing to combine those harmoniously and help the user in his visit on the website. However, this will not stop some to argue with you over good practices “because I built once this website and ….”. Another aspect that I will elaborate later is the fear of the unknown. A developer whose skill set is in the back-end programming will likely not understand the implications of front-end work and will tend to be afraid of this kind of work up to the point of over-estimating it.

Another reason is because it’s expensive. It has gotten better with the rise and improvement of libraries but creating rich interfaces still requires quite some time. Because of this and because the engineers are expensive, companies prefer to focus more on bringing functionality to products in a more or less linear fashion rather than refining the existing ones based on feedback. Just for the fun of it, on the websites that you use, go and count how many feedback forms do you see.

There’s another aspect that it is your job to clarify: design does not equal user experience. Although my view might be wrong, I see design as the look of a website (colours, fonts, user interface elements) while user experience is much more subtle and refers to usability and usefulness. I haven’t studied this — because it wasn’t in the curriculum and probably still isn’t although it should be — so I had to learn about that during my career. But you can do better for your team. You can offer training and presentations so that you can speak the same language and refer to the terms as what they actually are and mean. Once you speak the same language with your coworkers and show how important these aspects are, your work just got easier.

Collaboration

The next step would be to involve people. The worst thing here is to lock yourself in a room and come up months later with specifications and/or a design without having talked with anyone about that. Your chances to succeed are directly proportional to the part of the company vision that you are able to incorporate in your design system (I will use this term on to include several aspects. There are many definitions out there, here’s a random one). Visit several departments to see how they understand the vision, what their goals are, what the intermediate steps are and always be up to date with the changes. Ask to be included in all relevant meetings that a company may have. Key here is also to actually understand what those products do and who are they intended for. I remember about a designer I worked with for a short amount of time (she got fired) that didn’t even know how to use the product let alone how to improve the user experience. You credibility will be greatly affected if you don’t know what you are supposed to improve.

One special mention here is the discussions (note the plural) you should have with the software engineers. As the software engineers are the people who will be impacted by your work the most, you should keep on your radar what they feel about the complexity of what you’re trying to do. The last thing you wish is to have an engineer say that what you want is too complex. This could be the case and should be mitigated but sometimes what happens is this: because the engineers are generally focused in their expertise they will use the “too complex” wildcard when they are too afraid. And it’s hard to argue with “too complex” because we don’t really have precise scales for simple and complex.

Let me try to explain this a bit more. At the beginning of my career I used to do only back-end development (that is, what happens behind a website). Slower and slower I embraced other parts of the systems and over the years I ended up programming everything a website is made of. So, I have both front-end (the website’s visible part) and back-end perspective. Now, many developers out there have focused mostly on one of these 2, so mostly or exclusively on front-end or back-end development. And each side things about the other one that is much more simple then it actually is. I used to do the same with the front-end work early on when I was doing mostly back-end programming. Each side tends to estimate the work on the other side rather high because they are not familiar with it and therefore afraid of the complexity involved. So, in your work you will have to balance this in your discussions. You will also have to balance the design systems to the skill set of the team you are working with. A team with enough front-end experience will be very welcoming towards your ideas while one without much experience will probably be afraid of what you want to do. It could also take them considerable more time to implement it which could derail road-maps and plans. If that’s the case then it is probably better to try to improve the skill set either by bringing new people or by training the existing ones.

Measure (paragraph so important that it gets its own heading)

This is a recurrent element but it is good to bring this early on to be able to gain trust and actually measure. There is nothing/nobody out there that can argue with hard data (of course there is but they are not being reasonable about that). Therefore start to measure early on. There’s a myriad of tools out there to help you do that. From page visits and interactions to heat-maps and A/B testing you are all covered. It is usually just a matter of money. The advantage of measuring the impact of your work is huge (and of course the converse is true). Not only it draws a professional approach but it helps you recognise wrong paths early on. If the numbers don’t move in one direction or the other there are 2 possible causes: you’re measuring wrong or the wrong thing (this is quite common actually) or the user interactions are not affected by those changes. When measuring especially in A/B testing, software engineers are required and this is another reason why you should explain your work and how it is important. I said that this is a recurrent element because you don’t measure once but rather continuously. The product managers and maybe sales and marketing will very likely be interested in those numbers as well so this a project you can do together. And if I would be to make a recommendation here: please do it together! The last thing a website needs is a tracking pixel for each department in a company to bring the performance down. Do find common ground, there is plenty.

Still collaboration but here you do more talking

Explaining things goes a long way. It is not a favour that you do to your colleagues but is rather in your job description. Here’s why: you do very specialised work. Not only there is likely nobody in your company doing similar things but what you do is in some ways if not pioneering work at least in its infancy. By this I mean that designing and especially user experience have not quite been but only on the biggest companies radars in the pre-smartphone era. The small and medium ones either didn’t have resources for these or they just didn’t bother since there wasn’t much of a competing edge here as most of them had a bad user experience so there was simply no incentive to improve. This has changed and improved but your work is still seen as too expensive and/or not important enough. Please convince me of the contrary but also explain me why I get frustrated on most of the websites I use? So, on one side your work is specialised and subtle and on the other side is expensive and not important enough. That’s why I believe you should do a lot of talking and explaining. Because this way of thinking is only preserving a bad user experience kind of software. When it comes to the talking you should also be prepared to defend your work and justify your decisions. Do not take this as somebody questioning your work or qualifications. That would be a terrible thing to think and also extremely false. People simply do not understand and you can’t blame us either as we are surrounded by bad user experience so how can we understand something that’s just not there? So instead try to educate the audience and the stakeholders about the importance of your work (don’t forget your measurement’s numbers, they do matter a lot).

So here a short recap until now: