UX: everybody’s business!

It seems logical after all! A useful, functional and powerful product is a perfect blend of design and tech. It’s a whole project team guaranteeing the user’s experience and the quality they perceive. This is why a service centre is the perfect place to put this type of approach into practice, where you’ll find stable teams, generally strong team cohesion, and the willingness and opportunity to innovate.  As key UX contact at the SQLI Innovative Service Centre (ISC), I have the opportunity to work with the development teams on a daily basis. I’d like to share with you my thoughts and a few best practice ideas concerning projects.   

Separating technical design and UX design can be dangerous 

Who’s never had to go back on UX design decisions during the course of a project for technical reasons? 

• User journey review 
• Model modifications 
• Technical reworking, potentially leading to reduced functionality. 

This is often the case when the UX design and technical design are done separately, without synchronisation, or with very little communication between the two teams. This is known as a “Waterfall UX” strategy. 

Image via https://medium.theuxblog.com/the-ux-what-now-41c6e7fdff31 

But it’s still a common way of working which can, ultimately, prove ineffective and tends to generate tension both within the team and with the customer. Don’t get me wrong: the idea isn’t to blame one of the two teams, but rather understand why it didn’t work.  In many cases, defining the need doesn’t lead to the launch of the project. Agility is actually recommended to build projects based on changing specifications. So customer satisfaction comes from the team’s ability to help define their need, which matures as the project progresses.     

Agility, a user experience-centred approach? 

Preconception 1: agility only applies to functional specification and technical specification of the need.

The Product Owner’s defined needs change from the beginning to the end of the project, based on the definition and prioritisation of the product’s specifications. New needs emerge, both technical and functional, but also in terms of security, performance, user journey, etc.   

Preconception 2: It’s risky to start sprint 1 before all the UX design decisions have been made.

Sprint 0 features necessary and sufficient stages to prevent subsequent development from being disrupted by fundamental decisions. UX approach decisions, particularly the graphic charter, are often integrated into this preparatory phase (Waterfall UX). However, it’s advisable to start with minimum hypotheses, as initial customer feedback is more important than fully setting out a journey, which will inevitably change fast. Regular readjustment during development is far better. This is what is known as Agile UX.    “Responding to change over following a plan”   (1 of the 4 values of the Agile Manifesto)    With this in mind, we are progressively adopting an Agile UX approach on projects. As an integral member of the team, I get involved according to the development schedule (3-week sprints). I work with the Product Owner and team, synchronise my actions to develop/adjust journeys, Human-Machine Interfaces, and prepare the inputs needed for the sprint planning. Genuine collaborative work!  On a portal project, the customer and whole team found that this approach offered plenty of advantages. We also set up a library of reusable front components (design system) as well as an ergonomic charter to facilitate the work of developers and testers, and guarantee the site’s uniformity.      

 

Collaboration between design and tech from start to finish of the project

In this type of approach, the key UX contact is not merely involved in creation: 

• They teach the team about user-centred design and ergonomic principles 
• They play a facilitating role as regards the team, which becomes a stakeholder in the construction of the user experience 
• They help the team to assist the customer with defining their need 

In practical terms, everything starts with sharing the vision with the customer. At this stage, it’s the whole team that contributes to need scoping (or product scoping), the first building block that will enable the team to start work on the technical design.  If user interviews (or another research activity) are planned, it might be worth inviting one or two developers as observers. This will enable them to better understand the use context and needs to choose the appropriate technical solution and quickly deliver value to the business.   During the design phase, participative design workshops are also a good way to reconcile Business and Technical issues. The purpose of this type of workshop is to define, prototype, test and approve or reject functional proposals even before coding begins. It can also be used for team building and to enable establishment of a relationship of trust with the customer.  Finally, after each sprint or release, the team (including the customer) debriefs on user feedback and if necessary reviews priorities to continue to deliver value.  More generally, from start to finish of the project life cycle, the key UX contact works on the design for upcoming sprints, and reviews the current sprint. They play an advisory role regarding ergonomic issues and assist the team with implementing the user-centred approach.    So we have successfully begun to increase collaboration between Design and Tech by putting together a committed team sharing the same objectives. The teams know about UX and more easily adopt a user-centred approach. Customers are generally satisfied with the approach.  With this strategy,  

• Customers don’t get frustrated as they aren’t shown journeys or models that will ultimately not be implemented for technical reasons 
• We promote development work  
• We work with the customer from start to finish of the project 
• We create and deliver value more quickly  

In short, UX is everybody’s business, the product’s success relies just as much on communication, synchronisation and team cohesion as individual skills and expertise.