Designing the ‘Happy Path’: Lessons in UX and UI

[This transcript has be edited for clarity]

Jacob:

Hey, Jeff, welcome to another episode of the Human Friend Digital Podcast.

Jeffrey:

Hey, Jacob, today we have a guest on the show, my good friend Marquez White, who is a designer of user experience, user interaction, started out in graphic design, and has worked for companies like Kroger, Grubhub, Dropbox, to name a few of them.

Jacob:

So I’m glad he’s on the pod today because this is a topic that I have been, uh, not unaware of, but a little squeamish around in my career, because as a web designer, I have to dabble in UI. I have to dabble in UX, but a lot of times,, I’m kind of like an engineer that gets handed these pieces and this stuff that’s been thought through with a designer or with the product manager.

As we go into discussions later, see, I’m already using the terms Marquez is about to teach you on the pod, I’m getting smarter from this conversation with him, and I really liked that. So we’re going to go into insights and break down UX, UI, graphic design, how it works and the importance of UI and UX design for companies and why they should prioritize this.

I think some of the best parts of the interview coming up are when we dive into some of the philosophy and structures around getting really good UX, user experience, to make that a reality.

Jeffrey:

Okay, so without further ado, um, here’s our episode.

Jacob:

Hit it.

Jacob:
I’m happy to have someone on who’s a real expert. So Marquez, thank you very much for being on the pod today.

Marquez:
Happy to be here. Thanks, guys, for having me.

Jeffrey:
So Marquez, you’ve been in the design world for like 10 years, 9 years? When did you start?

Marquez:
Um, started, I think, back in 2014-ish.

Jeffrey:
Okay, so like a decade.

Marquez:
It’s a little bit blurry, but that feels about right.

Jeffrey:
I mean, I don’t remember when I was 24 either. Not that that was your age, but that was my age. And you’ve been in different roles—UX, UI, graphic design—for different companies. You’ve worked for Kroger, you’ve worked for Dropbox, Grubhub. So can you break down a little bit what UX, UI, and graphic design are, and then how they’re differentiated from each other?

Marquez:
Yeah, so that’s a thorny one. I think I want to preface this with, you know, you’ll get 10 different answers when you ask 10 different people. So I’m going to speak directly from my experience and what that’s been.

Jeffrey:
Sure. Yeah, absolutely. 

Marquez:

And maybe I can add some color there in terms of someone who’s listening to this, who runs a company—whether they’re going to want to hire a graphic designer versus a UX designer versus a product designer or whatever—what’s going to be relevant for them.

So I think just looking at my background, starting out as someone who was more on the graphic design side, what that meant was, you know, when I started, I was initially freelancing. And when I was at UC, I was like a student…

Jeffrey:
University of Cincinnati?

Marquez:
University of Cincinnati, right. I was doing freelance work, and I was taking courses around Gestalt theory and advertising and thinking about what are all those psychological aspects of design that influence people from a visual standpoint.

Jeffrey:
Going to stop you right there. The what theory?

Marquez:
Gestalt theory.

Jeffrey:
Okay, what is that? Sorry, I don’t want to drive you off course, but—

Marquez:
No—

Jacob:
I was thinking the exact same thing.

Marquez:
Yeah, so it’s a fair question. It’s a series of principles that underlie anything that’s visual and why things look the way they do and why they influence people. So maybe an example of that could be when you see something laid out in a composition, whether it’s a painting or an interface or a website, things that are situated closely to each other tend to be associated with each other, right? And things that are further apart are perceived as being less related. So that’s just one example.

Jacob:
That sounds good. Is that also tied into the same thing with colors? Sometimes with food brands, you’ll see they use orange a lot because orange is associated with food thoughts. Is that part of the same school?

Marquez:
Totally, totally. So color theory is also part of that theory I was learning back then. Warm colors, cool colors, and when to use what in which situation. And back when I was taking a bunch of those types of courses, I was doing freelance work for friends who were in student groups or running student groups, and they would throw events, and they would need to get the word out about them around campus. So I would make posters or banners for their Facebook pages and things like that. And that’s what I mean when I say graphic design. It’s more centered around communication, being informative, and solving problems around communication.

Jacob:
I could see a lot of people seeing that as like, when they think of design, that’s probably where they first go—what’s on a poster, what’s on a label, what’s right in front of me.

Marquez:
Right. And so, that’s something I was doing more toward the beginning of my career. Then, when I joined Kroger, that’s when I first started getting into the product side, product slash UX/UI, I guess. And the ambiguity around those labels is something I can maybe also clarify.

Jacob:
Yeah, one thing you should do, and I don’t think we’ve done it so far in the episode, is explain what UI stands for and what UX stands for.

Jeffrey:
Yeah, good point, Jacob. We haven’t actually defined those terms.

