Implement Service Design in Your Practice (feat. Eduardo Ortiz)

Eduardo Ortiz chats about service design and how it can be implemented in an organization.

Sponsored by Watch City Research
Watch City Research is your trusted UX research partner

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Copy Transcript Copied

Dan Berlin: 0:14

Hi everyone, welcome to another edition of the 97 UX Things podcast, Dan Berlin here, your host and book editor. I'm joined this week by Eduardo Ortiz, who wrote the chapter Implement Service Design in Your Practice. Welcome, Eduardo.

Eduardo Ortiz: 0:28

Thanks, Dan, how are you?

Dan Berlin: 0:29

Alright, thanks for joining me today. And can you take a moment to introduce yourself?

Eduardo Ortiz: 0:34

Absolutely. My name is Eduardo Ortiz, I have been in this space for close to 19 years. I, most recently and currently, run a design organization called Coforma. Before this, I spent quite a bit of time working in the public sector, as well as in corporate organizations, primarily in advertising.

Dan Berlin: 1:03

And where do you focus your work? Your daily work? Are you on the design side, the research side, somewhere in between?

Eduardo Ortiz: 1:10

I am mostly in the product and operations side of things. I do quite a bit of research, but it's often at the very beginning of engagements, before a team gets assigned to a scope of work, or to a project rather.

Dan Berlin: 1:28

And can you tell us about your UX career trajectory? How did you discover UX? And how did you end up where you are today?

Eduardo Ortiz: 1:36

I used to say that my career was unique and then I continued to meet people. And it's like, nope, my career is very, very common. So I started out by going to school for software engineering and very promptly figured out that I actually loved the idea of always being in a computer, I hated the idea of writing code. And after I left college, I needed to figure out how can I do something that I want to do, which is be on a computer, but actually not do what I went to school for, and I hate, which was writing code. And it took me a while, but I started to learn about design. And as I started then learning about different technologies learned about HTML and the front end, and delivering in the browser, I started billing myself as a front end engineer. Whereas I had zero experience doing anything in the browser. But as an engineer, it was an easy lift. And then I figured that I still hate it. And by luck, and happenstance, I stumbled upon the IAS mailing list; actually the ASIS&T mailing list, as well as the polar bear book, which was being mentioned all over the place, bought it on Amazon, read through it, didn't understand anything that was in it. But it was following the conversations that were going on in the mailing list and saw that there was this one guy, Lou Rosenfeld, that had written the polar bear book. So he made a post that he was coming to New York, and this was doing a taxi strike. So he wants to know if someone could give him give him a lift. I think at the time I pick him, his wife and his daughter up from the airport. So I emailed him, he ended up not needing it. But since then, we started a friendship and I actually started learning what IA, information architecture, was and then started pivoting into other areas over the years. At some point, I wanted to apply both my engineering capabilities and nascent information architecture skills, then ran into interaction design, because I could make things and see how things actually move then people were able to interact with them. And it's just been a number of stumbling blocks, stumbling blocks from there into UX, as a UX designer, then architecting things and then moving into product and product design and product management, which is where I found myself for the last few years.

Dan Berlin: 4:46

Tell me a little bit about... So you mentioned 19 years, so you've been doing this for quite some time and you were there in the very early days of information architecture and thinking about that. Tell me a little bit about being an information architect in those earlier days, if you wouldn't mind, because as we talked about with Joe, in the previous episode, this is a career we don't talk about very much these days, and we should be.

Eduardo Ortiz: 5:11

Yeah, I mean, the crazy thing is that I had no clue what I had stumbled upon. I had absolutely no idea that this was a professional field that originated with library sciences. I just felt attracted to it. Because here were a number of people who were passionate enough to actually be having this full blown out email exchanges, about taxonomy, and how to organize content and how to present information. And that was absolutely mind blowing. Over the years, I started attending conferences. And all of a sudden, I was like, I know that person. I didn't. But I had seen so many emails and interacted with them. And that just kept happening and happening and happening. And I consider myself lucky that I stumbled upon ASIS&T and their mailing list and the amazing people that have been pioneers in the field of information architecture, and that have laid the groundwork for creating the digital solutions that we apply and the tools that we use as UX designers in order to solve problems. I honestly don't think that I would be as proficient as I am, if I did not understand information architecture, and I would not understand information architecture if I had not stumbled upon them in the list.

Dan Berlin: 6:49

