Why Developers should care about UX Design

A great developer and an excellent product designer will always care about users’ opinion, that ought to be the start line to upgrade. It is one of the key ingredients for success is how the development team and design teams collaborate. It is quintessential for the planning and development teams to figure together.

In this article, I focus on why developers need to care about the design process. I am limiting my discussion to the highest 4 reasons.

• UX is all-encompassing, technology is an integral part of it

Let’s assume you’ve got a very well a screen is meant, but the backend service takes tons of your time to reply once you submit all the info. Suppose you’re building an outsized digital eco-system and don’t design a strong component-based architecture resulting in tons of inconsistencies across the whole system. In both of those cases, regardless of how good the designs are, the eventual user experience will suffer. Both these points were only for skeptics who completely stand back from the user experience conversation.

I firmly believe that developers can do tons quite faithfully reproducing the output created by the planning team. Let me give you an example. In a recent product backlog refinement meeting, one among the business owners expressed the necessity to supply a simple way for the back-office workers to manage duplicate id’s that get created in the system. The system that I am referring to is a large workflow/tasks based enterprise solution here. As soon as this request came through, the planning team leads got into discussions on how they might approach this, the quantity of user research needed, etc. When I probed the underlying problem further with the technical lead, we realized that the entire problem might be handled automatically with minor tweaks to the back-end system.

The experience of the system handling it and therefore the user not having to try anything in the least is much better than any prototypes the planning team would have come up with, after utilizing time on user research, prototyping, etc. This just goes to prove that developers can play a pivotal role in “designing” the foremost delightful experience for the end-users.

• Most brilliant architects are deep-rooted in user research.

With every software platform striving for abstraction with every passing day, it’s presumed that the majority of the developers will hit a plateau in terms of technology. While we all have seen tons of outstanding developers technically, those who scale heights quickly are those who understand the users and business well. Knowing what matters to the end-users, what are their biases, what parts of the appliance are going to be accessed frequently and wish to be high-performant, etc. is a huge advantage for an architect, compared to someone who doesn’t understand this.

• Understand why certain features are being prioritized.

As a developer, what percentage times have you ever cursed the merchandise owners/product managers for prioritizing a particular set of features over others? I can recollect umpteen number of conversations when there was a big keep off from the event team to create a particular feature. If all the teams, including the event team, aren’t involved in design activities like user-research synthesis, you’ll not have buy-in from all the teams, on what is being built. This will end in tons of frustrated individuals, including developers.

Several such things have instilled a firm belief that developers who understand stakeholder’s needs are often more motivated and have a tendency to create more creative and efficient solutions.

• At the top of the day, your code is to form lives better for your stakeholders.

I am sure that each project goes through a minimum of one phase where the event team clocks 80-hour weeks to make sure that the product/project goes live needless to say. What is all that effort worth, if the outcomes weren’t met? By working closely with the planning team, after every sprint, a developer can see how all that tough work is making someone’s life simpler. This is very critical and very satisfying from a developer's standpoint. This is probably the rationale why public sector projects will always remain closer to my heart than others.

This is often missed out by the majority of the teams I have worked with. Once the product/project goes live, developers never become involved in understanding the impact they need created, denying themselves an opportunity of great satisfaction/learning.