Marquez:
Yeah. So UI stands for user interface, and UX stands for user experience. And the reason that’s a little bit problematic is because technically, the UI is part of the UX. So it’s kind of a misnomer, right? The user experience is the total sum of the experience you have with a product, service, or company. So, you know, you’re making a doctor’s appointment at UCHealth, maybe—

Jeffrey:
I use UC.

Marquez:
Yeah, so your user experience is going to be… I’m trying to make it relevant…

Jacob:
I think you’re doing great. We’ve all been to a doctor’s appointment.

Marquez:
Right, so your user experience is going to be: how do you find the doctor? How do you find out if they’re accepting new patients? Are you clicking on an ad on Facebook page or Instagram? How do you find out about this? What’s the experience like making an appointment on their website? Are you able to find a time slot that you need? Are you able to see a doctor about the specific issue you have, or is it just a general checkup? Then, what’s your experience going to the doctor? Are you able to find parking? Are you able to find your way to the office and navigate through the building?

Jeffrey:
So user experience encompasses more than just my interaction with them on the app. It goes beyond that?

Marquez:
It goes beyond that—like everything.

Jeffrey:
So it’s the total user experience with whatever it is you’re doing, whether it’s a doctor or buying groceries from Kroger. That’s all UX. That’s all user experience.

Marquez:
Correct. So then the interface is what you interact with to accomplish or solve the problem you’re trying to address. The screen, the buttons on the screen, the app or website, or maybe it’s a kiosk at the hospital where you’re trying to find out where to go—that’s the interface. It’s something you’re interacting with to solve a problem.

Jacob:
So not all UX is UI, but UI is a part of UX.

Marquez:
Yes, that’s right.

Jacob:
Okay. This reminds me of something—and this is one of my first tangents, sorry. When I was first doing digital marketing about 12, 13 years ago, the owner of the company was obsessed with this thing he called “touch point analysis.” He would map out every single interaction the customer had. Any place where a website or an app interface was required, that would be our wheelhouse. Is that similar to what you do in your line of work, where you map the whole UX and then go in to identify each thing?

Marquez:
Yeah. One of the classic design methodologies is “journey mapping”. So, mapping out a customer journey to understand all the different touch points in the customer experience. If you’re placing an order on Kroger.com, the journey you take to place that order, and then your interactions that take place outside of the app or website. You get a text—a confirmation text or an email confirming the order. You might get a text if some items are unavailable in your order. You get a text when the driver’s on their way. All of these things are touch points in the overall experience. That overall journey is something we try to map out to make sure we’re accounting for everything that a customer might run into when using a product or service.

Jacob:
So a lot of it is really anticipating things. You’re trying to get inside their head—kind of like a detective… crime scene is maybe not the best way to describe it but, how do I get the customer to get to this incident to happen…

Jeffrey:
Why did you go to “crime scene” Jacob?

Jacob:
Well, it’s like a detective thing. You’re a little bit like a detective hat on. Like, you know, you got them to buy it. You want them to buy this thing. And you got to get your detective hat on to figure out all the things, the steps that they took to get there.

Marquez:
I mean, it is a little bit like that because you have to anticipate. When you’re designing, you might have this “happy path”—a term we use to refer to when everything goes right and nothing goes wrong. But you also have to be mindful of what could go wrong in that experience and what friction points a person might encounter, and how do we solve for those, whether it’s something in the interface or something outside of it? If it’s a communication thing, maybe we have to work with the marketing team to ensure we’re sending the right texts, that they’re worded properly, and that they make sense in the context of what’s being used.

Jacob:
I like that. I want to make a note of that, the “happy path.” I’ve not heard that phrase before, but it makes a lot of sense to think about it like that and focus on an optimistic view. One of the things that I came across in that touchpoint analysis version of this was, instead of focusing on all these happy moments, they always looked for points of friction or places where everything slowed down.

Jeffrey:
That’s like the inverse of that.

Jacob:
Yeah. I like the “happy path,” though, because it’s optimistic. So where does graphic design come in? Because a lot of times, you’ll see job postings or things like that where they say “UI/UX designer,” right? So how do you get to the design part of this? You’ve got this great, beautiful map and this path for people. So, connect the word “designer” fit into this mix?

Marquez:
Yeah, so maybe I can speak from my perspective a little bit as to how that crossover happens. I think a couple reasons… A lot of people in this industry do cross over from graphic into product design because it uses a lot of the same core skills. Core skills around: What makes a design good? What makes a design not work? Are you using color, typography, and layout efficiently? Those are basic, foundational skills that you have to know to design something that solves someone’s problem.

So, if you’re not good with typography, you won’t be able to create a hierarchy that’s clear in an interface, that’s readable, and that someone can follow to accomplish their goal. If you’re not able to use color efficiently, you won’t be able to call attention to certain things in an interface to make sure people are aware of what’s important to focus on and what’s not as important.