Yep. And information architecture really gives us that foundation, that baseline for design, and that seems to be the theme there with that.

Eduardo Ortiz: 6:58

100%.

Dan Berlin: 7:00

Thank you for all of that. Moving on to your chapter Implement Service Design in Your Practice. Can you tell us about that please?

Eduardo Ortiz: 7:09

Yeah, absolutely Dan. First of all, what I wanted to do was to remove the jargon from our field as much as possible when speaking to service design. So service design is defined as the activity of considering all of the components that go into delivering something to someone so that someone can do something. It is vague intentionally in the way that I define it because the truth is that service design is about taking the time to understand the environment in which something happens, and who plays a part in it, and who is affected by it, and all of the different touch points. And what I wanted to achieve in the chapter for implementing service design into your practice, was almost like a call to action to anyone and everyone that is in our field, as a UX designer, UX architect, experience architect, interaction designer, product designer, whatever they want to call themselves, that our work, shouldn't start in the browser. Our work shouldn't start in the device that we are creating for. Our work starts before that. And by the same token that our work doesn't end at the browser or the device. Our work goes beyond that. Engaging with every single aspect of the organization, whichever organization that may be, their customers, the business, the suppliers, in order to truly understand what are the challenges that people are facing at every single touch point is crucial for us to design good services. Because like Lou Downe wrote in their book Good Services, in how to design services that work. Services happen, whether you want to or not, it is up to us whether they are good or not. And I think that is something that is really important, especially when in the space that I find myself and in the public interest technology or civic tech, which is when we are trying to provide for someone, the infrastructure will happen, whether it is created and thought of or not.

Dan Berlin: 9:31

Tell me about that, how does the infrastructure get created, if we don't think about it beforehand?

Eduardo Ortiz: 9:36

Absolutely. So the best way to say it is by illustrating it with an example. When a law is passed by Congress and say that law is about requiring federal agencies to take specific action. The different federal agencies will go to the law, because they have a mandate, and they will try to parse it in a way that they can start implementing it. Most often it is they need to develop a report or they integrate a system to do X, Y, or Zed or they need to change their practices. But there's never a holistic view from how did this law get stood up, get written by Congress? What are the demands? Who are all... who is everyone that is involved? Because oftentimes, there's not just one organization that is affected by a law enacted by Congress, right? So you end up with a disparate network, that is often propped up by niche organizations that see this space, that see that there's something missing there, and they're like, oh, we'll do that. And you end up with this result, which is, the federal government may end up saying, in order to complete or to file or to achieve this function that Congress has mandated, you need to do this thing. And that thing may be incredibly complex, right. But here comes an organization that stands itself up who says, "You give us your information? We'll complete the process for you." And that happens time and time and time again, you see that in the healthcare space, you see that in applying for healthcare, with veterans, you see in applying for benefits by immigrants. It happens all the time because the idea of thinking about service design at that level? It's almost impossible. Right. Like it would require a team off teams, that would be massive. So instead, you end up with the other part, which is, well, someone else will do it.

Dan Berlin: 12:00

Right. And it sounds like with the complexity that these mandates come with, and for the potential for wide sweeping change, at least in the given area, there must be so many different touch points in so many different areas that you have to think of, to effectively do that. How do you inventory that? And how do you grok that?

Eduardo Ortiz: 12:26

Yeah, that. So you're completely right. It is massive, sometimes it's impossible to wrap your head around. But it is one of the best ways because of how the outputs are illustrated in how they are cataloged. It is probably one of the best ways to show businesses that may be reluctant or partners that may be reluctant to assign enough space or or funding for research to happen. Why research is important, why research is critical. Because one of the most impressive outputs of the service design space of the research portion of it are the service blueprint where you visually represent what are all of the different touch points, who are all of the different participants in that service, and what are all of the different interactions that happen across the participants, the touch points and the entities that are involved. In there, you see everything from someone interacting with something because of a policy, someone interacting with a device or a system or a tool because of a guidance, or because they have been directed by someone to do so. And when you're able to see that at a glance, then you're able to also see where things fall off where you haven't actually accounted for. In a lot of the research that we've done, we often see that we asked someone like,"Well, how do you do this thing?" And they will push back on their chair, they will open a drawer under a desk and pull out this binder that they have created for how to achieve specific functions in a system. And when we ask them, "Why do you do that?" They're like,"Well, this is not part of the training. This is in part of the system. But having done this enough time, I've learned that this is what I need to do." And we see that and being able to map it and to present it, to visually understand it. Because it's no longer... when you create that, it's no longer something that designers or researchers understand. Now anyone and everyone can see it. Right? And I find that to be really valuable. But back to your question. That is how most often information is presented in this space.

