Effective UX & Back-end collaboration

The internet has seen an explosion of publications about better collaboration between designers and developers. I decided to extend the discussion by adding a collaboration type I could not find any publications about. The collaboration between designers and the back-end engineers — architects and coders. Not about the collaboration between UI designers and front-end developers.

Developers are also designers

Any decision that is made by someone that affects how the item being created looks or functions is, by definition, a design decision.

Many back-end engineers are not only coders. They are also designers — people who imagine the new. (Some even have it in their job title — ‘architect’.) It is just that their ‘new’ is not the user interface and interaction. In this article, I write about the engineers who design the technical aspects and engineers who code and for sure who design and code.

Complexity requires specialisation; specialisation requires collaboration

What caught my attention is that most of the articles call for total shared understanding. I disagree. We have specialisation for something. A total shared understanding of all aspects that together form software is humanly not possible. And if it is possible, then the complexity is so low, you do not need a team. At WeAreBrain we do not work on such simplistic software products. Therefore, we are bound to teamwork between different specialists who will not have a total shared understanding.

The goal of the collaboration is to reduce the number of design and development iterations to a minimum.

What we can and should do it to improve our collaboration. I see three elements in this: Communication, Creation, and Evaluation. And an important Bonus — Comradery :)

Prerequisite — respect!

No process or tool will work without mutual professional respect. For my designer colleagues, being a software engineer is a complex job that requires continuous learning, comparing to which our learning of new tools and trends pales. And for the engineers — in the way to thinking, designers are actually most similar to you comparing to other professions in IT. Do not let the designer’s different tools of the trade fool you.

Communication of design intent

Designers have many different ‘receivers’ of their communication. Customers and their stakeholders, users in usability testing, other designers, copywriters, marketers and of course, all types of engineers, including the testers. I have not found one communication method and deliverable to serve them all well. Sad, because as a designer I want to focus on designing the product for just one audience — the users! And I spend most of my time communicating my design to all people who stand between my ideas and the user. Well, that’s the job of a designer. It is less about the design as about an effective and convincing communication about the design.

So, what do designers need to communicate with the backend developers? Generally, these are the data structures and the system behaviors including the speed of responses.

UX Prototypes

For the interactive products, it is always better to ‘show’ and not just ‘tell’ how it works. Interactive prototypes are not only UX designer best tools for actual design, but they are also helpful for communication to the engineers. However, the prototype often falls short in communicating the intended logics and could be difficult to navigate as most UX prototype are not fully functional without communicating by itself what is left out. To add the narrative to the show, we use the written/drawn specifications.

Design Specs

The visualization of the user interface, even in the most interactive prototype is simply not effective enough. Yes, some developers will say that a mock-up is enough. It would be enough for them to reverse-engineer the data structures and system behaviors. In my experience, if you deliver just the user interface prototype (or even worse — a static mock-up), a lot will be lost in translation. So, I do believe in usefulness design specifications or ‘functional design’. I believe that specifications as text, models or recorded video walkthroughs are as part of design work as the user interface mockups and prototypes. For the objection of “developers do not read” I have an answer that they do not read the specs as literature, but consult them when needed. It is a must to provide exactly what is needed at the moment and the place developer will work on this specific element. For us, it is now Jira. We do not document in Jira because of its temporal nature of the tickets. We add deep-links in Jira tickets to all specific parts of the design documents in Confluence, AxShare, and Zeplin (for the front-end). The Definition of Done in the ticket describes which piece of the deep-linked documentation is in the scope of this ticket for this sprint.

While UI designers got greats tools to communicate to the front-enders like Zeplin or Craft Inspect, there is no innovation supporting communicating design to the back-end developers for the websites, apps or chatbots.

So far, I’ve written about designers communicating to the back-end developers. Communication should go both ways to be successful, also from engineers to designers.

Engineers should provide input before the start of design work:

Existing technical limitations and surprising powerful capabilities.

• I’ve never experienced this explanation from a developer. I guess it is because engineers do not know what could be interesting for UX designers to know. The answer is: “everything that can influence a user”. So, dear back-end and CMS engineers, please offer to show the tools to your UX designers. We are interested!

Common concepts and terminology.

• Each platform or technology has its own concepts and terminology. To create a shared vocabulary, please do use and explain typical terms like a ‘node’ in Drupal or an ‘utterance’ for chatbots. Again, I never experienced a proactive ‘education’ from an engineer but learned a lot from observing the demo’s of the tools or being present during technical discussions between engineers.

After the design has started to take some kind of shape, engineers should quickly give feasibility feedback. See more on this type of communication — evaluation, later in the article.

Creation

‘Creation’ is a synonym or ‘design’ and a synonym of ‘implementation’. So, designers and engineers are all ‘creators’.

‘Design’ as a transformation of abstract ideas in the form of a tangible product and ‘implementation’ as the realisation of this form in its material. In most design professions there is still a separation between ‘design’ and ‘implementation’ tools and processes that lead to the separation of professions between designers and ‘implementers’. It is still in the software industry.

Designers create solutions based on the input — requirements, trends, patterns, technical capabilities, etc., including our own tastes and biases. The obvious participation of the engineers is to inform the designers very well about the various technological aspects. But is it not the creation. This input is part of Communication which I already mentioned.

Collaboration in the Creation I see as collaborative work sessions and documents in which we actually overlap.

Example of overlapping elements and possible topics for the collaborating creation sessions:

• Project vocabulary — definition of the terms used in the project. Created and updated together
• Translating business domain models or user mental models into the basic data models. Led by UX designers. It requires engineers to be patient with illogical world views or users and businesses. We could use Event Storming technique for this.
• Behavioral and structural diagramming together (use cases, interaction overview, objects, classes). Led by software designers (architects, engineers). It requires designers to speak the UML and XML/JSON. Results in the documentation that is created and updated together.
• For CMS-driven websites: Defining taxonomies and content types. Results in the documentation that is created and updated together.
• Defining and naming roles and their rights for multi-role systems
• Learning by stealing — checking important competitors for design and technology patterns. Shared facilitation. Results in a shared understanding of ‘industry standards’. (and stop comparing to Google if we are not competing with one).

Evaluation

Evaluation by developers

I see the tremendous value of feasibility evaluations of design proposals by the engineers as early as possible. Feasibility evaluation should be face-to-face on a draft version that should be easy to change based on the feedback. We structurally use our refinement sessions for it.

Tip for the devs: leave your ‘everything is possible’ mantra at the door and use the context of this project — budget and time when evaluating for feasibility.

Evaluation by designers

As I’ve written, I believe that designers should test the delivered software they’ve designed. So ready for testing should be first ready-for-testing by designers. Actually, it is better to demonstrate the working functionality or even data structure as early as on the local machine to the designer to get the feedback face-to-face and decide what to do with it — fix or accept. In such personal demo’s designers are also more forgiving and flexible :) And you can explain that missing elements are missing not by mistake.

Camaraderie

And while on our computer screens you rarely find something similar and our jokes rarely overlap, I found a company of engineers most gratifying. UX designers and engineers have more shared in any software project with a UX component that you think — seek each other and expect a lot from each other.

Designers, do invest in building productive relations with the engineers and they literally will make your dreams come true!