So, those are foundational skills that make it possible for someone to cross over from graphic to product design. When I say “product design,” it’s another name for UX design. I hope that that somewhat makes sense.

Jacob:
It makes sense to me, but I do this all the time.

Jeffrey:
No, I think it does make sense. Can you say how those same skills are useful in product or UX design? Why is that skill set useful?

Marquez:
I think here I can maybe add some color about how products are typically built within companies. Typically, you have what’s called a “triad,” and a triad is composed of design, product management, and engineering. This is essentially what teams look like within any company for any app or product—Facebook, Instagram, TikTok—literally any company. This is how products are built internally.

So you have this triad. Typically, product managers are in charge of thinking about the problem we’re trying to solve, and what data do we have that suggests this is a problem worth working on? How does the business benefit from this? How does the user benefit? How do we ideally meet that sweet point where we can align both business and user goals? They’re thinking about all the business side of things.

Then engineers are there to figure out how to build it—how to bring it to life, and what are the backend technologies and APIs we need to plug into to make this thing work, this product that we’re thinking about?

Jacob:
Just a quick note for listeners—the word “engineer” is often used to talk about civil engineers, mechanical engineers—those physical-world processes. This is like your code developers and the people turning your designs into reality, making sure when you tap something, something really happens.

Marquez:
Yes, a software engineer.

Jacob:
There we go, yeah.

Marquez:
That’s correct. They’re there to inform the tech side, and design is there to bridge the gap between those things: user goals, business goals, and tech constraints—design is there to bridge the gap between all of those things. I’m working together with product managers and engineers to ensure that what I’m designing meets three criteria: it has to be desirable, it has to be feasible, and it has to be usable.

So, desirable in the sense that people actually want this feature; it has to be feasible, meaning the engineers can build it; and it has to be usable, meaning someone can use it easily. They can look at it and say, “Oh, this is clear,” without having to think, “How do I get here? How do I get there?” They can actually use the thing.

Jacob:
I’ve worked with a lot of graphic design companies, or companies that focus on branding and design, and they’re smart with big ad campaigns. But none of the designers I worked with did what you’re describing. This seems like a whole different skill set with UX/UI design people like you, with those three things you just listed—what was that? Feasibility, desirability, and what was the last one?

Marquez:

Usability.

Jacob:

And usability. That’s really cool.

I have one more question, then Jeff can hit you with another. My question is, In that triad, who is the person creating the ideas to make new designs? Is it the product manager lording down to you guys, or is it collaborative where you’re coming up with ideas, too? Or is the engineer…

Jeffrey:

Or is it bottom up, from the users?

Marquez:
That’s a really good question, because it varies so much depending on the company, or even within the company. Different teams have different ways of working, different processes, and even within teams it can depend on the project and how much risk it carries for the business. If you look at a spectrum, on one side you have something that’s super risky for the company, like building a completely new product people have never used before. On the other side of that spectrum, you have something that’s maybe not so risky because it’s something that already exists, like making an update to an existing feature.

The process you use as a designer and as a team will vary depending on where you are on that spectrum. On the riskier side, where there’s a big investment in time, engineering hours, and design effort, you want to do a lot of research up front with users to understand whether this will solve their problem. On the other side, maybe we have something that already exists and we know people like it, based on data. So, all I have to do is make a simple design update, and we can launch it right away.

Jacob:
That’s interesting, especially when thinking about different stakeholders in the process and their feedback and how that plays out. You’re kind of getting pulled around.

Marquez:
It’s extremely political, and that’s a whole side of the job… You have to really love making things and seeing them come to life to thrive in this, because it does get political. Everyone has ideas about how something should look, how it should work, or whether we should be doing x and y.

But, it’s very collaborative, and you have to be diligent in making sure you’re able to influence people and use design to do that. I’ve seen people get really excited when they see something that doesn’t exist yet. If I put together a prototype, just walking through a feature—it doesn’t even have to be something super complex, it can be something basic—but this thing, it doesn’t exist yet, and I’m showing someone what could be possible if we built this. So people get really excited by those things and it’s very influential. And I’ve had that work in the past. But there are also times when I’ve worked with product managers who say, “Maybe this doesn’t make sense for us to do right now. Maybe we can do it later as a fast follow.”

Jeffrey:
A fast follow?

Marquez:
Fast follows are things not in the scope of the original project, but we’ll get to them later if we have the time and resources.

Jeffrey:
It’s like the new Apple phone  where it’s like “oh yeah, this is going to be AI capable. We don’t have it yet, but someday soon we’re going to have all these features, even though they’re not currently available.”

Marquez:
Yeah. As a designer on a team, it can be demoralizing to hear that over and over again. The compromises we make build up over time and can contribute to a product that’s less polished.

Jacob:
Gotcha. Okay.

