User Experience: Mind the gap
In a world where the only constant is change, technology and all of its advancements can easily complicate or simplify a business or a product's journey. The digital world is rapidly merging into a monolithic machine where there is little difference between online and offline. Customers or users, an expert or a novice - we are constantly faced with problems that require new and clever solutions.
In this article, I will define, in my opinion, one of the most important aspects to any digital solution: The user experience (UX) and the gap that currently exists between the designing and developing of these experiences.
As developers, designers and engineers, we are tasked with solving these problems by building applications and systems that are simple to use, easy to access, with high performance and secure and scalable. As time goes by, there have been many different ways that teams and organisations have approached building applications, whether they be technically driven, design-focused or navigated by a workflow or methodology and framework.
Generally speaking, these applications consist of a few layers that its users sit on. Namely the User Interface (design), Front-end (development, or implementation of said design), Back-end (Server/API/Database/Logic Layer), and a layer of DevOps/Infrastructure. In essence all these layers are responsible for creating the User Experience, and in my opinion each layer or contributor has an important role to play in creating this tailored experience but in many cases the 'UX' is applied as its own layer and has its individual or team that takes responsibility for it, whether it be a UX designer, stakeholder, or product owner. This tends to create a gap and a divide between all the parties involved.
Note: I'm not a fan of 'slashing' roles, but to keep this to the length of an article and not a book, I am sinning by grouping the various back-end and DevOps layers with slashes.
So how can we bridge the gap between design and development?
"Everyone is a UX expert" – So let's make sure it’s everyone’s concern.
This quote is often delivered with a negative connotation. I disagree. Everyone is a UX expert in their own right. After all, we've all used, and abused applications for quite some time now. Let’s use this to our advantage and make sure everyone is considering the user experience.
Wait, what? One of the advantages of a true agile workflow would generally mean that the UI Design, the UX design, the front-end development and the API all kick off at once. This may feel like an unproductive way of building software because naturally, one would think that there would be a bottleneck somewhere within the team.
How can the development start if there are no designs to work off? In that lies the beauty, with designers and developers (both front-end and back-end) being, for a lack of a better word, forced to work together. This way, the knowledge and creativity from developers and designers can be placed together to build working solutions every step of the way.
Rapid prototyping in the browser can be hugely beneficial as designers will be able to immediately provide feedback and vice versa. This creates shortened feedback loops, and shared knowledge that can help shape better solutions.
A designer’s skills should not be limited to Sketch or Photoshop. Yes, a picture tells a thousand words, but sometimes a great design simply needs words and communication to create a great "vision". API data structures and how or what the data should look like can be of huge benefit in the early stages of implementation. Of course, this is easier said than done, as there could be a disconnect between individuals. However, designers can also make use of realistic prototypes to provide developers with the application's look and feel, without spending too much time early on creating high fidelity mockups that may or may not be possible due to technical reasons, skills, budgets or time.
JSON structures can be provided early on through contracts to ensure less back and forth at a later stage. In my experience, while the world kept punting that designers should understand development, developers should also take the time to understand and respect designs. When we are at a level where we understand each other, it will be easier to build better solutions.
Communication and Collaboration
By working closely together, designers and developers learn to trust one another and pick up on each other’s language and points of view. Learning to compromise and respect one another's decisions allows for more overall input on the products we build. Remembering more questions early on can result in fewer hassles at a later stage.
Designers should take the time to explain their designs and the reasons behind them, allowing the developers to understand them better. In return when a developer explains the technical or time constraints to a particular design, it allows the designer the opportunity to think of an improved solution that may be better and less complex and time consuming to implement.
I've run into many scenarios where something that could have taken weeks to complete was resolved by simply changing text or the position of an element in a certain component. Think of it this way: If the entire team knows that we are tasked with creating a masterpiece - but we only have a pencil, it will ensure that everyone thinks of the best practical solution to spend their time improving and maximising the achievable gains rather than use imaginary colour crayons that aren't going to be available in the constraints of the project. It's a learning experience that will take time to get right, but once done, it'll only improve.
Make use of a 'User Experience' and 'Front-end' Architect:
As with any other titles in technology, the user experience and front-end architect is similar. There are many definitions of what they are expected to be. Are they designers or developers? Researchers or implementers? For the sake of this article, I am using the terms loosely.
Generally speaking, the user-facing functionality of an application is the responsibility of the front-end developer, who implements the designer’s vision and needs to be the voice between the back-end and the designers. The front-end developer's responsibilities have grown enormously over the years, and the skills that they need give them a wide range of understanding of design, data, structure, content and functionality. As applications become more complex, and technologies improve, we find that unicorns do exist.
With experience in the field comes domain knowledge. I believe that designers and developers with the right experience can position themselves perfectly to be the link between UI design, UI development, back-end, and ultimately the overall user experience. A combination of front-end and UX architect, in my opinion, would be beneficial in a large or small organisation where there is a disconnect between business requirements, technical implementation and visual design. As an example, when a solution architect is primarily focused on the technical complexity, and the lead product designer is primarily focused on the result. A middle layer between the two that understands both of their languages, point of views and concerns can be of benefit. Microservice design? What?
But with this set of 'unicorn' skills comes a certain amount of responsibility - preferably someone with this skill set should focus on the high-level overview of the application and contribute to the overall design, development and user experience of the application as this is where their skills would benefit the organisation most.
Rapid prototyping and quick iterations are always beneficial, but what if it's a large enterprise solution that is similar yet worlds apart? In the world of finance, for example, different products may seem very similar, but by paying attention to little details, and by taking the user's objectives into account, do we understand the complexity of the product?
The truth can be applied to eCommerce when someone understands the psychology and in-depth knowledge to grasp that small yet complex or simple changes can encourage a user to make a purchase. In this case, the need for an architect to oversee the technical infrastructure and the design system can be very useful. It allows for a pattern to be created, identifies limitations and complexities for multiple products or applications, while the designers and developers on the ground can focus on innovating and enhancing the base solution. The architect would focus on the foundation of the user interface designs of the application by implementing and making use of:
- Design systems
- Component library
- Build tools and infrastructure
- High-level overview: i.e. as back-end developers usually follow the architect’s rough plan, the UX/Front-end architect would have a high-level viewpoint and blueprint for the visual component of the application
- 'Foreseeable unknowns'
- Soft skills
- Great communication and empathy for all stakeholders involved (Engineering, designers, product and business)
My take on the vertical split of UX/Front-end needs
“A little bit of this, a little bit of that, and maybe, just maybe we can create usable unicorns”
The Rise of the UX Engineer
But what if I need more unicorns? Well, the role may not be as mainstream or as popular as its well-known sibling, the full-stack developer. The need for a UX engineer has become extremely vital to organisations and teams of all sizes. Just as systems architects need an army of engineers to build out the blueprint, in the future so will a UX architect. With the increase in importance and focus on AI, machine learning, voice, conversation, chat and gesture inputs, users will soon be faced with new user interfaces that may or may not have physical touchpoints.
If anyone reading this remembers how different screen sizes and browsers (cough responsive design, cough mobile-first, cough) shook up software development and design (side note: it's more of a present tense than a past tense, as much as buzz words would like to move onto the next big thing), then the implications of the next wave of 'interfaces' is going to need a whole new approach and way of thinking. (See Design Thinking)
What is a UX Engineer?
With that being said, a UX engineer should have the ability to turn the design language into a live, usable component library using vanilla JS/CSS or at least one popular framework or library - To implement the production-ready style guide for the design system, and create full-blown and rapid prototypes using the above-mentioned component library and design team.
The UX engineer should be able to easily communicate with designers and engineering teams and promote a healthy working partnership between the two. They should have a firm understanding of UX principles and how and when to do certain things. I'd argue that the need to be able to 'design' UI's in static or demo forms is neither here nor there as a UI can easily be designed in Sketch or the browser right away. It simply comes down to preference and tools:
- UX design skills
- UI design skills
- CSS frameworks
- Basic build tooling
- Basic testing
- Design patterns
- Package managers
- Basic Node.js or understanding of one back-end language (understanding, not command or advanced knowledge)
- Be able to build products end to end
I've come across various definitions and explanations of a UX engineer, but I think the easiest way to make sense of it, is with a quick comparison. If a full-stack engineer is a front-end developer that has strong front-end development skills and back-end development skills, then a UX engineer is an individual with a strong understanding of UI design, UX design, and front-end development.
In time, I think that having the skills to communicate effectively with both designers and engineers will allow for the field to flourish, as this will encourage both designers and developers to step into new arenas, whilst bringing all their old skills from their current comfort zone. It's the perfect crossroads, giving each party a massive advantage for not only their role but for their company and future too - which in my mind is a win-win situation.