As a customer, you can give opinions or reviews after any service finishes.
Lately, this feedback culture has been increasing among users with the expansion of social media and on-demand tools that allow you to rate how satisfied you were after finishing an experience (lodging, entertainment, transportation, food, among others). These opinions can be so relevant that they can make a business thrive out of nowhere, or plunge into a bottomless abyss. Tech companies, especially those who respond to a SAAS (software as service) model, take this satisfaction metric as a critical milestone to succeed.
Nowadays, comments and opinions are so important that people decide to purchase a product/service based on people’s rating or reputation. As with all things in life, there’s no formula for excellent satisfaction; in the same way, there’s no perfect technology or product, which leaves you in a dance of two complex forces: customer satisfaction and evolving products.
This article discusses the first force, customer satisfaction as a result of an experience, and how it influences a product’s success or failure. I’ll try to avoid the basic definition and the way CX areas already work in companies because this isn’t the article’s focus; instead, I want to dive deep into how inner relationships in tech companies create healthy or toxic results that eventually affect how users outside the company will generate satisfaction judgments.
Recently, the city where I live has experienced indefinite water rationing, which has forced us to adopt strict measures, such as going without the entire service for one day a week every ten days. Due to this unique event, we were uncertain about how to proceed.
The administrator of the building where I live with my family was supposed to be in charge during this challenging day. Hours before the rationing, we had no action plan or recommendation from the administrator, so we were exposed to anything; uncertainty was high.
When the time came, the rationing hit hard; we couldn’t anticipate some house duties, such as dishing the washes or collecting a water supply for the day. All this uncertainty and misplanning led us to massive frustration and questions without answers among the building neighbors, and because of that, we could not ration water as we should have. It was a total failure; thus, everything was terrible.
On the other hand, imagine the same challenge above, but this time, with proper planning and a set of possible answers from the building administrator before, during, and after the event. Once water rationing arrives, we will know things like this:
The milestones above certainly help reduce users’ uncertainty and can provide some relief during an experience. Even if unplanned situations appear, essential information may help create a new response or way of proceeding and moving forward during the event. Everything could be optimistic in this scenario.
As you may have noticed, the difference between good and bad service depends on how much information and companionship people have to understand a situation and how to use information to react if something unexpected comes up. So, what’s the key to succeeding in a good service? The answer is resources.
Resources, in this case, information and companionship, are fundamental to using a product/service and, therefore, creating an experience. Does this dynamic sound familiar to you? I’m pretty sure you deal with this phenomenon daily. Whether in a restaurant, hotel, or event, the final experience summarizes our entire perception of things and becomes our truth.
The place where the actual customer experience is born isn’t when a final user experiences your product in the market and issues a concept. These experiences are born intimately due to team relationships within a company. How is this possible?
You wear the hats of customers and suppliers in a tech-production cycle, so you must provide information and assets to those who require it, ask for answers whenever needed, and provide proper companionship.
Unless you work in a silo, technology work dynamics compel you to relate with other teams and people from diverse backgrounds, so you move into a complex relationship network:
Although it might seem obvious, how you interact with other people or teams in a production chain reflects the essence of CX, which is delivering superior experiences, value, and growth for customers. Given the previous definition, could you divide the customer experience into two levels of influence?
The first CX you know so far happens outside the production chain (mainly with a final product open to final customers), and the second occurs within the dynamics of technology teams; it may be invisible at first sight, but it is there. I call this intimate relationship “inner customer experience,” or ICX.
ICX is a connection network between teams that should ensure all the production gear works with proper information, value, and companionship from the supplier’s and customer’s point of view to release an optimal product to final customers.
When it comes to ICX, there are three main perspectives that you should consider: engineers, PMs, and designers.
This team requires several primary pieces of information to proceed; depending on the project, complexity, budget, and scope (among other things), this team can operate under clear definitions (desirable), business decisions, the definition of done (DOD), strong user stories, and working capacity. A focal point from other areas may help overcome unexpected challenges.
This team is responsible for developing tangible, functional artifacts that users can interact with. It also oversees the available technology and the expected system behavior that ensures job fulfillment.
Delivering complete documentation and an organized backlog of technical debt for future planning is essential, as well as performance monitoring, among other technical strategies. Ideally, the team lead is responsible for answering questions from other teams.
Results from these teams are solid and evident, so the error range is limited or controlled with a contingency plan. Customers of these teams know precisely what to expect regarding functionality, behavior, features, performance, and release time.
This part of the technology production cycle is usually the last stage before going live, so having lousy service at this moment can cost money and be a waste of time. Not having a complete scenario or action points is dangerous regarding what to expect from its customers because it can mislead stakeholders to make confusing product decisions. Eventually, it will create a poor user experience, affecting the product’s satisfaction and reputation.
This team works primarily based on business decisions as its source of truth. User needs and market opportunities are also valuable information required to proceed and build a product vision, but there are two essential assets for PM teams: timeframe and capacity. With these two variables, it is possible to assemble a plan and set expectations.
This role in a company must show a clear roadmap of activities or goals to accomplish and operate according to a plan. Impact on business numbers is critical information for stakeholders and other internal clients. This team’s standard answers to different areas are related to product value, purpose, and user engagement.
For this team, information and companionship are everything. PMs are responsible for connecting several sources of truth and translating them into valuable data for stakeholders. This team needs to create a follow-up cadence as the primary communication channel with other teams to ensure the perfect project execution or to socialize ideas or pivots on the project.
Last but not least, agreements are essential to keep all teams perfectly aligned on a common goal by reducing the gap of uncertainty and misunderstanding.
Good planning, execution, and results are evident when product managers fulfill all customer and business expectations. This team’s most significant achievement is finishing a production cycle and understanding or envisioning the company’s next step in income, projection, and market behavior.
This team is usually in the first stage of a production cycle. As a result, if the ICX isn’t good enough, it’s probable that the whole project will have a negative impact. This lack of connection between areas might result in false product expectations, unclear product definitions, and complex business decisions; thus, the final user experience will be compromised.
As with the other teams, this unit demands a group of information to work on any project, which lets it create a particular vision or solution. From the design perspective, it’s essential to have a purpose and clarity when impacting users, measure user behavior, and collect feedback to evolve the product in upcoming iterations.
Among pieces of data required to start a project, there are a crucial few: The definition of the problem to understand a challenge and create experience expectations and metric insights to have a quantitative context. If this information is incomplete, you’ll likely tackle problems from the wrong side, leading to lousy service.
You’re responsible for the whole project’s user experience, which should be your biggest asset to stakeholders and teams. How will this user experience look in terms of deliverables? Every team has the autonomy to create compelling artifacts to fulfill this need and provide a good service; making things easy to understand for everyone is necessary.
You can start from the basics like user flows, blueprints, and use cases to a complete design prototype to give people a close notion of experience and, eventually, provide feedback. You also own user metrics to state results after launching a product.
This team’s range of companionship is broader since it can participate in all production phases, such as the investigation stage, perform live validations within the project, and monitor after the product goes live. Regarding information, this team needs to provide stakeholders with a clear understanding of user experiences, user expectations, and high-standard communications. Companionship for this team also means being with users all the time, internal and external, to create a solid feedback bond.
In technology, users get most of the experience based on how hard or how easy it is to do a job; hence, getting to the final production cycle with proper resources (information and companionship) will positively impact inner customers, creating confidence to launch something that you can envision will be good enough.
Not having clarity on all business expectations, user behavior, and strong communication channels with other teams will result in a product with insufficient user experience, dead-end paths, and lack of coherence, making it hard for users once they interact with a solution. Lousy service equals a bad experience, so at this point, you can be exposed to negative reviews or, worse, user resignation from your product.
As I mentioned at the beginning of this article, you can measure customer satisfaction (CX) to make decisions, whether validating promising approaches, asking for recommendations, or changing the product value. The same premise should work for the ICX: Knowing how you behave and how satisfied your clients are with your final product may be the difference between excellent and lousy service.
As a young company, there’s still much to learn, and one of those learnings is to understand that your work is an asset to someone else and that how you create relationships with others is essential to have a healthy production chain.
There was a time when many company changes were happening within my product team, and part of those changes echoed how teams started to relate to each other. From the design team, we were getting negative feedback from other teams because the production chain wasn’t healthy due to ineffective processes.
That situation compelled us to be reactive to any request without planning or strategy, ultimately resulting in friction between teams. The worst part was that nobody was accountable for the feedback and comments that sounded more like gossip than effective feedback.
How do you react to this discomfort? The answer was straightforward: from then on, we formally asked people for their opinion on how we worked, and as any CX, we took this information to improve our service or product or, at least, understand our users.
After a team meeting, we agreed that gossip comments were unhealthy; instead, constructive feedback would help us improve effectively. So, we decided to use the most basic UX tool: A form. A simple form with the right message after finishing a project will create a secure place to give feedback to all teams, avoiding irregular messaging from anyone.
I remember someone asked about the difference between this form and a post-mortem meeting; I believe post-mortem ceremonies aren’t authentic, and people don’t feel confident speaking out loud to others in the same space/call. A form, instead, can be a friendly space, to be honest.
Once we decided to ask for feedback as a formal step of the production chain, the next step was to define the items we wanted to validate from their standpoint. We built this form as any interface; we represent the central regions of actions and then move into specific interactions.
We considered the following:
People are loyal to good service; that’s a fact, and getting their opinions is essential to building better experiences at any scale. Understanding that the customer experience shouldn’t be only an external issue for companies, but an internal matter will change how teams work and learn to build better products.
ICX is, so far, a new idea we, as a company, want to embrace and develop; maybe the internal customer experience isn’t the key to success, but we’re sure that every significant impact we create starts small, intimate, and straightforward. We’re sure it’ll generate a healthy feedback culture within my team that’ll encourage us to improve whenever possible.
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