Marquez:
It requires a lot of influence and collaboration with different cross-functional stakeholders, who may or may not have a background in design.

Jeffrey:
I think that leads into the last topic we want to cover: Why should the higher-ups care? How do you defend your work when people are asking, “Well,  you know, the money—do we really need this feature?” blah blah blah blah blah.

Marquez:

Yeah, I think there’s kind of two ways you can go about building a product. One way is to research what people actually want upfront, invest that time and effort upfront, and then design the thing that people want, and then build it and launch it, and go into that process with confidence that you did that research upfront.

Or, what you could do, and what’s actually really common, is that the CEO comes up with an idea, or some product manager comes up with an idea, they have a designer design it, and we don’t have full confidence on this thing yet, and whether or not people want it, but we think it’s a great idea. We think we know what our customers want.

Jeffrey:

Like Google Glass? Well, the thing is, people actually do want Google Glass, they just jumped the gun by like a decade.

Jacob:

Well, they also made it look pretty dorky.

Jeffrey:

Have you seen the Meta glasses? I mean, they look worse than the Google Glasses.

Marquez:

I haven’t seen them, but yeah, I mean, there’s plenty of examples of this out there. If you even think about a lot of what I’m hearing about AI is that people don’t respond very well to it. When they see that it’s in a product, it makes them a lot less open to using the product, and it decreases the trust they have with the brand.

But like, there’s a ton of examples out there of something that was probably like a CEO’s idea, and it was top-down, and it’s being pushed very heavily as something that the company should do, not really having the knowledge yet that it’s something that people want. And so the plan is to design this thing, have engineers build it, and then launch it into market, and then we learn whether or not people want it. So you’re investing all of those resources upfront and then saying, “Well, we don’t know if this is going to work out yet, we’re just going to build and learn.”

So those are kind of the two different ways that you can build a product, and really the latter of those is more expensive because it takes a lot of time and effort to be able to design something and build it, and there’s a lot of investment there.

Jeffrey:

And then people might not even want it in the first place, right?

Marquez:

Right, because if you take something to market and it doesn’t do well, then what was all of that effort for? When you could have done a lot of that research upfront.

Jeffrey:

To satisfy the ego of your CEO, clearly.

Jacob:

Now, I have a question about… You know, there are a lot of different design programs out there, like Figma’s really popular, XD’s really popular. Which ones do you tend to feel are pretty solid for what you do?

Marquez:

I spend most of my time in Figma. I’d say that’s probably the industry standard at this point. I think maybe a different conversation that’s… I don’t want to go too deep into this, but it’s something I’ve been hearing a lot: the “what’s next” part of this.

Jeffrey:

We can get a little nerdy, that’s okay.

Marquez:

The limitation with Figma is that ultimately what you’re creating is a picture of what’s going to be coded. It’s not like a one-to-one representation of code. So there’s a new title I’ve been seeing pop up called “Design Engineer,” where basically it’s like designers who know how to code. The thinking being that the closer and closer you can get to actually creating something that’s going to be functional and interactive, the better. You’re going to be able to blur that line between design and engineer versus what we have right now, which is this handoff between design and engineer, where the middle of that can be a little bit messy because you have two people who are using different mediums for their outputs and speaking two completely different languages. So there’s a lot of translation there that needs to happen. 

So, I’m working with an engineer, and I have to be able to communicate to them what this design is trying to accomplish, and they’re telling me back why or why not this is possible based on whatever backend technologies they’re using or whatever needs to happen.

Jacob:

I’m in that boat a lot on the engineer side because I often would take graphic design files and turn them into website files. So I get that for sure, and there is definitely a disconnect. I definitely see that to be the future for sure. I see some hints of that as well. I’m really expecting, maybe not this first round of the new GPTs this year, but the GPTs of next year, there’s probably going to be one that is like a Figma switch, and whatever you design in Figma, that GPT model is just going to spit out the code for it immediately. Then they’ll put it on some… almost like Webflow. Well, I think Webflow has been trying to achieve this for a long time, at least for website development, where you can be a hands-on graphic designer, and it outputs to web.

However, Webflow is a heck of a learning curve that tool is. It’s not really approachable for even everyday designers because it’s like a whole other toolkit you have to learn. But, we’re getting out in the weeds a little…

Jeffrey:

I don’t know what we’re talking about anymore, so…

Marquez:

If I can just pull it back. So Figma is what I use day to day. And yeah, Figma’s great for putting together high-fidelity designs. What it’s also trying to do, with some of the auto-layout features and design systems, is it’s teaching me and designers a lot of what they might need to know when it comes to that code background. So how things actually need to be laid out in a web space, with Flexbox, and getting people to actually think about—be a little bit more intentional about—how something is going to come to life in code.

Jacob:

