Holistic User Experiences: From Digital to Physical Products

Juan Pablo Vildosola at UXDX Community: LatAm. Video: https://youtu.be/5hhYGMG_toU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

GeoPagos and the mobile POS

[00:00:00] Hello everyone, thank you for joining this UXDX event. My name is Juan Pablo, head of product at GeoPagos. GeoPagos is an omnichannel payment platform that enables small and medium businesses to accept credit cards with a minimal, simplified setup, with hundreds of thousands of users in more than 15 countries across Latin America. GeoPagos drives financial inclusion, allowing many underserved businesses to accept payments for the first time.

[00:00:32] In this talk I'll share some thoughts from my experience of designing products that require both digital and physical interactions. Starting with the importance of having a holistic approach to the problem you are solving, where key aspects such as environment, device, sustainability or even culture make a difference. How, as designers, we can empower the team and facilitate collaboration with engineers, QAs, project leaders, you name it, allowing them to be part of the same process and work towards a common goal. And last, how designers become more valuable when they can cross over from a specific design task and adjust their lens to see a problem as part of a wider ecosystem. Hopefully you can get something out of this.

[00:01:26] Before we start, let me quickly introduce you to the product of GeoPagos and the problem we are solving. For many years, accepting payments in Latin America was not for everyone. Many small businesses were underserved by acquirers and very heavily reliant on cash. Having your own bulky and expensive POS terminal used to mean a lengthy, multi-step process and signing contracts. You might even need two or three of these ugly terminals to accept all major card brands.

[00:02:02] So the mPOS, as we call it, or mobile POS, allows any person to accept card payments anywhere, using an affordable, simple card reader device with a mobile phone app. This, combined with a simple sign-up and rapid device distribution, allowed many small businesses and self-employed people to access this service for the very first time in their lives. Additionally, the digital platform unlocks many value-added features beyond payments to manage and grow the business.

The first design sprint: flow and screens

[00:02:37] The key interaction of the problem was around the transaction moment, where two different users, a merchant and a customer, interact with each other for a certain time, in a specific environment, with not one but two different devices and interfaces. At that time we were trying a lot of different suppliers to make our MVP, and we did not have a lot of information about how it worked. Finally we started to work with a couple of different models, one with a PIN pad, the other without it, for different zones in Latin America, and I started to try them.

[00:03:19] The basic flow works something like this. From the merchant user's perspective, you turn on the device, and it connects wirelessly with the application. Once connected, the user must know how to interact with the physical device to read the card in different ways: tapping, inserting or swiping the card. And then the other important part was to validate the customer's identity, either by giving the reader to the customer to enter a PIN number, or by allowing them to sign on the phone screen with a finger, something very strange at that time.

[00:03:56] Our first design sprint was focused on the flow and the screens needed to interact with the user and the reader. Meanwhile, the engineers worked on the development of how to interact with the device itself and make a transaction safely and according to all the compliance, which was of a lot of importance back then. The result was a flow and some key screens of interaction, revolving around three main actions: power on, connection and the transaction.

Needing a holistic, 360 approach

[00:04:32] This was a very good first step, but we needed a more holistic approach to make a better product. The different devices, the people involved, the places where it takes place: all of this constitutes the user experience of that transaction. Very soon we realized that we needed a wider look and a 360 approach to this particular moment. The digital interaction with the phone and the device had to be thought about as one unified experience.

[00:05:02] First we started to get more into the reader, the hardware, with its interface and particular constraints: the usability and ergonomics, different things like signals such as lights and beep sounds, button target sizes and icons, a small pixelated screen displaying key information. Besides the app screens, there were many things to consider within the user experience, and most of these could be modified by us and designed as a whole experience, not only the screens.

[00:05:40] On top of that, remember that for many users it was the first time accepting payments. They had never had to swipe a card into an unknown device, or ask a stranger to enter their very secret PIN number on a tiny PIN pad. So a main tutorial with a clear example of how to do that was something worth considering in later iterations. Also, we had customer users concerned about the security of this new lightweight reader, so the psychology and the sense of security was very important to consider here.

Leaving the office: mystery shoppers and contextual inquiry

[00:06:22] Initially we were a small team working in the office. We could talk to each other and show what was in progress. But the distance from the user and the natural environment the product was meant to be used in was far different. In the office we were sitting in a closed space, comfortable, with air conditioning, in front of the computer, with all the time in the world to try to make a payment, laid back in our chairs. And also there was no customer user; we were thinking more about the merchant, and we wouldn't see the whole picture. It was really very far from the real-world scenario.

