Server-Driven UI at Priceline

Anthony Padronaggio, Aadi Deshpande at UXDX USA. Video: https://youtu.be/fy1QzZdjZ6Q

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.

The parity problem between platforms

[00:00:00] Aadi: Hello UXDX, hey, how's it going? We're going to talk about this. I'm Aadi Deshpande, I'm a VP of engineering at Priceline.

[00:00:10] Anthony: And I'm Anthony Padronaggio, I'm a design manager at Priceline. Before I get started, I just want to get a quick sentiment. When trying to align your teams, or work within teams who are trying to align product experiences, does it ever feel like this? Just this game of professional tag, where there's always some kind of obstacle getting in the way of you two aligning. Someone pivots and you're just lost trailing behind them, and someone's always moving faster, one team's always moving faster than the other.

[00:00:50] Anthony: I want to go into a quick story. I live in New Jersey now, so I've grown accustomed to a level of drama. Now the Wall Street Journal is not really something you would think of when you think of drama, but I found their articles pretty interesting so I subscribed. I used to go on my news feed and view their web product via the news feed. But after every article, the comment section has always been my guilty pleasure. After reading the article I'd always like to scroll down and just go to the comments and see people getting into a fist fight about the new Fed rate cut. That really colored my experience in a positive way.

[00:01:29] Anthony: And just like most people, who eventually build some loyalty to a product, they download the app. So I did the same. I downloaded the app, read the article, scrolled down, no comments. My experience kind of went from something like this to this. I had one expectation and then I got here, and it made me not really want to go to the app too much.

[00:01:58] Anthony: So there really is an issue of parity between platforms, between experiences. We're setting up expectations in one platform or one product path and then subverting them in another. So why does this happen?

Why platform parity is so hard

[00:02:14] Aadi: Well to start, there's differences in frameworks. Not only between app OSes, but web and app. You can do all custom work, but then you're putting a load on developers, so when OSes change they have to keep up with the standards of the new OS changes. And then users are also finding new expectations when these OSes release these new pieces of functionality. They upgrade their components, and then you're left trying to catch up to their expectations.

[00:02:51] Aadi: So you've got a team, it's already facing a certain amount of headwind in terms of building parity, dealing with platform differences, and generally trying to put product out there. But obviously one of the challenges that maybe many of you have seen is that while these teams tend to be small and functional, what you're also faced up against is a whole mess of web teams that can seemingly move faster, do more, and deliver what feels like at a much quicker pace.

[00:03:23] Aadi: Every engineering team goes through the same sort of cycle. They go through trying to get to the release as quickly as possible, but it's not just one team, it's usually many, many teams doing similar things at different rates and different paces. In the app world specifically, you sort of have this view of having multiple versions of the app at any given time out there, so you're supporting any number of versions. And any version takes anywhere from two to three days to get out there in the wild, plus you don't get to go back. You can only go forward. Once it's out there on a customer's device it's out there for good. So we sort of have these real challenges in terms of managing expectations and delivering value, which feels a lot like this again, we're chasing it, chasing it, chasing it.

[00:04:20] Aadi: So what do we do about this? What do we do about platforms chasing features? Well, let's try to ship features to as many platforms as possible. What do we do about the duplicated experiences that we feel when we go from the iOS Wall Street Journal app to the Android Wall Street Journal app or the web app? Try to consolidate, try to put it all into one place as much as possible. What do we do about the lengthy time it takes, that we're trying to capture the same value that the web teams do? Let's try to ignore it, see if we can get past it some other way.

[00:04:59] Aadi: Which kind of brings us to server driven UI, our potential answer to this type of problem. Briefly, for those of you that don't know, I'll talk about what server driven UI is, which is essentially a way to describe the interface and interactions of a given client system on the server, so that it passes to your device and executes there locally and manages experience locally. But I think more importantly, it creates a uniformity around the control and management of the experience.

Rethinking design system foundations for SDUI