Dan Berlin: 15:03

It's interesting to hear you talk about the binder, right? Often in UX research and design, we talk about doing ethnography in the field, because we want to see a person's natural environment. And the big example we always talk about is what stickies do they have on their monitor. Right? But what you just said, is taking that to the next level, many levels later. All right, they've been doing this for so long, they have so many stickies that they have this binder now. And that's not an ideal service design, right?

Eduardo Ortiz: 15:31

It's not at all, I mean, it's not even an ideal software design. Because oftentimes, where we see this is in the software space where people have to do this in order to be able to achieve their jobs, because their actions are repetitive, but the system doesn't allow for it.

Dan Berlin: 15:52

So turning back to your chapter, Implementing Service Design into Your Into Practice, that was a great, wonderful overview of service design in the world, but how about getting it into the practice? Can you tell us about that, please?

Eduardo Ortiz: 16:04

Yeah, so what I wanted to do, and what I set out to do, as I said just a few minutes ago, was to try to remove the jargon from the space in order to encourage and to enable anyone and everyone to be able to use service design to implement that as part of their practice. The first thing to implement service design is you need to give a shit. If you if you don't care, then nothing else matters. Once you care enough, then you're going to be able to actually implement things because you're going to see that there's a lot of work involved. And I break things down into three primary phases. The first one, which is research, it's about understanding the environment. It's about trying to find what are all of the different touch points? Who is affected by this? What are the different mechanisms that lead to this thing to exist? How does this thing exist? So it's infrastructure of policies, people. The next phase is about planning. It's about taking what you have found, cataloging it in ways that make sense, identifying where information may not exist, where information may exist, that differs from what people expected, aka pain points, and organizing it in a way that people are able to refer to it. And then the final phase is about taking that information that you have gathered, and presenting it in a way that people can visually understand what the service is. So you basically develop a roadmap, that is when someone is attempting to do X, this is everything that happens to them. At the same time for X to exist, this is everything that the business or the organization has to do. And this is how those things merge with one another or meet one another. And these are the different points in which we can engage with them in order to be able to improve the experience or to address issues that are the pain points that were identified during the research phase and noted noted during the planning phase. And so the idea behind it is that if you give a shit and you are able to ask the proper questions and document them in a way that you can then visualize them, now you have something that you can point to and be like, that's something that needs fixing. That is something that needs fixing. Because service design is not the job of one person is the job of everyone.

Dan Berlin: 18:57

Right. Super interesting. And I've never heard service design described that way. And it made me realize how it's so much like information architecture, and information architecture, you know, we're concentrating on the information, on the ideas and the things going on in an interface. But what you've just described is cataloging and organizing all of these other things. It's not just information, it's the services. It's everything going on. So that's, that's fascinating.

Eduardo Ortiz: 19:24

Yeah, the libraries that you see in service design, are as fast as the time that you have for performing the research. Because everywhere that you look, a service exists.

Dan Berlin: 19:37

Yeah. How about documenting ongoing learning? So the work is never done, right? And I'm sure organizations are constantly learning about their services when they do pay attention when they do give a shit. How do we deal with ongoing learning?

Eduardo Ortiz: 19:55

Not easily. You need to an organization needs to reach a level of maturity to understand that just because they launch something, doesn't mean that they are done. Too often organizations are like,"Oh, we launched this thing, now we go to new features," and forget that what about the features that we just launched, shouldn't we also iterate and improve them, and try to figure out how people interact with them, or what challenges people are facing. And it's much more manageable when you start and you end in a device or in the browser. But the reality is that most often you're transacting with things that go beyond the browser, things that go beyond the device. When you are applying to have electricity in your house, you may be doing it from your phone from a device, you may be doing it from the browser, you may be doing it over the phone, but that has a physical component to it. When you are applying to get water turned on or turned off, it's the same thing. And that correlation doesn't always match to other organizations, when they're like, "Oh, we have a we have an app that you can share photos," like, okay.

Dan Berlin: 21:30

Right. The work is never done. That seems to be a theme of this podcast. Honestly, it comes up so often is that no matter if you're in research, or design, or service designer, an IA, the work has never done.

