Q&A With Juan Pablo Vildosola

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

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.

Designing with hardware

[00:00:00] Rory: Unfortunately, that will be the last of my Spanish for the evening, but please do let me know in the chat if you're having any difficulties understanding English, or if you would prefer me to slow down. Welcome, everybody, to UXDX Latin America. Our first Q&A, as Jovi [?] just mentioned, is with Juan Pablo Vildosola, who is the head of product at GeoPagos. Welcome, Juan Pablo.

[00:00:32] Juan Pablo: Welcome, Rory, nice to meet you. I'm very excited to be here with you and all the other folks here as speakers.

[00:00:43] Rory: Excellent, so we'll jump right in. I watched your video, a really, really interesting case study. One thing I personally haven't had to experience is the hardware side of things, because my career has typically just been on the software side. So my first question is really about what influence you think that additional hardware layer had. Do you think it made things a bit more complex than a typical software project, or do you think those boundaries actually helped, because they limited the scope of what you could work with?

[00:01:22] Juan Pablo: Well, it's a good question, because I started my UX career working with hardware from day one. I didn't have a lot of previous experience with UX/UI for digital interfaces, so I cannot tell the difference. But I do know what good things it brought to me: the basic things about usability, and understanding the boundaries of the device itself. When you know that you have to make a digital interface work with a hardware interface, you have your constraints, but I think that you can reinforce the UX concepts that you've learned and put them to work in another plane, one that is not as common as UX/UI for digital interfaces, as you said earlier.

[00:02:28] For me it's natural, but I think it can bring experience to others who have worked for a year, two or many years with digital interfaces, and suddenly they have a project involving hardware, which is very exciting. I really think that it makes you a more complete designer, thinking about the experience as a whole and not just focusing on one interaction. So that's the best thing I can say about physical interfaces and the mix between the two worlds.

Going to see how people really use the product

[00:03:13] Rory: Excellent. You gave a great example of having to go and see how people were using the product in real life. Do you think that is something hardware has that software doesn't? Because with a lot of software you have all of the analytics in the code, and you can have Hotjar tracking user mice and stuff like that. Do you think with hardware it's more important to do the go and see?

[00:03:43] Juan Pablo: In my experience it's definitely more important. But in my experience, what you learn about the situation, the way you grab your device, is something that I think is very important even if you don't have a physical interface to interact with. In the talk, you mentioned earlier the phone experience, when you have to put a card on the other side. And I think this is something to design for. If you think about WhatsApp, which is very, very common in Latin America, you see people grabbing the phone in a particular way that never existed before WhatsApp, that I didn't see before.

[00:04:49] So you have a handling and usability experience, a way that you grab the phone, that is particular to this product, and it's influenced by where the record audio button is placed. I don't know why so many people do that movement. I think this is worth researching. Or how you take a selfie: then you enter the dimension of how you're grabbing your device, even though you are designing for digital interfaces. So I think there's a lot to it, and it's important even when you don't have a device like the one we use. The device itself, a cell phone, a tablet or a computer, is already a researchable element in the ecosystem of the experience.

[00:05:50] Rory: Excellent, that makes a lot of sense. Did everybody on your team go out to those go-and-see sessions, or was it limited to one or two people?

[00:06:04] Juan Pablo: Well, this process started with myself alone, in a small business. I think most of the people working on the project didn't see the importance of this early on. So I started to do it, and I encouraged other people to do so. But a few, or many, times, the devs working on the application or on the device itself told me, "Oh, the other day someone accepted a payment with our POS, and I saw it, and it's quite okay." So there's a reward in seeing the result of your product on the street, in the mass market, that goes beyond the research itself.

[00:07:03] So when that happened, I encouraged people to go, and more people got involved by themselves: "Hey, you can experience the things that you were working on as a customer. Go to this address, try to buy something and see for yourself." So it started with me, but later it was more common for the people involved to go and see those places, and understand and live the experience themselves.

Involving developers and QAs early

[00:07:39] Rory: Excellent. Yeah, I'm a massive fan of getting everybody to experience how the users interact, because everybody sees it from different angles and picks up on different things as well. Just on that point you made, that some of the devs were a little bit hesitant at the start: you mentioned how important it was that you got the devs in early and got their ideas and their insights. How difficult was that? I want to ask from two angles. One is that I've been in a lot of companies where they don't let the devs onto a project until the scope is locked and they've got a design in place and things like that, so it can be difficult from that side. And the second problem is that sometimes the devs themselves aren't interested in doing that. They don't want to do it. So how did that play out for you?

[00:08:35] Juan Pablo: Yeah, it's a very good point. I spread [?] the idea that we have to involve people earlier in the process. It wasn't easy. I still struggle with this in new teams, to get them involved. The devs are very task-focused, "I have to do this," and they tend to go deep into what they are doing, but not see the overall process or the other sides of it.

[00:09:18] The first thing I can tell you is that at first it's like they don't want to do it, or they don't feel it's their work. But once they experience it, they feel involved. It's, "Hey, I'll show you some flows or some screens, what do you think?" And not "what do you think" meaning "hey, can you build this," because that's the first step: "Hey, we came up with the design, with a couple of flows. I want this button to do this and so on." And they come back with, "Oh no, I think it's a lot of work." That's the first point. But the second stage of this is, "Hey, what do you think? We did this because we've learned that the user might need this step in that process," for example.

[00:10:18] When this kind of involvement happens, they really like it. And I think the work that comes after this involvement, after talking about it in workshops and working this way, turns into better involvement and a happier process, and I think the overall quality improves a lot. I've seen them come up with great ideas. And not only devs: I always talk about QAs. QAs are great allies, and many QAs can be great product analysts too, or give feedback or input about the product, because they know the product better than almost anyone.

[00:11:13] So it was difficult, and it's still difficult, also for QAs. One time the QA leader told me, "Hey, don't bring the guys to the discovery sessions, because they have a lot of work to do, testing tasks and testing user stories. Please, they are overloaded." I said, "Well, yeah, okay, but I really think they can get a lot out of these meetings, and the testing process would also be a lot easier if they were involved in the first place. They can spot something that's not right in the task earlier." So with devs and QAs it's been a good experience, but it's hard. You have to build the culture and evangelize about it a lot, but I think it pays off really well.

Making the case for the next team

[00:12:11] Rory: Excellent. And do you think next time it will be easier, now that people are bought in?

[00:12:18] Juan Pablo: Yeah, I definitely think so, but you have to make a little case. If on one project you work with them, you make a case and say, "Hey, we worked together, and this is how it went." Doing a retro, and the people were excited, and worked more focused, or had more commitment to the project. So you can start to make a case to show the other teams, to implement this in a similar way. I think this is the best way.

[00:12:50] And one thing that we didn't talk about in my talk, but that goes hand in hand with the research, is working with metrics. That is another whole world, which shows why we are doing something and how it's going once we launch. So this is very important too, and it's the same path of involvement in the discovery process and iteration.

[00:13:18] Rory: Excellent. We're going to be jumping very deep into metrics later today, because Patricia gave a great talk on that. Excellent, we're a little bit ahead of time, but we did start early, so I'm going to try to spread the extra time amongst all of the people. So thank you very much, Juan Pablo, and Daphne, I think, is next.

[00:13:46] Juan Pablo: Thank you.