[00:05:35] Anthony: In order to enable an environment conducive to SDUI, we need to go to the foundations of our design system and rethink it. When you're in product teams that are focused either on a single product or focused on a single platform, your design systems may end up like this. People over time are adding more things based on the challenges they're meeting in that narrow view that they're looking at. As time goes on these things start to branch out, the design system starts to branch out, more components are added. In this case all the same color attributes are there from a brand perspective, but the way they're named, the way they're grouped, the way they're themed are all different and are all used differently.

[00:06:18] Anthony: Now imagine yourself as a designer and you're working in this new SDUI world where we want to start aligning these products, and you're creating an experience with the intention of bringing it not only potentially across platforms but across product paths as well. And then you have to set that for an Android developer. You've never worked with that Android developer, you don't really understand the expectations, and then you're going from this to this. There's a lot of continuity issues in between and it's really hard to translate from one to the other. So start by going to your foundations, aligning your foundations across platforms, because these are the things that are going to pervade to all the components downstream.

[00:07:06] Anthony: And then even other styles. There are styles where you may have completely different styles between platforms and products alone. In these cases, between the web, iOS and Android products, there are different shadows, and a lot of times it just happens where designers are just trying to match the look and feel and the expectation of the OS. But when someone starts moving from the web to the app platform, which does happen, you start to notice these differences. And again, when you're trying to align these things, these small differences start to needle in and it makes it less conducive to a successful environment for SDUI.

[00:07:41] Anthony: So we want to make sure not only are we aligning the naming conventions again, but also adding documentation for use as well, to help guide people through that process. But we're not just saying it's a one-size-fits-all thing where we're only aligning these shadows and that's it. It's really, what are the custom elements we want to align across, but we also want to have flexibility left over for these native features we want to keep supporting. Again, we don't want everything to be custom, because what happens is then you end up chasing features and chasing OS changes and all that, and if you're a small dev team or a small design team it's going to be hard to catch up.

[00:08:21] Anthony: So then, zooming in, we want to take a look at the different custom components that we want to align on, and then we want to zoom in a little bit more and say, hey, what are the molecules that we can align on from here? Because a guest review may be the same on a listings card for all products. A guest review from a hotel or a rental car or a flight provider, is the UI really going to change? Is someone going to look at a price in a hotel listing differently on web than they will from app? Not really. And at these places is where we can start to use SDUI to relieve some of that churn.

[00:09:04] Anthony: And we do this, we don't just decide, hey, web has the most traffic, we're just going to align to web. We come together and collaborate to decide what alignment actually means. So it's not just a one-size-fits-all approach and it's not a make a choice and move forward. There's collaboration that happens in between. And we don't just say we're going to do this and ship it out. We're an A/B testing culture at Priceline, we make sure we test these decisions, make sure we're validating them, and if they're not validated we come back to the table and decide what alignment means.

Governance: how you stop the tree branching again

[00:09:35] Anthony: So let's say we do all that, we spend all this time aligning design systems, aligning components. How do we prevent coming right back to this a year down the line, just doing the same thing over again and just getting back here? That's where governance is crucial. I don't know if anybody's seen The Martian, I'm sure you guys have at least heard about it. To sum it up, Mark Watney, he's an astronaut, he gets stranded on Mars by himself and he needs to survive. He does that by referring to a set of standards and protocols set by NASA. He uses limited resources and the standards and practices to be able to make independent decisions to adapt to the situation. Then later on he's even able to collaborate cross-functionally with people at NASA to drive his survival forward even more, and eventually even get off the planet.

[00:10:33] Anthony: Now we're going to stay here on Earth, our problems aren't as big as Mark's, but you can see how these can translate. Understanding what the processes are when you reach an impasse, when someone wants a crazy banner because they want to promote their feature the most, what is the process that a designer, a PM, a developer needs to go through to make sure that we're not deferring from the ecosystem that we set up unless we really need to?

[00:11:04] Anthony: Governance and alignment need to occur up and down the organizational chain. We need alignment at the leadership level strategically, we need alignment at the engineering level in order to make sure that we're building the right things together, we need alignment at the product level to make sure that the features are consistent with the user experience and the platform that they're being delivered on. That not only implies the fact that we know what we're building, but that the thing that we're building is the right thing, at the business level, at the product level and at the engineering level.

