How to scale #UXEngineering, with Maxime Sarri (Google)

This article includes key takeaways from Maxime Sarri’s talk on how to scale UX engineering. Check out the full video on Youtube or get the latest from our Scale series.

2 key mindsets

Mindset #1: Bridging the gap between code and design

UX Engineer is a new title. It includes many terms like Interactive Developer, Front-end Developer, Graphic Coder, or Creative Technologist. It describes a hybrid profile that blends coding skills with product design. And companies are starting to understand the value they can bring to a team and a product. Google is one of the first to have done so in a structured way: bridging the gap between Google’s history — engineering and code — and it’s purpose — building meaningful experiences across the scope of it’s products.

Mindset #2: The devil is in the details

UX Engineers are focused on details. Loading animations, click interactions, scroll fades — on desktop and mobile — are some of the key elements on the UX Engineer’s palette. The goal being to create an experience that “flows”: whether they make the interactions between the user and the product more playful, more beautiful, or just more logical, the main objective is to polish the details that help keep the user more engaged. As Maxime puts it: he polishes details that the user may not notice, but take those details away and the user will notice that something doesn’t feel quite right.

4 key best practices

Best practice #1: From linear to cyclical

The old way to ship a new feature went something like this: first someone gets an idea, then there’s a meeting to discuss the idea, then the team works on the idea until it’s ready to ship. Sprinkle in tests to taste. The problem with that process is that it creates a form of inertia: once the team has committed to a project and expended time and ressources on it they are reluctant to not carry it out, where in some cases that would be the best solution.

To counter this, Maxime offers a cyclical process to work on new features, incorporating prototyping and UX engineering in the early stages to make iterations quicker and easier on the team. His revamped process goes as follows: after someone has an idea, start prototyping it with a designer. Include other teams in the discussion. Test out the prototype. And repeat until the prototype is ready to convert to production code and be prepared to drop the idea if the prototype isn’t successful.

Best practice #2: Make it personal

No two designers work the same. When you start working with one, get to know them. How do they like to work? What level of interaction do they need? At what point in the process? Getting to know the designer and adapting your processes to theirs will keep things running smoothly through the short, iterative cycles that Maxime encourages teams to adopt. Also, it helps improve communication which is detrimental to the success of a team — no matter how big or small.

Best practice #3: Create alignement

Everybody has ideas. What matters is being able to communicate them effectively to the rest of the team, while avoiding to stall everyone’s productivity with meetings. For Maxime, the best way to achieve this is to create a group of participants that includes all the key skills that will be necessary in the project. This helps narrow down a potentially long list of ideas and focus on the key features that everyone agrees are priority. It also helps create alignement between the different functions and work with greater confidence in what is being done.

Note: Maxime highlights the role of Product Managers as owning the overall vision for the product and following up on all the component parts to deliver on the roadmap. Their role is complementary to UX Engineers, as they hold the macro view of the work put in by all the different teams in the project as well as continued alignement between them.

Best practice #4: Run tests continuously

For feature tests that exceed slight changes to the layout, Maxime recommends using the prototype to run split tests. Running tests on actual production code is slower and costlier. It’s slower because teams can’t iterate as quickly on production code due to larger volumes of code to be compiled. It’s also more expensive because running tests on production code means actually producing production-quality code. Maxime also recommends keeping a lean approach to testing as this helps generate feedback on the early stages of a feature development cycle, rather than at the end when extensive time and ressources have already been committed to the project.

Subscribe to be notified of the latest Scale talks.

About Maxime Sarri:

Maxime Sarri is UX Engineer at Google Arts & Culture. His work helps museums make their collections available to audiences around the world and present their works with context. Maxime shares his tips on how engineers can build interfaces that empower meaningful experiences and how to use code to build storytelling, at scale. Follow Maxime on Twitter.