Designing Shuffle, the internal tool that powers Nubank’s award-winning customer service

Written by Cristiano Dalbem.
Reviewed by Amanda Shitara, Cristiano Luis, Gabriela Oeda, and Amanda Legge.

Welcome to an exclusive behind-the-scenes journey into the world of Nubank’s award-winning customer service. In this article, we delve into the intricate workings of Shuffle, the internal tool that powers Nubank’s exceptional customer support. We’ll talk about:

1. What it’s like to work in the Customer Excellence Platform, the team that builds the internal tools that power our customer support;
2. The techniques we used to better understand our users;
3. How we prioritized user pain points, connecting them to real business needs;
4. A deep dive and a behind-the-scenes peek into two of the biggest features we delivered;

Keep reading this article and find out everything about the Shuffle development process!

Since its creation, Nubank had a clear mission in mind: fight complexity to empower people in their daily lives by reinventing financial services. As tricky as this mission might sound, it was easy to find opportunities within the financial world, as any Brazilian could confirm: abusive rates, complex products, and inefficient, cold customer service.

The latter is especially prevalent in banking services, with long wait times with elevator music, countless transfers where you need to repeat the same information over and over again, unhelpful chatbots that don’t understand your problem, endless confusing menus, and unfriendly attendants in several services used on a daily basis. 

From the beginning, Nubank offered an effective, efficient, and humanized service to differentiate the company from the market, and this is how the role of “Xpeer” was born.

Xpeers are Nubank’s own professionals in customer service and problem-solving. Even today, Xpeers are a fundamental part of the customer experience that Nubank offers. They understand our products and services like few others. They also know how to listen to customers, understand their problems, and conduct the conversation in ways that respect the customer’s time while reinforcing the human aspect of it.

It’s not easy to provide 24-hour support simultaneously in multiple channels for more than 80 million customers across various countries. Needless to say, Nubank’s customer service numbers are impressive. To give you an idea, since you started reading this article, our support team has already assisted more than 200 people!

Nubank is well known for offering great experiences through its digital app and humanized customer support, but did you know we have a full team dedicated to creating a great experience for Xpeers and the internal tools they use? 

In order to guarantee that we’d be able to handle the massive contact volume from customers, Nubank invested in developing the software platform that supports the entire operation internally. The CXP (Customer Excellence Platform) Business Unit is the team that focuses on monitoring the operation’s metrics and developing the products that Xpeers use in their day-to-day work. These metrics can be split into two groups:

• Efficiency: customer wait time, agents’ idleness, etc.
• Quality: CSAT (user satisfaction), number of completed calls, etc.

CXP is what we call a platform team, serving three different layers of users and stakeholders: internal product teams, Xpeers, and customers. We provide the tools and

documentation that will allow Developers, Designers, and PMs across Nubank to build Customer Service experiences that are tailored to their products and business needs. It is only because of this platform that the software can scale and grow, and the CXP team can focus on improving the platform itself instead of building the dozens of widgets and components that make up the final product.

In addition, we create the internal tools for Xpeers to serve customers through phone, email, and chat channels by showing which products they have and their statuses, as well as perform other internal operational jobs. And of course, everything we do is with our main (and most important) stakeholder in mind: the customer. That’s why all our product metrics have to, end up impacting customer satisfaction metrics. If our mission is to provide tools for the customer support team, our objectives should be aligned with them, thus everything improvement should impact and improve our operation and ultimately be perceived by the customer.

The main product working behind the scenes to ensure our humanized customer experience is called “Shuffle”, which is the tool used by Xpeers on a daily basis to carry out the vast majority of their work. Like most of the rest of the platform, it was an internal creation of Nubank, made especially for our needs and systems, based on a microservices architecture. Despite looking complex, Shuffle’s main screen is divided into 4 main parts, from left to right:

The parts of Shuffle, the main CX Platform tool used by the customer support agents in their day-to-day work.

The sidebar on the left offers navigation through the main parts of Shuffle, which are the different service channels. If you are taking the Chat channel, it will also bring the other simultaneous calls that Xpeers can take. Lastly, on the bottom, the Autotake component is where agents choose how many simultaneous calls they want to take.