Yeah, exactly. Especially because in your line of work, everyone’s going to touch it. It’s a very physical output in the end because it’s going to be on a phone, and someone’s going to have to actually scroll, touch, rotate it around. You’re going to have device information coming in, geolocation stuff, and it’s like, “Okay, this is a real physical thing.”

So to that end, let’s talk about some of the things that you’ve done—some of those fun projects.

Jeffrey:

Yeah, do you want to do a case study of something that sort of illustrates what we’ve been talking about this whole episode?

Marquez:

Yeah, yeah, so I—

Jeffrey:

As long as you’re allowed to, vis-à-vis NDAs.

Marquez:

I’m allowed to because it’s public. It’s been public for many years at this point. It’s not something that you’re going to be able to access unless you’re a driver with Grubhub, but it’s out there in the public.

So, one of the roles I had at Grubhub was on the driver team. Similar to how there’s an app that you would use to order food, there’s an app that the drivers use to manage all the logistics around pickup and delivery.

An example here is that a driver might get to a restaurant and discover that the food’s not ready for them to pick up yet. Logistically, there’s a million reasons why that could be the case. But the main thing for my team was to figure out how do we get drivers in the driver app the tools to be able to self-solve in those situations, so they can move on to their next delivery and we can cut down on driver support contacts in the process.

Jacob:

I did want to say, just so it’s clear—usually when people think of user experience, they think of customers going through this. But you’re doing the user experience for the driver.

Marquez:

That’s correct. There are customer-facing apps we’re all familiar with, but then there are internal-facing apps—things meant to be used by employees at a company. In this case, it’s a driver app. But it could also be something like Salesforce, a B2B product. So there’s B2C products, there’s B2B products… So, with Grubhub, it was what’s called a “three-sided marketplace:” There’s a restaurant-facing product they use inside the restaurant on a tablet to manage all the orders coming in. At Grubhub, we had teams of people for all of these things.

Jeffrey:

I’ve been on that restaurant-facing side of that triad—not for Grubhub, but I did it for DoorDash and for Uber and they sucked.

Marquez:

Yeah, even at Grubhub, there was a lot of room for improvement there because it’s such a legacy, outdated thing to use. Employees at a restaurant have a million things going on, so they don’t want something complicated. They need something that’s going to work.

Jeffrey:

Yeah, that was always the big thing. It’s just like if something goes wrong, none of us have the bandwidth or the time to fix it or to get on the phone with a customer representative to figure out what went wrong. We can’t. And then, you know, that whole order fails because of it. And like I said, I never worked with Grubhub in any restaurant that I’ve been with, but I’ve worked with the other ones, and it was just like, if something went wrong, and I’m not saying that they did often, but when they went wrong, it was just like, “Yeah, I can’t handle this right now. I have 30 people in the window trying to get food.” So, yeah. I mean, that has to be a huge challenge for them. But you were on the driver-facing team.

Marquez:

That’s correct. And so, specifically with the problem that this specific project was, a case where, you know, looking at a driver, we had a driver support team internally who would be fielding texts, calls, and emails from drivers when they’re out doing deliveries, and they run into an issue, right? And so, they reach out to the driver support team, and in this case, we were getting a lot of calls from drivers who, again, would arrive at a restaurant and they discover that the food’s not ready for them to pick up. And there are a couple reasons why they’re calling. So, number one, they want to vent frustration about the order not being ready. And, you know, it’s valid frustration because it could either be because the restaurant is just really busy and they need more time making the food, or maybe Grubhub’s dispatch algorithm sent them to the restaurant too early. But in both of those cases, the only solution is for the driver to just wait for the food, because Grubhub cannot call the restaurant and tell them to hurry up.

Jacob:

They’re not going to want that call.

Marquez:

Right, so that’s not going to happen. And the other thing is the driver wants to express a little bit of concern, right, because they’re concerned that if the order ETA needs to be pushed back, and the food is late getting to the customer, that they’re going to be blamed for it. So, it’s something that’s completely out of their control, so they shouldn’t be blamed for it. So they’re calling driver support to complain about these things. And these calls are making up like a high majority of the contacts that we’re getting from drivers at this point in the delivery flow.

So at the beginning of a project, what you want to do is define what is the problem that you’re trying to solve, which I’ve sort of outlined, and then define what the success criteria are going to be. So as a team, how are you going to be able to look back and say that this thing we built actually solved that problem? And what are we going to measure to be able to say that? So in this case, you know, we had this problem that we defined, and then we defined the metric: we want to be able to decrease the amount of support calls that we’re getting from drivers at this specific point in the flow.

Jacob:

Yeah, so what was the success? I mean not maybe the success, but how do you get there? I mean, I’m sure you’re about to tell us, but I want to know.

Marquez:

