Three UX principles to humanize engineering

A common engineering approach to user experience (UX) focuses on the systematic interaction between the end-users and the product. How will they get from A to B? And what are the edge cases in between?

But in today’s world, this doesn’t fly, prospective customers rightfully expect so much more than to just execute a given task. They want to feel connected, augmented, and empowered.

A truly awesome UX is achieved, not only by designing and building tightknit features and flows but by focusing on the endgame first. What are your users trying to achieve? Why have they selected your product to be their weapon of choice? How will they feel when they accomplish their goals and more importantly, what about when they don’t? 

This means to deliver a truly meaningful and impactful experience, engineers need to take a user’s lens.

In this Snack, we build on our ethos that everyone’s a designer. We offer 3 principles every engineer in Nory leans on. The purpose being to try to humanize our development efforts and enable us to better delight our users and choosers alike.

#1 Engineering and UX <-> Two sides of the same coin

It doesn’t matter if you are front-end, back-end, or end to end – whatever part of the stack you are building you are going to impact the end user’s experience. Irrespective of the levels of (perceived) abstraction between the UI and the layers of microservices or code that you’re working on.

Incorporating regular UX discovery sessions into the engineering calendar helps the entire team to better understand user needs. This empowers the team to make smarter decisions across the stack: from more efficient API designs and database structures to building outcome-driven machine learning models.

At Nory, we make sure every feature development undergoes a user story mapping session (read more about story mapping here) with our team of engineers and designers. This helps us understand our customer’s end game in great clarity; thus enabling us to better prioritize trade-offs, unearth technical complexities early, and have high confidence in our technical design before we start the build.

#2 You’re architecting an experience

Software architecture is not just about two-tier vs three-tier architectures or jargon-led cloud offerings. Understanding the intended user journey and identifying user personas helps prioritize mission-critical architectural decisions and focus on real edge cases or run-overs.

The experiential treasure to guide these decisions is buried under bundles of user research interviews and recordings. These provide ample opportunities for an engineering team to understand and predict user needs and feature requests. This connection to the endgame helps massively in structuring a system architecture that has scope for rapid scaling and adaptation to change requests.

#3 Empathy is your plotline

An analogy we lean on is that our software engineers are akin to movie producers who need to empathize with their audience. Why? Because if you can’t resonate with your audience, you won’t be able to create quality content that keeps them entertained and engaged throughout your movie.

As a developer, you need to empathize how a user feels when they utilize your specific block of code to try and overcome a challenge. Because every problem, after all, is a customer problem.

Principles in practice: My journey from the restaurant floor to the codebase

Recently, I had an opportunity to tag along with one of our designers to visit a customer. They are a busy fast-casual restaurant chain. Aside from sneaking in a juicy burger, the goal for me was to observe how these users engaged with Nory during the restaurant’s peak hours. How did we help or hinder them? How were they feeling in the moment? What type of environment were they working in?

It was a busy day for this customer meaning; multiple transactions a minute with high throughput, high time pressure, team members interacting with multiple devices to get from order to delivery, and a need to coordinate cooking preparations and customer engagement simultaneously.

It was incredibly insightful to discover the different devices needed to get through the day and their screen sizes, operating systems, and internet connection speeds – all in a single location belonging to just one customer.

Combine that with the realities of working while you move, being under a recurring stopwatch, and having no space of your own to execute key operations. The environment in which the customer used the various tools and products told an incredibly immersive story. I could feel the joy when things went smoothly and the pressure and the angst when things slowed down service.

I hadn’t grown up working in restaurants, just eating in them. So for me to try to emphasise with our customers through secondary research alone was never going to help us build an impactful product.

The following week, when I was building a new feature, I could position myself on the very same restaurant floor and incorporate my learnings – making sure that the feature could cater to the all-go environment. I’m certain this will be a habit in all of my future architecture designs or CSS styles – and I’m looking forward to the next site visit (and burger) already!