1. The purple sidebar on the left allows Xpeers to switch between different tasks: emails, telephone, chat, or internal backoffice jobs. The colorful circles with the customers’ initials enable the navigation between different customer views. Lastly, on the bottom, the Autotake component is where agents choose how many simultaneous calls they want to accept at any given time.
2. An integrated chat interface with the customer. Besides the messages sent by both parties, it shows some metadata such as the predicted contact reason, transfers made previously, and even a complete history of previous contacts from that customer.
3. A “job” or a “ticket” is the representation in the system of a customer issue. This top bar, called Job Bar, is where the agent classifies the issue and controls the job to either mark it as solved or transfer it to another team. Agents can also “skip” a job and pass it to the next agent in line. They usually do this if they’re too busy, or if they think they’re not the best person to solve a particular problem.
4. PersonDeck: The heart of Shuffle, this is where all customer information lives. It contains the tags, which identify unique properties of the clients, and the widgets, which are cards that encapsulate all customers’ information and possible actions that an Xpeer may need to do during a service. Fun fact: it’s called a “deck” because it’s made of “cards” — now you might be able to guess where the name “Shuffle” comes from.

Even though it’s not visible here, the canned responses system is an essential part of Shuffle. This feature guarantees the quality of service by assisting Xpeers with ready-made answers to common customer questions and problems. We’ll cover this more later in the article.

As a designer joining the team, the first thing I did was try to learn more about the users: who they are, what they do, and what their motivations and pain points are. Reaching out and building a relationship with them was easy since they’re Nubank employees and we could circumvent some of the standard privacy requirements when working with external customers. They’re colleagues who, if it weren’t for Nubank’s home office policy, could be sitting next to me.

However, it soon became clear that while not everyone building Shuffle had the same level of direct interaction with the users, there were occasional meetings with operational leaders and valuable sporadic feedback that enriched our collaboration.

A fascinating ritual that already existed at Nubank was the Xpeer Xperience: a whole day dedicated to Nubankers working as Xpeers. Although the ritual helped put us in the shoes of our users, it was not enough: we used different machines than them, we had different levels of knowledge, different motivations, and so on. It was crucial to tap into the Xpeer mindset in a more direct, less biased way.

This is how a new ritual was born: the Weekly Shadowing. Once per week, we set up one hour dedicated to observing Xpeers in their “natural habitat,” doing their work while we watched how they used the tools we helped build and maintain. Although it was difficult to not jump in and offer tips and ask questions, it was essential to avoid interacting with the Xpeer being observed, so as to simulate the closest possible experience to their natural behavior. We wanted to avoid any possible feelings of this being a “presentation for us” in which they’d involuntarily falsify a way of working that made them seem like better professionals. We even provided a small playbook for guests to ensure these kinds of things were clearly aligned before joining the session.

The Shadowing Playbook provided a quick guide for observers to know what themes to pay attention to and other good practices for participating in this kind of session.

The weekly shadowings, in addition to creating greater empathy and connection between the team and our users, helped reveal great insights and made us review many of the preconceived ideas we had about how the product was actually being used. Although Shuffle might look like it has an overwhelming UI that demands a lot of cognitive effort to someone who doesn’t use the tool everyday, we noticed that Xpeers who use the tool every day for several hours quickly memorize the location of different pieces of information and actions. Xpeers were ninjas using Shuffle! If you use any professional tool for work, like Photoshop or Figma, you can probably relate to software that has a steep learning curve.

Another important lesson we learned was that a large volume of so-called “minor” (but still equally important) feedback actually never reached the team. These agents’ day-to-day work is very hectic, and they prioritized escalating only the more severe problems that would affect the operation. Moreover, as creative and resilient people, they often managed to find ways around the frictions of the tool.

This meant, for example, that they didn’t report performance problems they were having with the tool on their machine – they’d think it was their fault, or they’d blame the wifi or the VPN. This was actually one of the problems that didn’t appear when we did the Xpeer Xperience, since Developers and Designers at Nubank use extremely performant machines. 

A simplified schematic of how the customer and Xpeer journeys intersect.

The team, mostly comprised of seasoned back-end developers, was highly attentive to metrics such as system stability and network performance. This issue, however, still slipped through the cracks since they were only considering the back-end side (e.g., how fast the services respond) and not so much the front-end side (e.g., how quickly the browser renders the page and makes it available for interaction).

As a Product Designer, it was not enough to just bring dozens of user insights and learnings to the team. It was also my job to help bring clarity as to which insights were the most important and prioritize which solutions we should implement first. And here, we’re not just talking about which changes would impact the users the most, but also what impacts the whole experience: from the needs of internal users of the platform (which are multilayered, as we covered earlier), the customer itself, and what aligns best with the business and product strategy.

At this point, it was essential to balance the company’s strategic drivers, the product’s mission, and how different project ideas fit into this. For example, redesigning the interface components and creating a Design System could generate a great visual impact and empower Designers. But, compared to other bigger issues we’ll see next, the usability improvements of these projects would be minimal, and we probably wouldn’t detect a significant increase in agents’ productivity.