[00:11:41] Anthony: This is a quote by Peter Drucker, he was an organizational theorist, and essentially what this quote means is you can have as much strategy as you want, but at the end of the day someone has to adopt this strategy. That's your colleagues, that's you, who are going into this and saying, holy crap, that's a lot of stuff to do, I'm doing something I'm not used to doing. It's adopting a culture shift overall, and this can be pretty daunting. You're meeting with people you've never met with before potentially, you're changing processes that you've kind of got used to, you have those wagon wheel ruts that you've been moving through while you've been at this company, and now all of a sudden you're expected to change the way you work.

Scalable thinking instead of one-off solutions

[00:12:24] Anthony: So what are some of the expectations? As a designer, I've run into the issue of, I see a user problem and I want to solve that the best way possible, and what I see a lot of designers do is they think of one-off solutions. Here's the way I'm going to solve that problem, I'm going to release that into the world, and then I'm done, I feel like I've solved the problem the best way possible. But that's how you end up with this component landfill, and these disparate pieces littering your experience, because they're not zooming out and thinking of the entire user journey necessarily.

[00:12:58] Anthony: So we want to adopt scalable thinking, have a sustainable solution. When you're thinking about components, how does this work within the entire ecosystem? And go from thinking, hey, I'm a hotel designer, or I'm a web designer and I just have to think about responsive, or I only have to think about my Android design, to thinking more like, I'm a product designer, I'm a user experience designer for my product, and I need to zoom out and understand how the user enters this journey.

[00:13:30] Aadi: So change is implicit in this culture shift. We recognize that the things that we used to do before, we employed a certain set of skills, our engineers, our product people had a certain kind of focus, but we really need to think about this in a manifold way. We need to be able to recognize that there are skills that we need to acquire and tools that we need to put together in order to understand a broader landscape of technology. Teams will have to go from being essentially simple engines that are driving towards a singular focus, to somewhat more complicated machines that understand more about the nature of how things are built and the value proposition being driven towards. Thank you.

[00:14:20] Anthony: Oh, that's you. Oh sorry, that is me. I think when we talk about delivering faster, delivering for the customer and delivering more features in record time, who doesn't say no to that? This is something that leadership gets behind very, very easily, but the reality is that we're the ones stuck with that problem. We're the ones who have to manage the expectations and figure out how to actually build that process and build that strategy and build that governance for ourselves.

Building a support system through the change

[00:15:00] Anthony: To address this situation we need to build a support system. For instance, on the design side, a web designer might not have the knowledge base that an app designer would have, a hotel designer might not have the knowledge base that a rental car designer has. So employing a support system, we have a primary designer who is solely responsible for that experience. They're getting a user-centered problem that they want to solve for, they're the ones taking ownership over that, but they're not alone. There's someone who's there to assist them with those knowledge gaps.

[00:15:36] Anthony: This isn't going to last forever, these are transitional changes that happen, and to have that support system to guide you through these organizational changes is something that's going to help relieve some of that stress. And also just advocating to colleagues, to product managers, developers, managers, that there is some change that's needed, there is some growth that's needed, and giving them that space to be able to respond to that change is important.

[00:16:00] Anthony: Ideally this is where we want to get. Instead of staying in that tunnel vision of, here's my product, here's how I'm going to work in my product and that's it, understanding where we need to align, aligning the goals and the outcomes. Because if you don't align the goals and the outcomes, that's how we get back into spreading out and that tree growing in all different directions.

[00:16:26] Anthony: When you're able to use tools like SDUI and align these goals and align these outcomes together, then you can have that extra space left over to do the meaningful changes you really want to do. There are certain things that apps can do better, there are certain things that users want to know specifically about hotels. It's not necessarily the way we show the price, it's not necessarily the way we show guest score, but it may be something where someone says, I really want to see the landscape of the hotel, I want to understand the location better. Focusing on the differences, because the things we know should be common are easier to work with, we've aligned on those things already.

[00:17:09] Anthony: And then at the center of that we want to put the design team. So instead of the design team focusing on a platform or a single product, centralizing that, because that's the customer view. The customer doesn't only go into a rental car and say, I'm done. They're going to browse other products, they're going to look at different experiences, they may jump, like I did with the Wall Street Journal, from your web product to your app product. And if you don't have that zoomed out view of the customer experience, and you get this tunnel vision of, I'm just going to work within my product or platform, you're going to lose out on that bigger picture of what the customer is experiencing.

