User Experience Design Beyond the Interface
Why usability, user testing, and partnership with UXDs shape products far beyond screens
I once sat behind the glass in a usability study. I was the lead in building the service being tested. We were studying whether the product we put together made it easy for our customers to solve their problems. In a typical usability study, a participant who has never used a product before is given a task, and builders watch them live as they try to use the product. In this case, it was clicking through buttons in the console and moving between pages. The goal was to see if the product communicated how it should be used, in other words, how intuitive it was.
I thought the user interface (UI) we put together was really great. It looked sharp. I was the lead engineer building the service behind it, and I had also been involved in shaping the concepts and UI flows during design sessions. At the start of the study, I was fully confident that users would complete the tasks with ease. Instead, I watched participant after participant click the wrong button, land on the wrong page, and fail to complete a task I thought was straightforward. It was an eye-opening experience for me as a software engineer.
People who build products, such as engineers, product managers, and applied scientists often get too close to them. What feels obvious to us may not be obvious to others. This is a blind spot user experience designers (UXD) are trained to avoid. Watching those participants, the UXD helping us was not surprised at all. For them, it was another day of gathering user feedback to refine the design.
Reading the usability report later, I learned something else. Users were not only confused by the interface. It was not just that a button could have been named better or placed differently. Some of the concepts we created as part of the data model were not intuitive. Users did not expect to create another resource and attach it to the original one for it to work. It was like renting someone a car, and expecting them to check the fuel first before they get in and turn the ignition on, while they expected the car to already have fuel. So they missed an unintuitive step, and the car did not start.
Until then I thought UXDs helped with UI while engineers defined the data model. Through that report, and follow-up conversations with our UXD, I realized they are trained to ensure the entire experience, not just the interface, is usable. In hindsight, I should have worked with UXD earlier on. I could have saved a lot of rework time.
I have seen builders treat UXD as an afterthought many times. The thing is, you can build a powerful, secure, reliable product. But if the interface and the concepts are not intuitive, if the customer journey is not shaped end-to-end by someone trained for it, you will frustrate your customers and risk losing them.
That is why I invited my colleague Shilpa Bhat to join me for a walk and a recording on this topic. Shilpa is a Principal UXD and leads the user experience team for Amazon Intelligent Operations, the broader org in AWS that owns services like CloudWatch, AI Ops, Managed Prometheus, OpenSearch, SSM, etc.
What follows is that conversation, with some quotes lightly edited for clarity. You can also watch the video here.
I started our conversation recalling the usability study I mentioned. I said, “Shilpa, when I first worked with a UX designer, I thought their job was about the interface.” Shilpa smiled and said “It is about the experience, it’s not just the interface.” That distinction matters. Calling it UX/UI flattens the role. “UX is much more than the UI.”
She gave an analogy:
Imagine you’re going to a restaurant. The food is one part of the experience. But the reservation, the welcome, the noise level, the way your order is taken, and how issues are handled are all part of the user experience. Even the payment timing changes how you feel about the place.
I agreed wholeheartedly. I go to a restaurant for more than the meal. I am there not just to feed myself, but to spend time with friends and family. How I remember that experience depends mostly on the people running the restaurant.
From there our conversation moved toward customer goals. “You always work backwards from the customer’s goal, the customer’s problem,” Shilpa explained. “Think about the ideal experience and then figure out how we achieve it.” She tied this to the “jobs to be done” philosophy. Customers are always hiring us to do a job. For example, in the space Shilpa and I work in, monitoring and operational excellence of software systems, that could mean resolving an issue quickly.
I added that when customers enter the AWS console and something is not where they expect, it is frustrating. We both laughed about a real-life example I brought up. I pointed to the “Norman Door” in the very building we were sitting in. How many times have I approached to that damn door, pushed, only to realize it was a pull? Later I learned these confusing doors are called Norman Doors, named after Don Norman, a cognitive scientist who showed how design should make use clear through its form. In his famous book, he used doors and door handles extensively to make the same point, hence the name.
It was not the first door I had trouble with. On a trip in Türkiye, I once stood there for what felt like half a minute, trying to get into a bank. It could have been a bank that offered the best service inside, but it didn’t matter. I was already frustrated before I even stepped through the door. In my defense, I was extremely jet-lagged and doors work differently there. In the US, commercial doors usually egress out, while in Türkiye they often do the opposite. Shilpa and I did not talk about this story, but reflecting on it later I realized it ties to localization, which in turn ties to usability and UXD. Different cultures bring different expectations. A shape, a symbol, even a color can mean opposite things depending on where you are.
Shilpa said this is related to a design term called affordance:
A product should communicate how users interact with it. When you see a cup of coffee, you know where you are supposed to hold it from and which end goes to your mouth. It is pretty self-explanatory.
Then, she brought it back to how this ties to the AWS console. She stressed that good design means thinking beyond the part of the system your own team owns. “If customers need to use multiple services to complete a job, the connective tissue matters,” she said. Going back and forth between consoles should be seamless.
I asked Shilpa what she expects from engineers when partnering with UXD.
A lot of engineering and UXD have very complementary goals. We always want to start with the “why.” Why we are building something and then figure out how to deliver it.
Bring UXD in early. Understand what the implications are. It may not be as trivial as it first seems, because there might be no standard patterns and you might need to think it through first.
Shilpa went on with an example from her time working with AWS DeepRacer, where her team contributed to an open-source project that many assumed had no UX element at all. Shilpa’s design team argued that developers would not see what they could achieve with the software without good guidance. They partnered with AWS Solutions Architects and community influencers to build small sample projects and record short videos of them using the software to inspire potential users. She said, “We then followed with marketing and console collaterals to reinforce the message.” By that she meant the supporting pieces teams often build after a launch, like blog posts, short guides, in-console tips, and other material that repeat the same message in different places. Shilpa later shared some of these videos with me. Here is one of them.
We closed with advice to be the user of our own products. I added my own reflection: the difference between trying a product on a large screen and on a small one can be dramatic. Only when I use my own products daily do I realize how they feel. Shilpa said, “We should be dogfooding our products day in and day out. Ask what the customer is trying to do, and then try to do it yourself.”
I had not worked for a US-based company before coming here, so the term “dogfooding,” which originated in the US, was confusing to me when I first heard it. The phrase traces back to a 1976 advertisement for Alpo dog food, where actor Lorne Greene claimed he fed the product to his own dog. In 1988, Paul Maritz at Microsoft sent an internal email titled “Eating our own dog food,” encouraging wider internal use of the company’s software. Since then, the term has stuck in the tech world. It is a strange name, but once you know where it comes from, the meaning is crystal clear. Using your own product is the only way to feel the friction yourself before customers do.
That usability study from years ago left a mark on me. My conversation with Shilpa reinforced my learnings from that experience:
Products succeed or fail not only on their power but on how they are experienced.
Working with UXDs is not only about how a product looks and feels. It is about ensuring the experience makes sense end-to-end.
As builders, we need to partner with UXDs from the start if we want to create products that our customers will love.
When I asked Shilpa at one point in our conversation, “Is it a stretch to say Amazon’s method of working backwards is UX?” she did not hesitate:
Totally, it’s totally that. If you look at the definition of user experience, it is user-centered design. The user is the center of everything we do. We start from the user, and Amazon’s working backwards is exactly that.
I walked away from our conversation that day with even a stronger conviction that the best products are built when we work side by side with UXDs.