By talking with stakeholders and co-creating with the team, we mapped and correlated the main product objectives, improvement ideas, and strategic company drivers. This diagram is a simplified version for presentation purposes. Solid lines represent clear impact and dotted lines represent indirect impact.

We also realized that there was a lot of “low-hanging fruits:” minor, low-effort improvements that would improve the Xpeers’ quality of life and that, when stacked together, could make a real dent in the product’s usability. While we invested in in-depth Discovery to investigate more significant issues (which we’ll cover in the last section), we tackled these small issues bit by bit. This started to build a more positive atmosphere among Xpeers, who complained that although the platform has had many improvements under the hoods, Shuffle hasn’t evolved much. Here are just a few examples:

1. Notifications: During Shadowing sessions, we noticed that Xpeers frequently switched to other browser tabs to investigate issues. However, Shuffle did not alert them if there were new customer messages in the meantime. We added sound effects for different notifications and a custom favicon and page title to reflect the status.
2. Chat panel: From the very first sessions, we noticed how sluggish it was to type messages to the customers. The problem was so severe that we often observed agents typing their messages in the address bar of the browser to later copy and paste it into Shuffle. As engineers were refactoring this component’s code, I made sure we’d prioritize improving the performance too. 
3. Autotake: before, Xpeers had to manually pull tickets from the system, which was tiring and inefficient (even if there was a keyboard shortcut). In field research, we even heard reports of Xpeers leaving small weights on their keyboards to keep pressing the action shortcut. Autotake is, as the name implies, a system with a minimal UI (on the bottom of the left sidebar we showed earlier) where the Xpeer sets the number of chats they wish to take at the same time, press “play”, and the system will automatically allocate these as they come.
4. Typography: moving from Open Sans to Inter, we increased the legibility of small text due to it being more optimized for screens. It also reduced screen real-estate usage due to its taller x-height, which works better for high-density designs.
5. Keyboard shortcuts: Essential for those who work with professional tools, they were not reliable due to bugs and we identified opportunities for new ones. One example: there was a shortcut for finishing a job, but not for choosing the contact reason from a dropdown menu, which had to be done with the mouse cursor.

Little big details: by cleaning up the browser tab title and showing notifications there, we helped agents not leave the customer waiting when multitasking. Xpeers also reported this reduced their anxiety about going deep into their problem-solving on other tabs.

Despite being difficult to measure their impact individually when shipped, all of these improvements helped give the feeling of a product that was no longer frozen in time and made the Xpeers trust the team and ask for more. Following are two bigger projects we ran while these small changes were being shipped:

• Redesigning the canned responses experience
• Optimizing the visualization of customers’ data

Before/after: instead of a full redesign, we could drastically change the overall look & feel by compounding multiple small changes, making users feel like the product was not stuck in time. Most importantly, the changes improved not only form but function, driving real results by impacting the users’ productivity and satisfaction with the tool.

While analyzing and organizing the dozens of insights, our attention started to gravitate toward a set of issues regarding how agents used canned responses, which are ready-made answers to common customer questions and problems. This is a common type of feature for customer support tools, and helps agents remember all details they need to ask or provide for almost all types of customer issues, as well as maintain consistency in how the company approaches the problems.

Although Shuffle had its own huge database of canned responses with an integrated search engine, most agents preferred to use a sketchy Chrome extension to handle them!

Organizing a repository of all the insights was crucial to navigate in this complex and new universe, helping us identify patterns while keeping everyone on the same page of what we were discovering.

In addition to bugs that made Xpeers lose all their canned responses and usability issues that led to inefficiencies and errors, there was a high-security risk in using an external browser extension over which we had no governance. Besides these problems, we were leaving a huge opportunity on the table to apply usage data to improve our own internal Artificial Intelligence models, which are the cornerstone of the CX platform.

After gathering insights from sources such as surveys, in-depth interviews, and our dear Shadowing sessions, we used the Problem-Solution Tree framework to visualize and categorize the main opportunities, as well as brainstorm possible solution ideas.

The Opportunity Solution Tree was a helpful framework to help us map and visualize our objective, the problems we wanted to solve, and ideas for solutions. [Click on the image to see a larger version]

After prototyping and testing several concepts with users, we arrived at a new system that allowed agents to search for information without losing the focus of the customer. Instead of an interstitial modal that covered the whole screen (think of something like macOS’ Spotlight), the winning design was a sidebar that allowed agents to keep an eye on the chat and widgets while searching for canned responses. We also introduced a few other new features that users loved:

• Being able to create their own, custom canned responses.

• The ability to customize the existing canned response shortcuts (in the form of “/SHORTCUT”), so they could use their preferred mnemonics, such as “/REISSUE” instead of “/REISSUEAPP-HOWTOREISSUEVIATHEAPP”.