What you get out of it

[00:17:44] Anthony: What do we get out of this? I think from the design point of view, you get meaningful work out of it. You have ownership over what you do. You're not the designer who's just scaling someone else's idea, which is something that when we have this disconnected experience, someone else might be coming up with the idea for a new hotel product and it's like, okay, I've taken this hotel and now I just have to appify it. I don't think anybody wants to come to work and do that. So coming up with something where you take ownership of your experiences, I think it's worth the effort and worth the stress of that organizational change.

[00:18:19] Anthony: While previously we've had the idea that these teams are seeding ideas and cultivating new product features and really growing their own ecosystems, we sort of have to think about this a little differently and more broadly, and really go to a larger community where we're not just taking ideas for our platforms and our people, but we're really resonating ideas from other teams, our sibling teams or partners, and figuring out how they make sense in the grander scheme of things.

[00:18:52] Anthony: The environment previously looked like this. Every product, every platform had their own work going on, all different outcomes they're achieving, and you may work fast but you're working fast in only that direction that you're moving in. You're not moving fast together. So when you take the pieces and you put them together, are we really moving fast, or are we really just turning work in different directions and not really ever connecting where we need to connect?

[00:19:18] Anthony: So we want to move from this mess of an interstate to a product development superhighway, and we do that by aligning the things we need to align, following these processes, using the tools that help us align our resources together, having a system of governance to make sure we're driving this alignment forward, driving these outcomes forward, and we're not going back to what we were before, and having a support system to be able to make sure that we have people who are willing to adopt this cultural change and drive it forward into the future. So that's it, thanks.

Q&A

[00:20:00] Host: Aadi, Anthony, that was fantastic, thank you. So we have some questions from the live studio audience and the audience online. Is there any order y'all want to take this in? Because before you even start picking at it, I want to thank you for making governance cool, and for having as many memes as you did in your presentation. I don't know if anybody else, yeah, come on, hey, me plus. Yeah, nicely done. All right, where do you all want to start? Start at the top? Start at the top. Is server driven UI necessary if you only have a web app?

[00:20:44] Aadi: I think the answer here is you're already doing it. One of the challenges from the app design philosophy is that we are co-opting some of the philosophies that the web has always had. The notion of building the experience and then delivering it to the client is something that has always been a little bit of a challenge from the app perspective. So you have that mindset, and that's what we're trying to bridge, the gap between the app side and the website, to deliver that. If you want to add anything to that?

[00:21:14] Anthony: No, thanks.

[00:21:18] Host: Okay, cool, okay, got one. So how does a company like Priceline account for, let's talk a little bit about how Southwest might want to be represented in a certain way on Priceline versus maybe some other vendors or partners?

[00:21:33] Anthony: That's how we have partners, and that's where our design system comes in. We have to account for these when we're creating that unified design system. So while there's a focus on the design system on the web app, they're making sure that they're collaborating with app team people to understand these constraints. We need to be able to make sure that these colors will scale to other partners, we call them PPS, and we want to make sure that these color systems and these themes will scale to other partners. And again, that's why it's important, in the future maybe we want to scale these. Right now we only do it on the website, maybe we want to scale app products to Southwest too. If we set up the design system to work in that way and we collaborate in the gecko [?], then we're ready to go. If we start opening this up to Southwest on the app or in other products we're ready to go, because we're already accounting for these at the foundational level.

[00:22:24] Host: Fantastic. So have you run into circumstances where one vendor, I'm just going to pluck some out of thin air, so let's say you have Hilton and Hyatt. Has somebody like a Hilton come to you and said, I absolutely need to see it done in one way, and you kind of bend the system a little bit to account for it, and then all of a sudden Hyatt and everybody else wants in on it?