Yeah, yeah, yeah. That’s a good question. So we have the problem defined, and my role in this project was really collaborating a lot with the driver support team to be able to figure out what are those specific issues that drivers are calling in about, what’s the frequency of those calls, so getting that success metric, and then figuring out which of those calls can a support agent can actually solve over the phone and what they cannot. So, again, there are things that a driver support agent cannot do, and that’s call a restaurant and tell them to hurry up making the food—there’s no control there.

But what else could go wrong? The order could have gotten picked up by another driver from another delivery service, or there could have been a glitch in the software that caused the order to never make it to the restaurant. So those things need to actually be solved by a driver support agent because what they’re going to do in that case is either cancel the order or resubmit it to the restaurant manually. 

So the existing flow in the driver app was built in a way that we wouldn’t do any investigation with the driver when they request a support agent to be able to understand which of those buckets the problem falls into, so whether the order is just not ready or whether the order is missing. So that investigation needs to be done before we can figure out whether we actually allow the driver to contact a support agent and for that call to actually come through.

So what I designed was kind of this branching flow where a driver would be able to go in, and if they want to contact an agent, they can still do that. But before we let that contact go through, we’re introducing this new flow where a driver has to indicate whether that order is just not ready or whether it’s missing.

Jacob:

Is that like a little pop-up that’s like, “I need help,” and there’s some questions—that kind of a thing?

Marquez:

Yeah, yeah, yeah. So, there’s a pop-up with this dialogue box where they can indicate if the order is not ready. We introduce this questionnaire screen where a driver is able to say if they’re able to get in contact with someone who works at the restaurant, whether it’s just an employee or an owner there, to dig into a little bit of the “why” behind the order delay, like why is the order delayed and how long do they think it’s going to take, whether it’s like five to twenty minutes or longer. And that’s data that we’re collecting to be able to do two things eventually:

One, we want to be able to hold our restaurant partners accountable in the event that we’re seeing repeated reports from drivers of orders being late. And then the other thing is that we want to be able to use that data, because if we know that certain restaurants are consistently behind at certain times of the day…

Jeffrey:

You can optimize…

Marquez:

We can then optimize our dispatching model to account for that, so we can send drivers to the restaurant later so that the timing matches up a little bit better.

Jacob:

That’s pretty good. That’s pretty smart. I was a delivery driver for a while before all this gig economy stuff took off, and so I would always have to be like… depending on the time of day, I was doing this manually, right? Like, someone would call right in the middle of the dinner hour craziness, and I knew how long the books would take to need it. So I was giving time estimates based on here’s how busy we are, here’s how many drivers we have, where are you located, and…

Jeffrey:

Who did you deliver for?

Jacob:

Hooligans Pub, the finest eatery in Pleasant Ridge, and served the most Irish food of all: buffalo chicken wings.

Marquez:

Delicious.

Jacob:

It’s just like a chicken wing delivery place. I mean, we went all over town, but… So you’re anticipating all of those things in an app so it can do it automatically for people and almost learn a little bit about what it’s like to be at that restaurant and work there. Because if a person at the restaurant could probably give you an accurate estimate, you’re trying to have the app learn like it’s a restaurant employee and then be like, “Oh, I know if it’s Hooligans Pub, I shouldn’t say it’s going to be ready in 15 minutes right now at this time of day.”

Marquez:

Yeah. And I mean, as a driver, you felt that pain, right? You did a lot of that work manually, and you in your head were saying, “Well, I already know this restaurant is going to be running behind, so I’m just going to wait to go there,” versus like if the app were just telling you the exact time that the food is going to be ready, then you can trust that. But when that mismatch happens between what the ETA is and what the driver thinks it actually is…

Jeffrey:

And they have to sit in the restaurant for 15 minutes waiting on the food, and they’re losing time, they’re losing money, they’re…

Jacob:

They’re going to lose their tip too. You know, they’re going to…

Jeffrey:

And then, yeah, potentially the customer’s going to be like, “Yeah, why was it so late? Did you go to the strip club?” I don’t know.

Jacob:

Bad side story: There was a delivery driver at the place I worked, and he did go to a strip club once while on shift. That’s a real thing. It really happens. And then I got this call from this lady—it’s like midnight because we were a late-night delivery place—and I don’t know where this guy is. He comes back, he’s reeking of booze, and then he just declares that he went to a strip club, and then he quit.

Jeffrey:

See, Quez, it’s not the restaurant’s fault. It’s the drivers going to strip clubs. That’s the fail point.

Jacob:

It’s real. It really happened.

Marquez:

You got those outliers, I guess.

Jacob:

Anyway, so now…

Jeffrey:

So then there’s the second bucket.

Marquez:

Yeah, so the first bucket is order is not ready. Second bucket is order is missing. So if the driver indicates they get to the restaurant, they can’t find the order, whether it’s because it got picked up by another driver or it just never made it into the restaurant system, right? And so, in that case, we allow the call to come through if the driver has indicated they checked with the restaurant, just asking someone if there was a mistake in them actually getting the order. So if that’s the case, we allow that call to come through, and then the agent has to actually resubmit the order to the restaurant manually.

