#1 Designers & Developers

If every stakeholder involved in the process of initiating, conceptualizing, managing, designing, developing, testing, or marketing a product - software or otherwise - play their roles with ardent honesty towards achieving excellence in their respective domains, then the world would be a better place.

While this sounds nice to hear and agree with, on paper and in the spirit, in my 10 years of UX design consulting career, it is observed that the ground realities are significantly far from ideal.

Each person is driven by his or her own motivations, preferences, biases, constraints and prior experiences which unintentionally influences the end result. They work hard during the product development cycle - sometimes push, pull, resist, or allow themselves to be carried along, as this process unfolds and the product eventually gets delivered.

This 'singular cooperation' is comparable to a colony of ants carrying a dead caterpillar towards the anthill. From afar, it appears that they work as a team, cooperating and coordinating towards their goal. But up close research has revealed that each ant is pulling in an arbitrary direction which it think is appropriate to achieve the goal, working against the efforts of the other ants. Somehow, these forces balances each other out and the caterpillar is moved in the relative direction that the majority of the ants are pulling in.

The UX designer represents the stake of the user in the process of the product development. S/he believes in designing layouts and interactions which simplifies the task-in-hand for the user and making it more engaging from the user perspective. Additionally, his or her role is to maintain checks on the decision making process during product development, in case it starts deviating away from the user's interests.

The developer, on the other hand, is driven by different priorities. S/he has the arduous task to bring together all the abstraction i.e. the expectations of the business and the design team, into a tangible working product, within limited time and resources.

Economic factors (read as 'organisational mandates for profitability and resulting restrictive timelines') re-prioritizes the need "to deliver on time, within the tight deadlines" above the need "to ensure a refined user experience". Some even consider the proposed micro-interactions as cosmetic or aesthetic or good-to-have stuff, which can be dealt with later. They fail to realize that the overall user experience is a result of a collection of subtle interactions that the designer strives to incorporate within the design and by deferring many of the proposed interactions, the overall experience gets diluted.

"The sum of the parts is greater than the whole."

Not to mention, the additional drag of fixing a huge backlog of defects, which makes it more difficult to attain their prioritised goal and further reinforces the focus on "to deliver".

In an effort to resolve the many technical challenges faced during the development process, the development team tend to lose track of the purpose of the product, which is "to serve the interest of the user". It does not in any way mean to undermine the hard work put in by the developers in building great software.

Let me cite an example in one of my recent projects, to demonstrate this.

The following image shows a part of a web form.

The business requirement stated that the Due dates should not be greater than the Requested End date. The number of Due dates fields were dynamic in nature and could range on an average from 5 to 50 fields.

The solution from the developer's perspective was to allow the user to select any dates in the Due dates fields, and show an error when it exceeds the Requested End date.

Here, the developer's philosophy is to

"Handle errors when they occur"

The design solution proposed was to disable the Due dates until the user specifies the Requested End date. Once specified, the Due dates are enabled and the date picker should not allow selecting dates beyond the specified Requested End date, effectively avoiding any error scenario.

Here the designer's philosophy is to

"Avoid errors where possible, Handle errors when they occur"

This helps avoid the error, but it also increases the amount of checks and validations that the developer has to work on, effectively increasing their work pressure. There is a natural resistance from the developers to accept this solution.

Despite having handled the error for most cases, there was one scenario where a user could modify the Requested End date after the due dates have been updated, resulting in some of these Due dates to be in error.

The developer's response - "Let us reset the Due date fields which are in error, when the Requested End dates are modified".

The designer's solution - "Let us highlight the fields in error and add a section level error message informing the user of the same."

The solution identified by the developer was keeping in my mind, the simplest and the fastest way to technically tackle the error. However it fails to capture the needs of the user. The user would want to know which fields are in error and what their current values are. This empowers them to make a choice, whether to modify the Due dates or update the Requested End date. Simply resetting the fields in error would not have helped the user to make an informed decision and thus would have impacted their experience.

In their attempt to focus on the higher priority ticket - to deliver a functioning product within time - the developers ability to empathize with the user needs are severely limited.

"Empathy is key to understanding and resolving the user needs."

After due persuasion the Dev lead agreed to make the additional changes. However it does not change the fact that they had to work extra to allow for these cases.

It is critical that all stakeholders are educated, in order to make them understand that the focus of a project should not be just to deliver a working product (which is the case most of the times), but to ensure that the 'needs of the users' are addressed, while doing so.

This requires a change in mindset - to unlearn what they have learnt over time, and to allow for new concepts to hold roots.

"Your mind is like a cup filled to the brim."

This is difficult, if not impossible, in a live-project scenario, where time is of essence. However conducting UX awareness sessions at the source, where budding developers, project managers, business stakeholders learn their crafts and tools of trade, where they have an opportunity to take a pause and look beyond their curriculum and 'see' the user, where their cups are not filled to the brim.

One way to make this possible is through industry connect events, where organizations can 'give back' some of their time and knowledge to these centers of education, which spawns the the next generation of creators.

Over time we shall see a natural tendency from the developers to empathize with the users, and cooperate to make life easier for the 'user', from the business and project managers empathize with the users and to allocate more time required to make it easier for the 'developer' to do so, which in turn shall hopefully simplify our roles as 'designers'.

---------------------------------------------------------------------------------------------------------------

The author is an UX consultant working for a reputed multi-national software development company, with around 23 years of Design experience, covering a range of domains, from User Experience design, E-Learning, 3D Visualization, to Architecture Design.

You can follow him on Twitter @jadhavanchi to stay in touch with his random ramblings on Design, Privacy, Technology and Experiences in life.