[00:22:50] Aadi: I think that's a governance challenge, it's an organizational challenge, but it's also a commercial challenge. Good design systems, like the ones we're trying to build, have a certain amount of variance that will attempt to accommodate these and respect certain people's brand ideals and wishes. But the reality is that it's never going to be perfect, and so we have to bring them to, yeah, I know, I know, shocker. But I don't know if you wanted to add to that?

[00:23:20] Anthony: No, that's a great answer. I wish Wes, he's the design director here, he'd have a lot better answer than I will, but I agree. It's accepting, like we were talking about before, there needs to be a level of flexibility in any design system to be able to drive it forward. But I think someone was talking about having that constrained flexibility is important, and dealing with those parts, trying to deal with them in that constrained flexibility sense, is going to drive you so far, and there's going to be barriers and challenges, and you'll have to see how your governance and your processes will allow you to drive through them. So maybe we will have an exception in those cases. We need to define those things ahead of time, so someone who is faced with those challenges will be able to move through them independently.

[00:24:04] Host: I love it, I think it's a super strong strategy for dealing with, and I'm sure this doesn't happen to anybody else, but when the key client comes in and makes those demands. Stellar. All right, can we just answer the percentage-wise how unified iOS and Android can get, because I think that's going to be a quick one? So you're going to do the percentage-wise?

[00:24:24] Aadi: All right. I think the answer that I would want to give is, I don't know if that's the question you want to ask, because you can spend a lot of time and build 100% uniformity, but ultimately are you getting the right value out of that proposition? Are you building to the best of that platform's abilities? And you're building for, even on platforms there are different types of customers. We understand how iOS customers tend to be on the high end scale, Android customers maybe on the lower end of the scale, and so they have different value propositions, and so we have to account for those differences. So uniformity isn't the answer, we're just trying to get to a better sense of uniformity. Sorry, sorry.

[00:25:01] Anthony: No, go ahead please. You have anything to say? It got cold in here. No, no, no. I think you really fielded the question in a graceful way, because what you didn't say was, that's the wrong question to ask, I'm not going to answer it.

[00:25:21] Anthony: And I think again, and it's still his words not mine, it's assessing the user needs and challenges for each platform. Like I said, I was talking about, a listing card is a listing card, that can be perfectly agnostic of platform, but there are certain tools and features that users might be expecting and you need to analyze which those are, and make sure that your dev teams have the room to grow. I've had problems before, not necessarily at Priceline, in other places, where things have been custom and then a new OS comes out and they need to change based on the standards that the OS has set, and now that's all that tech debt coming in, and that's time you're not working on the things you want to work on.

[00:26:05] Host: Love it. All right, what are you feeling, you want to take on the HIG question around iOS?

[00:26:13] Aadi: I think one and three are kind of similar in that sense. This is why we have a design team, design leads and designers. The guidelines of these systems are guidelines, they're meant to instruct and inform and drive towards a certain type of solution, but the reality is that you will make some qualified choices that this best describes the experience that you want to resonate. And so you will deviate from those guidelines at certain points. You might say, hey, a FAB makes sense here, or hey, I think I'm going to add a little bit of animation here. Those are the choices that you're going to make, and ultimately you're going to make them resonant with the customer and resonant with your platform experience. So uniformity is certainly not our goal. Our goal is to build the best experience we can in the fastest way possible and deliver for the customers that want to see our features rolled out as quickly as possible.

[00:27:16] Anthony: And just to add on to that, there's a collaborative process that happens here. He's a developer, I'm a designer, and we can easily have a researcher and a PM talking about this same thing, so it's not like we're doing these things in a vacuum. Asking these questions, we can use research to help validate the choices we make. We're making a choice, we're validating the choices and we're seeing what resonates. We're talking to developers to see, hey, is this going to create more churn for you for OS-level changes? We're talking to research and customers, is this impacting you positively or negatively? We're talking to the design system manager and designers, is this flexible enough to be able to solve user centric problems? And these things are all coming together, so it's not some one person making a decision here, another person making a decision there.

[00:28:00] Aadi: And for the second one, for that one come find me after this talk, I'll have you sign the NDA and we can discuss in depth.

[00:28:08] Host: And for those online, you can track them down and y'all can figure out that NDA thing. Aadi and Anthony, thank you so much, that was, thank you, thank you very much.