Eduardo Ortiz: 21:42

That is so true.

Dan Berlin: 21:43

Yeah. So what else about your chapter? Was there anything else here about your chapter you're hoping to convey here?

Eduardo Ortiz: 21:49

Um, honestly, like, if I could convey one last thing I said, this is just as hard as the work that everyone else is doing. It is not unique, it is not special. The only thing that you need to have is heart, the only thing that you need to do is give a shit in order to be able to do service design.

Dan Berlin: 22:08

Yep. That's wonderful to hear and totally agree. I mean, we have to pay attention, you have to give a shit and pay attention. I agree. And it touches all of us all the time. And anytime we're doing design, we have to be thinking about service design, because anything that gets designed, will touch other things, just as you said. Great example, just in terms of everyday interaction, I recently took my car to the shop, and I got a text from the technician saying your car is all set. Or here's what the cost is going to be and here's what we found. And I got in touch with my service manager. And he's like, "What text?" So my service manager had no idea that this thing that the techs were using got implemented. And there's a failure of service design in everyday life.

Eduardo Ortiz: 22:56

Right. And by the same token, it's like services happen. Whether you plan to or not, you probably assume that the technician has no clue that you receive that message. Yeah, that is that they're just on their computer. And they're like saying, these are the three things and the car is done. They click on Save, they move on to another ticket but they probably have no idea that then the system sends a message to the customer of their car saying hey, this is the information that is in the system.

Dan Berlin: 23:26

Exactly.

Eduardo Ortiz: 23:27

Which, don't get me wrong, it's a smart touch point, but clearly not one that has been integrated into the process itself.

Dan Berlin: 23:35

Yep. Yep. It serves a customer need, but you have to inform the people doing it.

Eduardo Ortiz: 23:40

Exactly.

Dan Berlin: 23:41

Yeah. Yeah. Awesome. Great. So this has been wonderful about service design. Thank you for all of that. How about a tip for our listeners? Do you have a tip for people either breaking into UX or who have been here for a while in terms of their career?

Eduardo Ortiz: 23:59

Yeah, I mean, I will say what I just said a few minutes ago. That is the work of service design, it's not special, it's not unique. All you need to do is care enough in order to be able to do it. So whether you are brand new to this space, you just need to care enough to not be discouraged. Whether you have been in the field forever. All you have to do is care enough to not be discouraged. The work is hard, but so is doing anything else. And the only thing that is harder is doing nothing at all.

Dan Berlin: 24:34

Work is hard but fulfilling.

Eduardo Ortiz: 24:35

Agreed.

Dan Berlin: 24:36

How do we get people to care? How do we get other people to care? Are there ways?

Eduardo Ortiz: 24:42

I don't know.

Dan Berlin: 24:43

Okay.

Eduardo Ortiz: 24:44

I often say that I can teach anyone anything. What I cannot teach someone to give a shit.

Dan Berlin: 24:53

Fair enough. Maybe just through advocacy and just saying this over and over again and showing people over and over again. Hopefully it'll just click one day, as we do in UX, right?

Eduardo Ortiz: 25:04

Yeah, I mean, all we can just create this basis and create the systems in order for people to join us. But beyond that, it's I honestly don't know how to get someone to care beyond what they do. Yeah.

Dan Berlin: 25:20

As long as we always keep trying. That's the fun of UX.

Eduardo Ortiz: 25:23

Yeah. Absolutely.

Dan Berlin: 25:26

So Eduardo, this has been a wonderful conversation. Thank you so much for joining me today. My guest today has been Eduardo Ortiz, who wrote the chapter Implement Service Design into Your Practice. Thanks for joining me today, Eduardo.

Eduardo Ortiz: 25:38

Thank you so much for having me, Dan, and thanks to everyone for listening.

Dan Berlin: 25:42

You've been listening to the 97 UX Things podcast, Eduardo Ortiz has been my guest today who wrote the Implement Service Design into Your Practice chapter. Thanks for listening everyone. You've been listening to the 97 UX things podcast, a companion to the book 97 Things Every UX Practitioner Should Know published by O'Reilly and available at your local bookshop. All book royalties go to UX nonprofits, as well any funds raised by this podcast. The theme music is Moisturize the Situation by Consider the Source, Joshua Berlin is the podcast transcript editor, and I'm your host and book editor Dan Berlin. Please remember to find the needs in your community and fill them with your best work. Thanks for listening.