• Customizing the content itself, so they can adapt it to their personal tone of voice. They’d also be able to use rich formatting (such as italics of bold) to better highlight parts of the text and add images or GIFs.

• We also introduced a “smart placeholder” feature that automatically fills details of the canned response with data from the customer, e.g., {{customer_name}}, {{account_balance}}, etc.

• Several improvements on how the search worked, such as being more flexible with typos and accented characters and also being more contextual, ranking the results based on the agent’s team and current case classification.

The final prototype for the new Shuffle integrated system for searching, managing, and using canned responses.

One of the most significant signs that Shuffle had not scaled very well with the company and agents’ needs is the Widgets area. While there might have been half a dozen widgets at the beginning when Shuffle was first established at Nubank, we were quickly approaching more than 50 widgets! Even if agents had very different types of tasks and customer problems to solve, the Shuffle widgets were in the exact same order for everyone.

During the Shadowing Sessions, we often saw agents overlooking critical info on the customer profile. We hypothesized that this was caused by an interface with a high cognitive load and poorly structured information architecture and visual hierarchy, all negative effects of that sea of widgets.

From talking with agents, facilitating some co-creation workshops, and taking a close look at the data, we mapped the main objectives and constraints for this project:

• Agents are accustomed to the current layout of widgets, where they memorize positions and can quickly scroll directly to that position. We know any changes will have an initial negative impact, so we have to make sure that any changes will be a real improvement in the long-run.
• Some agents work in teams with very predictable work and always solve similar customer issues using the same widgets. Other agents’ work streams were the total opposite – depending on their specific task or allocation, they needed to access unique data sets.
• We discovered that when agents requested to improve the organization of the widgets, they actually expected that this would improve the performance of Shuffle, which was one of their main pain points.
• If we split the PersonDeck into multiple “decks,” it was crucial that we wouldn’t also fragment the load time into multiple load times. The effects of a compound loading time would make the agent even less productive than if she had to wait once for everything to load.

Wireframe prototypes designed to gather reactions from the Xpeers of different approaches we could explore to improve the organization of widgets.

Since many ideas were on the table, we built several small wireframe prototypes to test the different concepts. After user-testing those, we got the engineering and product teams together to discuss them using a Decision Matrix technique.

A snapshot of our Decision Matrix, a framework for prioritizing ideas based on multiple dimensions.

The Deck Editor was an idea that was on the Engineers’ mind for a while, and that Xpeers seemed to want very much. It’d enable them to fully customize the widgets they wanted to see and their order. However it was also a complex feature, both to build and to use, and most certainly didn’t fit the time budget we had at hand.

We concluded that a “low-hanging fruit” solution would be to implement filters for the widgets, organizing them by categories. These filters would be “remembered” by Shuffle for each agent, thus ensuring that a lot fewer widgets needed to be loaded at any given time and potentially improving one of the biggest problems reported by users: the software performance.

Another simple-to-implement feature that would generate a lot of value was the ability to mark widgets as “favorites.” A simple extra button in the lower right corner of each widget would allow users to pin their most used widgets to the top of the screen.

Combining the Filters, Favorites and the recently launched Collapsible Widget features would allow an entirely new level of customization of widget visibility and ordering. Although it was not the fully-realized flexibility of a Deck Editor, these were easier to implement and use.

Combining 3 simple features (Filters, Favorites, and Collapsible Widgets) allowed Xpeers to customize their views while keeping the system simple to use and maintain.

Designing an internal, professional product such as Shuffle was very different from anything I’ve ever done before. However, as with any project, keeping general principles of good Design in mind, the rest happens naturally. Here is a summary of our main learnings:

• At the heart of offering great customer support is the people, but providing the right tools to those people is equally important. Providing a great experience for our Xpeers is one of the best ways to lead by example and enable and inspire them to offer a great experience to our customers.

• Putting ourselves in the user’s shoes is not enough. When the end user is so different from the people building the products, the role of Design and Research becomes even more important. Observing the agents in their day-to-day work with Shadowing sessions and doing interviews was arguably the best way to deeply understand them.

• An internal product that is a platform not only has many stakeholders with potentially conflicting interests but also has many different profiles of users. It’s crucial to map who they are, and their needs, and understand when these needs interfere constructively or destructively with each other.

We believe that this work has set the foundation for future work, which is currently being done by an even larger team dedicated to improving Shuffle and the CX Platform as a whole. Even though a complete overhaul of Shuffle was not feasible before due to too many uncertainties back in 2020 when all of this started, after many learnings throughout the years this exciting route is being considered again and will be a reality very soon. So, stay tuned for future articles on Designing Shuffle!