Ultimately, you know, in that first bucket, after we collect that data from the driver around why the delay, how long the delay is going to be, we inform them like, “Thanks for the heads up.” They’re not going to be affected; like their acceptance rate is not going to be affected by the late order, to ease those worries around whether or not they’re going to be negatively affected. And what we also continue to do is give them the option of dropping the order if they don’t want to wait for it.

Jeffrey:

So they can pick up another one—they could pick up another order, right? So they don’t lose money, is that the…

Marquez:

Right, they can. If they don’t want to wait at the restaurant for the food, they can drop the order, and that’s always been the case. But that does affect their acceptance rate.

Jeffrey:

Oh, okay.

Marquez:

So that’s the trade-off there, and that’s something that we can continue to inform them of in this flow. But, you know, ultimately, what the outcome was, was that we were able to decrease calls to driver care in that specific scenario by about 40%. So that’s kind of evidence that that flow was effective at decreasing those calls and then allowing drivers to move on instead of standing there at the restaurant, wasting time trying to get a hold of driver support. They can actually go into this flow and self-serve a lot of that work and then move on to their next order.

Jacob:

Well, that’s a big decrease—40%. My question is, since the word “designer” gets thrown around in here, what was the design part of this that you were working on? Because this sounds very much like you were hands-on, like… not to say crime scene investigator again, but you were figuring out this frequent crime that was happening in the Grubhub app for the drivers for this and you solved the problem. So where does the designer… where do you put on the design hat? Where does that come in?

Marquez:

So I would say, like, when you think about, like, going back to those labels of UI, UX, vs. product design, this is where that divide happens. Where, you know, someone who calls themselves a product designer, they might be a lot more in the weeds on not only what this thing looks like, but how it needs to function, and what are all of the inputs that actually inform that. So, from a business standpoint, how are we going to benefit from this? How is the user going to benefit from this? And then from an engineering standpoint, what are all of the tech constraints that sort of inform this? Even working with driver support to understand what’s the data that we’re seeing there, and how does that need to inform this? What are those internal SOPs, like what’s happening on the other end of that call?

Jacob:

Oh, no, no. You said an acronym. You’ve got to define it for the listeners. What’s an SOP?

Marquez:

So, SOP is the process that driver support agents work through on the phone when a driver calls in. So this project was about taking that process that happens on the phone and bringing it into the app that the drivers are using so that it’s less manual and more automated, and then drivers can work through that themselves without needing a support agent.

In order for me to actually be able to create, like, design a flow that does that, I need to know what that process is. And I can only know that by speaking to a support agent who’s more familiar with that process than I am. Even the visual part of it, it’s not anything super fancy, but it’s more about process. And the screen that I actually created, you can go to my website and look at a prototype of it, but it’s mostly just text and checkboxes and just a simple flow, right? Visually, it’s not anything complex, but it’s more about taking this manual process and making it a little bit more automated. That’s sort of the design part of it. It doesn’t have to be anything super visually striking.

Jacob:

Yeah, because, yeah, you’re not trying to do an ad campaign in the middle of a driver’s utility app. You’re trying to make sure it’s useful for them, so you’re just trying to make sure they have the right kind of interface tools to get the job done. So maybe the word “designer” is thrown around a little loosely within the industry—not to say that it’s not… I’m saying more like… How do I say this? When people say “design,” they think of graphics. But sometimes in your line of work, when you’re talking about design, you’re talking about this hybrid moment where usability and graphics are interlocked, and it’s very, like you said, process-driven, like, “I have to make sure this is a very usable thing at the end of the day.”

Jeffrey:

I don’t think it’s a loose definition of design. I just think it’s a more true definition of design. That’s what you do when you design something—you’re solving a problem. And yeah, maybe the default understanding for the layman is like graphic design, but you use graphic design in your industry a lot, so it’s not a surprise that you default there. But, no, it’s just because, like, think about industrial design. Industrial design isn’t about looks or graphics. It’s about solving a problem in conjunction with engineers, like software engineers or mechanical engineers. The person who intersects that gap is a designer, usually, I would think.

Marquez:

Yeah, I think we solve business problems. That’s correct. And I think it’s not really a layman versus not layman understanding, it’s more so about the different problems that you’re actually trying to solve. So I would say my experience from graphic design is that most of the problems there are communication-based, and you’re trying to solve an information problem, make something more informative, or increase visibility of something, right?

In product design, there can be a lot more variation there in terms of the types of problems that you’re trying to solve. And yeah, I mean, it’s very similar to industrial design in the sense that industrial designers have to be knowledgeable about not only what they’re creating, how, like, what it looks like and how it works, but also even they’re concerned about supply chain and how it’s going to be manufactured, right? They have to be knowledgeable about manufacturing processes and materials. And when you’re designing software, it’s a lot of the same thing. You don’t have to know how to code, but you have to know how this thing is going to be coded.