[00:07:07] It was obvious that we needed more research and context observation. We decided to get a complete picture of that experience. Some members of the team, including myself, tried to visit merchants as mystery shoppers. A few devs and designers showed up in places where we knew the product was active, like restaurants, or buying something in a shop, to have the excuse to experience the customer side of the transaction. This gave a first-hand look at what really happened in the point-of-sale environment. But at the same time, you could not document it and share it with others. In fact, none of us really knew how to conduct a research study and gather quality data.

[00:07:54] The next step was to hire a research analyst to help us with the different research techniques and tools we didn't know anything about. This researcher would plan and conduct research studies, do the recruiting and also facilitate documentation of the findings. We ended up doing something called contextual inquiry. We didn't know it at that time; we know that now. This means that researchers join the users in their natural environment as they do their activities the way they normally would. The researcher and a few assistants watch and learn, occasionally documenting with photos and videos.

[00:08:37] It was also an interview, so the inquirer would ask questions about what the user is doing, or other more open-ended ones. The interview would take on a rhythm of its own, with periods of silent work and periods of discussion, asking questions and talking about the experience as it was developing in that moment.

What the research showed

[00:09:02] And where did we go to get the answers? We started to visit different small businesses matching our audience: retail and groceries, farmers' markets and even street food [?]. Most used our product, but we also did some research on merchants using direct and indirect competitors as payment solutions. So we were looking at the whole experience and not only the use of our product. That was very helpful too, because we could understand more about the problem we were solving, and not our product in particular.

[00:09:45] And what did all this show us? Here are two insights. For example, we were interested in the natural frequency of payments, ranging from a few transactions per hour to multiple transactions in the same period, depending on how many employees, the time of day and the type of business. That helped us make better decisions in designing the connection flow of the app, or how long the reader stays in standby mode. More on this later.

[00:10:19] Handling the device, the ergonomics, was also an interesting issue. Many users were the only person taking payments and attending to customers, so using two hands and focusing attention on the devices was a bit of a challenge. We didn't know that in the office, for sure. The context was also different from country to country. We needed to design for different user customs regarding payments, where sometimes the card never leaves the customer's hand, and sometimes the whole transaction is made by the merchant: you give them your card and they give it back, like here in my country, Argentina.

[00:11:01] Now that we have more context and a deep understanding of the problem we are trying to solve, we can make better decisions and integrate them into the product later, or answer those questions we had early in the process. For me it's like flying high above the user's world, a quote I saw reading an article, which is a very nice metaphor here, because you have the moment to look at the problem with a broader perspective, from above, and try to see a greater picture. So you design the experience as a whole, but also the transitions between touch points, which is very important. And many times you need to deep dive into a particular problem, to acknowledge interactions not completely related to design, and work closely with the rest of the team. I think it's very valuable, and the process gets richer.

Designers as the pivot across three teams

[00:12:03] Now, as the company grew more, in addition to the mobile app developers, who were doing that part of the apps and the devices, we now have a whole team specifically for the hardware, working on the device. So all three parts of the team are working together as one, and this brings some new challenges. The designer here is, in the same process, a pivot, unifying the whole experience across different teams. UX, product designers and devs gather to discuss flows and interactions as part of the development process.

[00:12:53] For example, when discussing Bluetooth technology, low energy, high energy, you name it, to make a connection faster and more efficient, we discuss why we need permission to turn it on, how best to design the permission, and how long we can keep this connection open while trying to maintain a balance in battery consumption. So we are linking here the battery efficiency we're talking about now. We talk with engineers to explain why the device is set to power off after a certain number of seconds, and why we need to choose this according to what we saw in our contextual research. Remember the natural frequency of payments: we now have a median time, or number of interactions, for how long the device has to be turned on.

[00:13:50] All this could be changed, but we needed to discuss it with the team. To change this, we needed to make a new framework for us to go through an application process, and to make that in the device we needed to develop a new flow in the application, which was a firmware update, which is very critical to the core product. So we go back to the digital screen and design it again, to later iterate on another feature of the product. Ultimately, designers ended up knowing a lot more about development constraints, and developers knowing why we need to adjust the user experience based on the research insights shared with them. And this is a really great way to work, in my opinion.

The challenges of cross-functional work

