UXE or how to engineer design
Keeping the value of the end-to-end project: the role of the UX Engineer in Sketchin between design, technology and delivery.
We should be honest: we love the design and beautiful, smart and polished design projects, but in the end, the reality stays elsewhere, in the people’s experience, and people want to live experiences beyond their expectations no matter how beautifully a project was conceived. A poor outcome of a brilliant project disappoints people and hurts the brand that offers it.
In other words, the quality of a product or a service should be cared for from conception to delivery. Every step counts to shape the experience lived by the users.
In our experience, the most significant issues arise in the no-where land between design and development when a project is translated into an actual product and the envisioned experience made real. In this crucial phase, something usually gets lost or is misunderstood just like in the broken telephone game we played when kids.
“When designers do get more power than their developer counterparts, they build weaker products” — John Maeda
And there is no fault in this compromised communication chain; it is a matter of sensibility and skills: designers and developers have different skills and do not think alike. Moreover, developers face countless design decisions which are left uncovered by designers.
What a UX Engineer is
Google was the first to create the role of UX Engineer towards the end of 2014; the following year, Sketchin also integrated these skills into the design line. It was clear the need to humanize technology and use it as a foundation for the design for experience.
According to Google, a UXE is a technology advisor and a prototyper with strong knowledge in UX design, whose goal is to help UX teams to design possible user experience and support clients’ dev teams to understand and prioritize product development correctly and to maintain a high end-to-end quality product.
But actually, a UXE is more than a bridge; he should merge the two worlds seamlessly: engineering the experience and, at the same time, making micro design choices during the design and coding process to ensure the overall quality of the delivery.
He or She is not just a designer or only a developer, but he profoundly understands both and makes them communicate efficiently.
Finally, a UXE is also a technologist: he understands the opportunities and constraints that technology introduces.
Design and technology are interdependent.
We shall go a little further. It is a truth universally acknowledged that design and technology are strongly entangled: the first exploits the second discipline to create useful, enjoyable and desirable products.
This statement implies that a designer should understand the technology opportunities and how to make the best out of them when shaping superior experiences.
However, experience teaches us that solving complex problems is more comfortable if they are approached with a variety of skills. Let’s say for sure that T shaped designers compose our teams. The technological know-how takes the same value of more known disciplines such as interaction design, visual, copywriting.
A person who benefits from service, both through a touchpoint on screen and within an analogue and human context, probably uses some digital enabler. A data saved and recalled at the right time, a quick and transparent transaction, a calculation of an algorithm: these are all elements that fall under the technological hat and have profound impacts on the processes and the perceived quality of the experience.
Taking care of the engineering aspect of a project also means, and we know how important it is, bringing concreteness, feasibility and respect for budgets.
Tools and Skills of a UXE
Aware of the fact that the technologies with the most significant impact on the user experience are the most disruptive, we decided to focus our know-how on a few specific areas to ensure the most significant added value in our design. We can’t know everything, but we can learn some things well.
The most crucial tool in the hands of a designer/engineer remains to understand. Understanding the implementation details of a new framework, understanding the limits and possibilities of a given architecture, understanding the main functions of an SDK and how they enable better experiences.
The vast majority of projects that result in implementation have in common that the touchpoint is digital, often a screen.
Hence the choice to invest in the know-how of web framework and smartphone applications. In the same way, we believe it is essential to continue to experiment and touch the still young but already consolidated voice interfaces and increased realities, for example.
A UXE, moreover, masters at least a couple of programming languages, and with them can learn the fundamentals of others.
It is true that to realize something, you need to know the tools that make it concrete. Still, it is equally valid that most consumer technologies gravitate around similar languages, similar schemes, shared bases. For this reason, a UXE can empower a design team by translating technical documentation into design possibilities.
Where is the UXE in the design and development process?
As already mentioned, engineering practice is halfway between design and development. But let’s go further.
Analysis and automation skills are also valuable within Operations. As design teams grow in number and project complexity increases, so does overhead on production. To maintain the concentration needed to continue delivering value, teams must delegate operations to another unit — Design Operations.
Within the DesOps landscape, therefore, a UXE can contribute by identifying, with an analytical mind, process optimizations and possible automation. For example, we think about the versioning of design artefacts, identification and setup of the most suitable tools for design and handover to development, rationalizing decision-making flows, creation of the Design System. In other words, all the most engineering and rational part of Operations.
On the other hand, the practice of UX Engineering must be able to interface with those who govern the development sprints. Often you see developers waiting for the design or complaining that some assets are missing or that it is not clear what is designed. Engineering processes (DesOps) and supporting the design in delivery is also the task of a UXE. It fills that natural gap in delivery steps.
A UX Engineering team must therefore work as much as possible on a continuous flow (kanban for example) to interface with different, sometimes asynchronous, sprints and planning. Planning requires fluidity and resilience, as well as strong communication and the ability to handle the priorities of the various projects.
Roles and duties of a UXE.
So UX Engineer is a critical figure in the entire design process, from the design strategy to the production. There are four main scopes of its work:
Design engineering
Iterative and incremental design based on imperfect and impermanent artefacts (while remaining extremely effective in achieving design goals) often requires additional intervention before going into production. Engineering design means just that, that is to do that action of reclamation, abstraction and rationalization to extract the essential components, the foundations, the UI components and the rules of interaction. These activities often take the form of a Design System (or Library).
It creates consistency and consistency, i.e. it limits back and forth with developers and reduces design discrepancies.
Design empowerment
What if a UXE is part of the team even during the design strategy, research or product/service evolution phase? It would bring the point of view of the developer, help to understand if some pain is due to technological frictions or bad design, to push the design strategy towards feasible and compatible with implementation budgets. This type of healthy contamination represents an added value for both the client and the users. It limits the possibility that the project will end up in the drawer of beautiful but unrealizable things that are in the desk of each client. UXE, therefore, works on the same level as an interaction or a service designer, bringing its verticality to the project.
Design OPS
As already discussed in the previous paragraphs, the Design Ops aim to create the correct workflows and method to enhance the design and development phase. The DesOp approach provides the most suitable tools, systems and practices to enable the realization of a scale project. It strengthens the foundation of design practice.
Considering that automation is already permeating the design of projects, methods and tools, the role of the UX Engineer as described and conceived in Sketchin is fundamental in this scenario.
In practice: UXE is a permanent part of the scrum development team, bridging the design and supporting the developers.
Proof of concept
From the idea to the result, anything can happen. It is better to identify in advance a terrible idea before it turns into an equally frightening reality.
Development skills are translated into concrete representations of an idea of a concept. Similar to prototyping, the creation of a POC exemplifies the feasibility of a solution. They are small demos to answer the question “can it be done?”.
In practice, it is a matter of building the real frontend artefact ready for production where, however, data sources and services are not yet integrated. They are based on conventions and example data tracking to simplify the integration process.
As an example, a POC can take the form of a chatbot, a sandbox to test an algorithm, a structured data collection, an app that exemplifies geolocation logic, a link between data source and data visualization, the set of notifications behind a transaction, biometric authentication…
Mocking up
When the quality of the experience is intrinsic in the realization of the touchpoint, one can go as far as the actual realization (sometimes fictitious in the data and disconnected from any service layer or backend) to exemplify the implementation quality that is expected. By making a part of the frontend, for example, the UXE sets the quality benchmark of the interaction and performance of the finished product.
Together with the developers then, you compare to transfer this value to the rest of the product or service.
We can easily imagine a future where we can design prototypical user interfaces by merely talking to Siri, Google Assistant or Slack embedded bot” Andrew Shanley — Creative Director @R/GA
In this new perspective of hybrid continuum, where the concept of omnicanality is radicalized and where people expect to enjoy products and services seamlessly between physical, digital, virtual and cybernetic contexts, the figure of UXE takes on additional relevance. Indeed not the role itself, but for its ability to preserve the coherence, value and integrity of the experience lived by people,