Jeffrey:

Whether or not whatever code is required is feasible. I mean, bringing it back to the three-pronged sort of needs that you said, like, is that code feasible? You have to be aware of that in…

Jacob:

The word in the industrial sector, what is it? Design for Manufacturing and Assembly—DFMA. So you have a good parallel to that for sure.

So, for our listeners, we’re going to give out Marquez’s website link in our blog post on our website. The case studies in there, I have to say, are really detailed, really walk through the flow of everything you just described today. And for a visual representation where you can click through, definitely go on there and scroll through. I think you, as a UX/UI designer, Marquez, you make a very functional presentation for people to look at. It’s very clear that you’re like, “I have thought about how this should be presented to be the most effective, look clean…”

Jeffrey:

Hey, he’s been doing it for a decade.

Jacob:

Yeah, you can’t miss the mark. And some of these are great, and I really like to see your handwritten process as well with the rest of the designs. So we will definitely post to that, and you can explore all those things because they’re great hands-on examples of UI/UX.

Marquez:

Yeah, I’m glad to hear you think so. I’m currently in the process of redesigning the site from the ground up. So, you know, what’s currently live is what’s live right now, but it’ll look different in a few months.

Jeffrey:

Hey, if you need help rebuilding it, I mean, that’s what we do.

Jacob:

It’s true, we could help with that. But I think that’s great. So, if anybody’s listening in a couple of months—which could happen—the website might look different today, but I’m sure it will be just as usable and presentable in all these topics.

Jeffrey:

So, Jacob, final thoughts?

Jacob:

Final thoughts for me… I thought this was a great, eye-opening conversation into this stuff because, as far as website design goes, I am definitely on the engineering and product management side of it more than the design side of it. So, I’m often at the receiving end of crazy graphic designs, then I have to tell people, “Nope, don’t do it that way; you just added 10 hours to the project.” And it was really nice to hear someone like you talk about it because you get a bigger view of it.

And so now I want to work with more UI/UX designers than I do with graphic designers for my website stuff moving forward. Not to say that my graphic design people that I work with aren’t amazing because they are…

Jeffrey:

So good. No complaints.

Jacob:

I do really appreciate the level of detail and thought that you and people like you go through. And I definitely want to put a couple of key takeaways—the triad, that was really nice. I hadn’t heard that before. And the three key things of feasibility, desirability, and… Oh, what was the last one? I’ve got to write this down. Usability, sorry.

Jeffrey:

Usability, feasibility, wait… now I’m missing the third one.

Jacob:

Desirability.

Jeffrey:

Desirability, usability, feasibility. Got it.

Jacob:

I mean, that’s a great set of tenets to go by when you’re designing or deciding on a new product. So that’s my takeaway. Jeff, is there anything you wanted to add?

Jeffrey:

No, only that I love talking to you, Quez. I mean, we’ve been friends for, like, so many years, and we have never had this deep of a conversation about what it is that you do for work. It’s like, I was always…

Marquez:

That’s true.

Jeffrey:

I’ve always been vaguely aware, but never in this much detail. So it’s been nice to explore that side of you.

Marquez:

I mean, you know, this felt really good, actually, because I feel like I’m never really able to… You know, imagine someone being at a party and someone asking me what I do for a living. There’s no time for me to actually give all of this detail, and I feel like I struggle sometimes with being able to distill that into an elevator pitch for someone at a party. Like, “Oh, I design apps, I design software.” Okay, well, what does that actually mean?

It doesn’t really compute for a lot of people. And, I don’t know, it’s like a very backstage kind of work, and people just don’t know that this exists. But yeah, I had a lot of fun going into a lot of detail with you.

Jeffrey:

It’s been great hearing it. I mean, yeah, like I said, I love hearing more about what it is that you do for work, because truly, we’ve been friends for like a decade, and I don’t know your job apparently, so it’s been good to know it.

Jacob:

No, it’s been great. And I think… Is there anything you want to leave the listeners with?

Jeffrey:

Yeah. Final thoughts, Quez?

Marquez:

Um, no final thoughts. You know, I love what I do for a living—all the ups and downs that come with it. Tech is turbulent, but also there’s a lot of great things about tech. There’s great things about being able to create something and then see something go from an idea in someone’s head to actually being this tangible thing that you can use and see and touch and experience, whether it’s on a phone or a computer or a process that you experience in real life.

And so, I think that’s what kind of keeps me in it. And I love it.

Jacob:

That’s great. That’s awesome. Well, thank you for being on.

Jeffrey:

Yeah. Thanks, Quez.

Marquez:

Thanks for having me.