[00:14:49] But cross-functional work has some challenges too. In the early days we were a small team, 10 or 15 employees working in the same office, communicating often and sharing progress. It was very, very easy for us to reach each other. Later, as the company grew bigger, they started to rearrange. The mobile developers started together as one big team, or even a pool, and something similar happened with the hardware engineers. The teams started to drift apart. Especially UX and design got quite disconnected from development. I think this is something that happens to all of us at some point in time in our companies.

[00:15:35] The situation led to some misalignment, low-quality deliverables and rework. Engineers were very focused on tasks, with high rotation and low commitment to the product. After some rearrangement of teams, the evolution of this, and I think the first improvement of the scheme, came with the role of the product or UX owner, who would align the teams and priorities, working across and facilitating communication between stakeholders through meetings, workshops, you name it, with at least one or two members of each team involved, to show findings and work together, trying to break the so-called silos of work.

[00:16:29] We also tried different ways to collaborate. Working together and sharing information was a little bit of a challenge. Doing workshops and meetings proved to be more efficient and effective compared to heavy documentation and pure design handoff. "I send you the Sketch screens or the Figma screens": no, that alone didn't work very well. Visual support over written definitions, with collaboration tools like Miro: flows, screens, technical stuff, research insights, mixed and connected in the same visual space. This is a very, very good tool for now, for the pandemic also. And as the team works as one, there was no need to detail tasks attached to long user stories, so it was easier and more natural to flow the information.

Bringing QA in early

[00:17:33] Another thing we found very useful was to also try to include quality assurance people early in the discovery, development and design process. Many times involved only in the last step of the process, QAs proved to know a lot about the product and give great input and feedback. They were great allies. This would also make the QA process easier, because we didn't have to explain what to test or what to look for, because they were already part of the team and they knew what to look at.

[00:18:08] And later, documentation of the features and products is made in collaboration also, with Confluence or other platforms like Confluence. Try not to leave critical information and decisions hidden in tasks or user stories in Jira or other project management tools. So for all the QA part, we were working very well together.

Tap to Phone

[00:18:43] Another interesting case came up when we started to develop a new solution, commonly known as Tap to Phone. This was a new product or opportunity where the card reader is no longer necessary. You can replace it with the phone itself, using the NFC antenna to take contactless payments, tapping physical cards, phones or wearables. One of the challenges was to make proper contact with the card on the back of the phone, where the NFC antenna is located. This was inconsistent across different brands and models.

[00:19:21] So the first approach here was to involve a couple of QAs to start a test. Each one of us grabbed a couple of phones and tried to make a proper reading, tapping the card on the back of different models. They were all Android phones; there's no iPhone here yet. Very soon we discovered that the tap experience was very inconsistent. On some you might need to tap on the bottom part of the phone, on others in the center, or the top. Sometimes you need to make a slight angle with the card, a very odd thing to do.

[00:20:00] So this was validated with some users, and we designed a little onboarding or tutorial to discover the particular sweet spot of each phone. You need to make a test payment, moving the card around the back of your phone to find the place where the antenna is stronger. I really like this particular Tap to Phone case, because two interesting things happened. We were more prepared as a team, thanks to the previous experience of developing the mPOS, the research in the context, and knowing all about the device and the moment of the transaction. And also, involving QA testers helped bring more diverse people into the discovery and design processes. They were the ones who had the phones, and they were used to trying different phone models and testing them.

[00:20:59] This facilitated learning from each other's specific expertise, empowering the whole team as a cross-functional one. So involvement makes things work better, and knowing each other gives better communication towards a specific goal.

Crossing over, and wrapping up

[00:21:19] This also allows us, the designers or product designers, to cross over from the most common fields, let's say UX and UI design for digital interfaces, and apply user-centered principles where needed, be it hardware devices, service design, customer support or a whole new product. This is where I used to give my colleagues the astronaut advice [?]: if you feel any aspect of the product experience is unattended or overlooked, don't hesitate to take a look and help somehow, even if it's not what's expected from your job title. This will make you an overall better professional, I assure you.

[00:22:07] To wrap up, let's say: try a holistic approach. Before jumping to conclusions and designing screens, take your time to learn more about the context, the people, the nature of the tasks they are trying to achieve and the struggles they have every day. Also, be a team player. Try to break the silos between different disciplines and work together towards one goal. Improve as a designer, push yourself to be a better professional: go a little deeper and apply the user-centered lens in other areas that at first might not seem related to UX. And that brings us to the end. Thank you very, very much for your time, and see you around.