Design, with Salomé Mortazavi

Episode 96 · 54:58 · SRT · archive.org · all Tanzu Talk

Well, it's time for our favorite topic. How's the weather up there? But this is a special edition since both of you live in Seattle. I think I have moved somewhere that finally has similar weather. I thought I had lost my Dutch ID card. So I was out and about and I got to wear, you might be familiar with this, what's called a rain jacket while I was out today. It's a very novel sort of thing. It's very thin and it's this fancy one that has sort of like zippers on the armpits so you can cool off, which is a very fascinating idea that you would wear a jacket and need to cool off. But, you know, how many rain jackets do you think I'm going to need over two years? Am I just going to tear through these things or are they more permanent? To come to Seattle? Or just in a rainy environment in general. Say you live in a rainy city. Unless you're trying to match with your shoes or your bag. That's a good idea. That's a good idea. I hadn't thought of that. Now, do people do that in Seattle? Do they have matching rain jacket and shoes? I feel like people in Seattle have just given into the rain. They just understand they're going to be wet and clothes are not going to match. It's very different. Yeah, it's purely functional. When you travel away from Seattle, do you like inadvertently bring a rain jacket every time? Just because like you pack for the weather at home instead of outside of abroad, you know, abroad from Seattle? Or are you disciplined enough not to pack that? I never pack a rain jacket just because I'm just not very prepared at home either. I often get caught in the rain. Yeah, I don't think I do either. Maybe I'll bring an umbrella. But even then, like those are from Seattle. Like I really feel like a tourist every time I use an umbrella in this city because no one else wears one. Oh yeah, we've talked about that before where there's sort of like a little bit of like Seattle localness and you can't have an umbrella. So that negates my last follow-up question on everyone's favorite introductory topic, which is, you know, you've got these like golf umbrellas. And then you've got sort of like the, they're almost like the police baton of umbrellas.

I don't know how long that is, maybe a little over a foot, but then there's like these compact umbrellas that are kind of like those compact bags they have. And like, do you all carry around a compact one? I mean, is that, or just no umbrella? I don't carry an umbrella. I learned my lesson the first week that I moved here from the East Coast. I had my nice umbrella with my raincoat and everyone was staring at me and I realized, oh, this is how you stand out in Seattle as a tourist or someone who's just visiting. Yeah. So I have to use the compact one. It's in a pocket. So I don't feel too ashamed if I'm walking around with it. But then if it's actually pouring, then I do still have some coverage. Yeah. Now, do you think over here in Amsterdam, if I got one of those umbrella hats, I would fit in or would they think I was a tourist or just would they be confused? Both. I don't know what those are. I'll have to let, I feel like, hopefully I'm not making this up from some dream, but I feel like there's these hats that are like umbrellas that kind of cover your head. I think you're thinking of a sombrero. Or an urban sombrero. The urban sombrero. That's right. I feel a startup coming on. That's right. Well, why don't you introduce yourself, guest, now that you've given your bona fides about surviving in the rain and fitting in. Who are you? What do you do around here? I am Salome Mordazavi. I'm a product design manager in the Seattle office. And I've been in the Seattle office for four years via Toronto. And yes, I work with a team of designers and product managers and engineers to build products. So you must have, did you, are you, are you Canadian? I am a hundred percent Canadian. Yes. What was that like getting like a work visa in the U S was that thrilling? I assume you've got one not to, you know, we can edit this out.

Um, yes. I mean, I was warned about the intricacies of getting a visa, but much to my surprise, it was really easy process. Um, that's a very nice border person. I, we had a legal team who helped us out. So that process was unusually smooth for me. Yeah. Yeah. It's been, I, I, I have this experience myself. I'm still slightly going through it, but yeah, it is nice to have people helping you out. It's, it's like, uh, lawyers be awesome when they're doing exactly. Well, we have a, a few little news things to go over and then, uh, and then we're going to talk about, uh, product design and other exciting things like that. A topic that I think we talk about every now and then, uh, moon or whatever, but, uh, not enough. So why don't you, uh, what, what did you, what did you find for us this week? News wise, Richard? Yeah, there were a handful of things. First off, I noticed that at the end of last week, the folks, Google, the Google cloud team shipped a spring cloud module or library specifically for all their Google cloud stuff. So if you're at using GCP, you're putting your apps up there using Google pub sub or Google cloud storage, my SQL, all that. Now you have a nice way for your spring boot apps to actually talk to those. And Microsoft has one of those as well. You see these sort of libraries trying to make it easier to use these first party cloud services. And this has been under development for a few months, but really neat to see that finally ship. And, and so how does that, uh, I mean, is that just spring cloud that's wired into GCP or, or what is it exactly? Yeah. It really just means that from your code, you know, with some basic annotations and properties, it's really easy to consume those respective Google cloud services. So you don't have to do much. It really just says, look, look, my app wants to use Google cloud SQL for its SQL database. Cool. Here's some basic annotations. I don't have to have any too much funky stuff in my code. Not too much funky stuff. That's good. And, and then, uh, well, there, I only had one item this week and then, and then I'll hand it back to you. But I noticed, uh, I don't know if it was this week, but over at red monk, uh, our friend James governor is doing, trying to do some hardcore thought lording and he has deemed, what

would we normally, I mean, I guess the fact that he's created a phrase for this, I think he created it. I went to go search, I Googled for it. And the only thing came up was like how to do term papers or something. Uh, anyways, he has this phrase progressive delivery, which I guess, I guess we, we would use the phrase, uh, rolling upgrade or rolling release where you, uh, the, the example of this, I always used, they went over it themselves was how, uh, when Garmin releases some software, uh, they release it to like the, uh, the Kansas city area, their Kansas city data center, and then kind of like their West, uh, us data center and their East data center. And then, you know, eventually they get to China and Europe and Latin America and other places. But it's this idea of, uh, you know, you might also call it a canary release, depending on if it's for a bug checking or to see if your software was, uh, I don't know, done well in a way that was helpful, but, uh, he, he's been wrapped, he'd wrapped the term progressive delivery around it. And then some people from, uh, launched darkly, uh, which that's a nice name. Uh, they sort of, uh, be more technical followup to it, but so there, we'll put that on the board. There's progressive delivery become a, uh, uh, an official, uh, thought Lord and lady, uh, phrase a thing. Yeah. I mean, your next, I'll, I'll endorse you on LinkedIn for progressive delivery. Oh, that's a good idea. Yeah. It'd be good. You can put that right next to a kettle popcorn making. The other thing I thought that was interesting on this, cause I bumped into James at the Google cloud conference a couple of weeks ago, talked about this was that specifically, yeah, there's different techniques for this, but it's not even just for performance things. It's not like just let's deploy a first and see if it works before we roll it elsewhere. It's also about feature flags. It's also about, Hey, let's tap some traffic, go here and see if these users convert at a higher rate than these users. So being better about not just constantly shipping all the software to all the places and turning everything on, but in some cases, purposely being smart about how you're pulling things out and delivering probably will even touch upon our product design conversation today,

which is how do you potentially experiment with design in a continuous delivery sort of culture? So I don't know. It's a cool thing up. We'll see if people talk about it more. And then, uh, what, what are the other, the other two items you found, Richard? What else did we have here? So I threw in something around, uh, what Confluent shipped last week. This is the company that has the kind of the creators of Kafka on staff, and they've done some, some cool work here. And we worked with them to actually ship some things to easier to use Kafka on Kubernetes. So specifically Helm is a package manager for Kubernetes. We worked with them building, testing these sort of Helm chart, actually deploy these Confluent platform or Kafka components to that. And then they also shipped a nice white paper. So it just neat to see some of these platform, more complex workloads, the more supportable way to things like Kubernetes, not just virtual machine environments or public cloud. So pretty neat stuff. You can try it today. It all works great. Well, the same thing actually this morning, just a few minutes before the podcast with a Yuga Byte, great database as well, that now runs on PKS as well with some really simple installation. So, you know, neat messaging platforms, databases, we're getting better, I think, at figuring how to deploy these in container environments. The last thing I found was there was one more, I guess, the second project that the Cloud Native Computing Foundation actually promoted all the way up to a graduated project. That was Prometheus, kind of a monitoring infrastructure tool for apps and infrastructure and pretty neat stuff. I know Pivotal is playing around with this for some services as well, but people seem to like it. Yet another thing. There's a lot of things incubating with the Cloud Native Computing Foundation. We talked about Harbor in our last podcast, but good to see graduating through the program, not getting stuck. It's kind of never ending limbo in the foundation there. Yeah. I think unless I'm misremembering, there used to be, this is a little while ago now. I think there's a Pivotal Conversations episode where I talked with Diego when he worked here about Prometheus, but maybe that didn't happen.

I'll have to find out. We'll pretend it did. Yeah. That's right. It was a good conversation. It was probably game changing. Yeah. That's right. Well, yeah. You know, it's like over here. It's August. Slow news time. It's great. You can sit back and relax and enjoy getting lost in the rain. Mm-hmm. Yeah. Well, so how did you, guest, how did you find yourself doing design? Well, I was just curious to find out first, how many designers have you had on this podcast before we dive into everything? Well, as you can tell, I have an excellent memory for every episode. How many do you think, Richard? Has it just been maybe, I don't know, how many? Zero to one? I think it's in that range. Oh, we need to change that. Yeah. Well, that's, you know, you're the blazer here. All right. How did I get started in design? I guess I started in design as a child. I was very curious about art and basically the role it plays in our world. I spent many hours drawing and painting. And then I got really interested in human interactions. What makes us tick? What makes us motivated? What makes us excited? And then that basically led me to get into graphic design, visual design, interaction design. And throughout the years, I started getting really curious about technology and the role it plays in our lives. And then I just made my way into product design, which has been really, really interesting because you get to see all of the life cycles of the design process and work with humans and technology and try to bridge that gap. So, like in the software world, how do you distinguish between design and developers like to fancify up what they do? Engineering. Like, what are the differences?

Not so much like a task base, like what people are doing tactically, but like what the point of it is or kind of the philosophy of it, so to speak. How are those perspectives different? How are those perspectives different? Yeah, sure. As designers, we think about the why and understanding the human experience, empathizing and observing and being curious and trying to understand what are those important touch points between a person and technology. And this is in something called computational design, this is a term that John Maida coined, and it's very different than traditional design. And so, in computational design, you have to think about the impact that the product or service is having on the audience and your users. And so, as designers, we're continuously trying to advocate for the user need and bringing that back to our team and helping the developers understand the why. And so, working with developers, they think about it in terms of how to build that thing that we are telling them that they need to build. And so, what we do at Pivotal is try to bridge that gap and bring that understanding to the whole team, including the development team, to really think about the end user and the customer that we're building for. And really inject the why into the code and to make sure that we're thinking about features in terms of outcomes instead of just features to be built. Salome, you and I talked about a couple weeks ago when we were talking about this podcast is that sometimes that can feel like that's a nice to have. If I'm an enterprise dev who might think like, I don't really, I mean, people have to use whatever I ship, especially if it's an internal app. So, what do I care to some extent if they really think this has a great design aspect or if it's just functional enough? Do you consider this an optional role? Or when you look at a product, you know, you look at a balanced team, you look at whether it's internal enterprise software or something that's external customer facing. Do you see that this is something you can kind of treat as optional?

And do you really think this is mandatory? This is a great question because I continuously get questions like this from stakeholders of especially large enterprise companies who come to us, not understanding the value of design, not understanding the choice that the internal employees, which are essentially their users have. And so, one of the things to consider is, you know, as you're trying to improve performance of your employees and help them make sure that they are engaged and enjoying their job and being able to perform at their optimal rate. Reducing that cognitive load as you're interacting with a product or service is very essential. And so, if you think about you having a traditional top-down hierarchy and being able to tell your employees what to do, I mean, if you think about compliance rates, what is the last time that you saw 100% compliance rate where employees do exactly as they're told? So, choice is always there. It's always present. And you see it when you watch and observe employees come up with very, you know, extensive workarounds that are timely and, like, time-consuming and expensive to the business. And also, really make them feel unsatisfied as they're performing their job and tasks. So, when you really think about that is, you want to make sure that you are creating an environment where your employees are there to, you know, perform optimally, not just the status quo, not struggling with software. And so, if you can remove those barriers, the more of those barriers you can remove through improving that user experience and thinking about their needs, the better performance you're going to get out of them. And then, beyond that, you're going to, you know, open up this room for innovation where they are freed up to think about things that are more important than just, you know, trying to get around this badly designed software. Right. To the enterprise-y people, do they buy all that?

Or, like, how do they respond to it? Yeah. I mean, they respond to it. They respond to it when you talk about the ROI of investing in design. And, you know, when you think about, there's a lot of amazing material out there that can speak to, you know, the companies that are investing in design. For example, I follow the design and tech report and the McKinsey report. And one of the things that really stood out to me this year, and I started trying to use those numbers to be able to build a design case, and the value of design was companies that invest in design, are design-centric, outperform the rest of the market by 200%. And so, this is a really interesting number that comes from the DMI, Motive Strategies, that's funded by Microsoft. And so, when you share these numbers, and you talk about, you know, when we explore and examine companies that are committed to design as a part of their business strategy, and track these, what they found in the DMI was that the companies that invested in the past 10 years in design and making design a central and integral part of their organization, they outperformed the rest of the S&P by 200%. And so, that's a really compelling number. And so, when you're thinking about, in terms of design, you have to make sure that you are speaking about the ROI, and speaking the business language, and getting out of the design mindset, and the design conversations and chats that you're used to as a designer, and think about the why, and think about always tying it back to the outcomes, and then think about if there's a way to quantify the value of the thing that you're designing. And that really helps drive the conversation towards the business side, which really, you know, that's what we're here to do. You know, products are here to solve a business problem.

Good design is here to solve a business problem, and a user problem. And so, when you tie those two worlds and bridge that gap, then it's a more compelling story, and the business starts to care about it more. So, it sounds like you discussed, like, you've got to focus on the outcomes of the outcomes to convince the sort of stakeholders. Yes. Having better done software will result in a better run business, essentially. Yes. I mean, one thing that we continuously get faced with is a client will come to us with a set of features, and what we think about is, hey, like, it's great that you think you know how to solve this problem, that these features are going to do it for you, but we're going to think about these in terms of the goals and the outcomes that you're trying to achieve by these features. And so, what that really allows us to do as designers and as a, you know, cross-balanced functional team is really help us to understand, you know, why are we building this thing and use many different ways to achieve that same thing. So, I like to give an example to new teams when they come in. You know, if you ask your team to build you a ladder, they're going to come up with many ways to build you a ladder. They'll build you a wood ladder, a metal ladder, a purple ladder, but at the end of the day, it's going to be a ladder. But if you challenge your team to find a way to reach the top shelf, they're going to really be able to use their expertise, think outside the box, and come up with many different ways to solve that problem that is actually more valuable and better in the context that we're trying to solve the problem for. And so, that's what the power of thinking in terms of outcomes is. It allows the team to really use their expertise to be autonomous and go out there and try to figure out how to solve that problem best. And so, I think it's a lot of having that conversation over and over again and then trying to tie it back to the business value.

Yeah, I love that. Focus on the outcomes. I mean, I think some people can see this work as maybe about making things look nice or kind of the aesthetic versus the actual utility and the value. Give me some examples of what you've seen. And don't name names. We don't want to shame anybody. But what does bad design look like? When you see that either in not even just, I don't know, how an app works, also maybe the approach that went into it. Like, what is a bad design that you've seen? Or a couple examples. I guess one of the things that I try to think about when I think about design is, you know, breaking that association of just the visual alone, especially in product design. Often one of the biggest pains that we are faced with is like, oh, this application doesn't have a user interface. So, therefore, we don't need designers. But when you really think about all of the different touch points and the whole experience of the application, there is a human being consuming that at the end. And so, I guess I would think about bad design as something that doesn't allow the user to safely and effectively and comfortably be able to get the job that they're there to do done. And so, if you are making your users frustrated and if you are not allowing them to get from point A to point B in a timely fashion or you just get them lost in a way that they abandon that application or product, then that is bad design. And so, something, you know, I would like to separate the visual aspect, like the moments of delight, which are really great, you know, nice to have. But you can have good design that's really simple and not visually blowing your mind, be a good design. So, I think just the experience and being able to get your job done and being able to perform that task in an efficient way that you feel comfortable, you feel like you belong using that system is an important part of good design.

Yeah, that makes sense. What do you, what's in your toolbox? So, when you're trying to do good design, what do you bring to the table besides, obviously, your skill and your background? But are there technologies you bring? Are there, you know, a workshop approach you like to bring? What are the sort of things that people bank on when they bring you into a project? I guess one of the areas that beyond the, you know, the typical tools we use, sketch, we use a lot of Envision products, which help us to be able to prototype quickly and easily. And then also other tools like Studio that's coming out, that's, you know, starting to replace sketch. Some of those tools are, you know, all designers know really well and use often. But beyond that is more bringing those conversations, basically helping the roles understand how to frame a problem from a user-centered way. So, from how can I take this problem and define it, understand it, and frame it in a way that is seen through a human lens. And I feel like that is a practice that design really is a steward of. And anyone who is building a product, whether they're a designer or not, they are in charge of understanding that human experience. And so, anyone building a product should be able to do that. And so, designers come in and are able to facilitate those conversations, teach those workshops, to be able to raise the design fluency of a team. So, a developer, when they're building a product, they can really think about, why am I building this product? What does this feature do? And to have those informed conversations and to be able to think holistically about the overall thing, outside of just those, you know, stories that they're working on right then and then. And so, that's part of the value of design. The other part of it is, like, you know, thinking about organizing people and infrastructure, like, the communication components of a service to be able to improve the quality of interactions between, like, the services and the systems and the customers.

Those are the intangibles, the invisible things that we don't see that designers do. That's outside of just traditional, you know, user experience and the user interface. And so, I think those are some of the things that design brings to the table. Yeah, you touched on real quick there, the idea of a workshop. So, you know, do you get in there at the project initiation? You know, when we instante some of the work, what does a workshop look like from a design perspective? Is it you with a bunch of sticky notes on a whiteboard? How does that play out? Yeah, there's a lot of sticky notes. I believe we keep the posted industry in business single-handedly. Yeah, I mean, what we do at the beginning of a project, we have a meeting where we basically try to understand the needs of the client, understand their goals, understand their users and the why they're building that product, and then basically highlight our assumptions. And then from that, you know, the role of the designer is, I guess, I say workshops, but it's continuously happening. We're always in front of the whiteboard. We're always talking, collaborating as a team. We work in what we call, I'm sure you're familiar with this, but for people who haven't heard this, cross-functional balance teams. And so we spend a lot of time chatting about, you know, our assumptions, understanding ways to de-risk them. And by, you know, doing that, we're making sure that we're building the right thing. And so that looks like a lot of conversations with each other, a lot of conversations with subject matter experts, with our users. And that happens in forms of different types of workshops or activities that we do. And they're not necessarily prescriptive because we try to understand this is not a linear process. We think about all of our design tools and activities that we do, like the workshops, as basically tools in our toolbox that we reach for, depending on the context.

You know, so it may look like, you know, doing a customer journey one day to be able to understand the overall end-to-end experience of a service. And then that might extend to a service blueprint to try to understand the systems and the other people that interact and support that customer journey. And then that helps us to identify different areas of pain and opportunity. It may look like a prioritization exercise where a team can't narrow down a problem that is worth solving. And so they have too many things and they want to boil the ocean. And so we're able to help them and facilitate that conversation to be able to get them to, you know, narrow down the possibilities and think about, you know, what is important today. So it's a lot of those things that we do as a team, work really closely with our PMs, which at times the role of PM in design in those early stages is a little bit blurry. But that's what I would say the workshops look like. It's just continuous conversation around trying to understand how to, what is the problem A, and then how to solve that problem. Yeah, that reminds me of one of my, you know, somewhere in the middle of my stack of things I'll never actually do, work mind palace organization things, is, you know, as you're just going over, like in the, in the labs part of Pivotal, like sort of metaphorically and literal, for lack of a better phrase, there's a lot of thought technologies that are, as you say, like conversational tools. So there's, you know, the software you would install and tools that you would use and all that kind of stuff. But, but then as far as I can tell, there's also a lot of like, here's how we do this quadrant thing that to prioritize stuff. And here's how we, here's how we have a conversation to suss this, this thing out. And they seem pretty, I don't know, tell me if I'm wrong, but they seem, what's the positive version of rigid?

They seem well-defined of how you do them. And then it would be, it'd be fun to like have a, I don't know, a book or a booklet that was like all of the, all of the thought technologies for doing things instead of just like, you know, here's how to use a build pack. That stuff's fun and everything, but there's, there's a whole, this whole other packet of stuff that, that Pivotal does that is, I don't know, in some PDFs there, but not sort of cool. Maybe you say that, but myself and some designers actually across Pivotal Cloud Foundry, one of the designers and Martina Schell, we're working on a Pivotal field guide playbook right now. And so that's at the beginning stages, we have an outline and we're basically talking about, you know, the principles and the methods and some case studies that we find would be valuable for the community. And this is basically trying to understand the value of design in the transformation story. And so I think that's something that we know intimately well working as designers within Pivotal because we have a very robust design community. We have a very active Slack channel, we have design round tables. And so one of the things that's not really apparent to the community outside is the design, the wealth of design within Pivotal. And so that's one of the passions that I have is try to bring that to the forefront, you know, to help the community understand just, you know, how rich, you know, the resources that we have at Pivotal and the processes and the methodologies are. Yeah, that would be exciting. That would be fun to see. Yeah, it's a project that I'm working on. And so a lot of folks are involved and being really supportive. And, you know, it started with a conversation with an email out to Rob me talking about, hey, I think this is really important.

This is the value of design. Can we have a conversation about this? And this turned into him being super supportive and engaging the leadership team who are now actively supporting this initiative. And so it's been really great to work with Martina and other designers across the globe. And, you know, bringing that global gap even closer, we feel like, you know, it looks like conversations in London and Berlin and other parts of the world and really bringing that knowledge of design and distilling it in a shareable fashion. What are the ways, I mean, you mentioned your Slack channel programs like this, is that like, what are the ways that our product design community kind of just gets better at stuff? How do we share information with each other? Are there things that you felt you've learned from your peers over the last 12 months, even a design concept? Or, you know, I still have design of everyday things on my bookshelf. It's one of my favorite books I'd read a long time ago. But are there things that you've learned over the last year from this community? And how do you make sure that everyone keeps getting better at this? Yeah. I mean, as I mentioned, we are continuously speaking to each other. We are sharing knowledge through Slack. Try to organize, for example, like we organized a design roundtable for all of the West Coast. And so we had new designers that joined, I know it's not West Coast, but Austin. We wanted to really help them understand the design community at Pivotal. And so we hosted this roundtable that included Seattle, San Francisco, LA, and Austin, some folks from Dallas, and some other folks that were able to join from the East Coast. And so we have conversations and talk about, like, what's really important to us in dot vote beforehand. And then beyond that is there's just such a wealth of information out in the community and in the world of design and product design.

You continuously have to keep up and learn and understand. Like, I follow the design and tech report, as I mentioned. There's a lot of great resources that, you know, great podcasts. One of them is my favorite is, like, high-resolution podcasts I listen to. I go to a lot of different events, like Creative Mornings, also active in Hexagon Women in Design Community, which used to be XXUX. So basically, it's really important to just be out there talking to different designers and really understanding what's new. An area that I'm really interested about is inclusive design. And so that is something that came out of OCAD University and is now a framework that Microsoft is sharing with the world. And so I had the privilege of bringing Tim Allen to come speak at one of the events that we organized in Seattle. And we did a workshop with him, myself, and Myra Vega from San Francisco. And that's been really interesting because, you know, in the world of MVP, minimum viable product at Pivotal, how can we make sure that we bring in the value of inclusive design early and sell that to our stakeholders and our clients so they can think about that at the beginning? And so that's one of the challenges and experiments that we're running with one of the clients next week who's really interested in this topic of inclusive design. And so I guess what I'll be experimenting with is to how to bring inclusive design into the lean world and what could that look like. And so that's one of the areas I've been really passionate about, learning more and practicing more, which really changes the way people design things. Instead of designing for the 80%, you think about designing for the people that are most excluded and then expanding that out to many.

And when you really think about the ROI, and Kat Holmes is really amazing, she talks about this. She's the director of inclusive design at Microsoft, and she says she gave this example of amputees in the U.S. And for example, if you're thinking about your primary user, you may not think about an amputee population, which is 26,000 people in the U.S. But what they frame it as is, if you think about someone who has a temporary disability, like if you break an arm or you sprain your arm, you're not able to use that arm anymore. Then you have a temporary disability, and that number jumps all of a sudden to 13 million. And then they frame it even further in a way that is more compelling, and it's thinking about the temporary, like situational disability, which is like you are maybe a new mother, and you hold a baby, or you have something that's preventing you from using your hand because you're carrying a box or a bag. Then that number jumps up to 26 million. So the area of design that's been really exciting for me is to try to understand that really the human experience, all of those, how we interact with the environment, and how can our products fit seamlessly within that environment that allows us to interact with them in a comfortable and safe and efficient way. So it seems like, I mean, no pun intended, one angle on some of that is like picking which perspectives to design for, if you will. And like how do you sort through those perspectives? Like that's a clever and a good way jump from amputees to people who only have one hand available to do something. I mean, your example was great. And so like how do you, like if you were to do the, you know, the four quadrant, you know, Eisenhower-ing, you know, priority thing, what's the exercise look like for here's all of the perspectives or potential users or personas or whatever.

What does it look like when people filter down to the ones that they want to include, I guess? I guess one of the things that's going to be the challenge to try to see how we can do that in a lean world, in a world of MVP where you have limited resources to try to get this minimal viable product out to basically validate the concept. And I think that could be something that you decide at the beginning to say like, hey, I know this product or service is going to be something that is used by the world and I wouldn't want to expand my reach as much as possible. And so after that early validation, hey, even if this is something that I should be solving for, I think it comes more in the framing phase. After you have defined a problem and validated that problem as worth solving, then during the framing, you start really thinking about, you know, who are the people that are being excluded? I think accessibility is one of the basic baseline foundations for this. I mean, you think about that, you think about like the people that are interacting with your products or service. You want to be able to be inclusive about all those folks. And so that is something that I don't think is optional. I think it's, you know, if you're building a great product, you have to think about the variety of users and that are going to be interacting with it. And also you have to consider the aging population. So I think at the baseline, you have to be accessible. And we've done some great work in the Seattle office, pairing with developers to understand what are those things that we can bake into our products early on so we don't have to go in and think about it after and refactor after. So then your product becomes more sustainable and scalable in the future. But then beyond that, observing your users and seeing what are those environmental constraints that are going to impact your product in the long run and which one of those to prioritize, I think, is an interesting conversation, interesting challenge to have.

And that comes from observing your users and seeing what are some of those, you know, early foundational choices that you have to make as far as the limitations of that product when it comes to inclusivity. What are those and which ones do you want to prioritize? That's something that we need to focus on and try to understand with your team and see which is more important, you know, is it going to be someone who is not able to hold your product or is going to have mobility issues or are they going to have visual impairment issues and how can you navigate those waters in a safe and effective way? Yeah, yeah. I mean, I think as ever, like, you know, wrapping one more abstraction layer around the core process of, like, seeing what models emerge to think about sorting those out. That would be fascinating to see, like, how you even, like, put it on paper to get to the point where you can make a decision. Right. That'd be fun stuff. Well, another, like, I forget when it was, but another follow-up question earlier. Like, I think we were talking about, like, I don't know, like, measuring things at some point. And I'm curious, like, how do you, how, talking of figuring out how to come up with the thing that you care about. Like, you mentioned something about, you know, I'll use a canonical example, right? Like, how come people keep abandoning their shopping cart or, you know, they could abandon an app or whatever. And, like, like, in your experience, like, how do, other than the obvious thing of, like, we would like people to buy the stuff in their shopping cart. Like, how do you come up with these tracer metrics that you can use to track if something's working or not working or if improvement is gone? Like, how do you, if you've got a blank whiteboard or a stack of post-it notes, like, what do you start asking about and filtering through? Yeah, it's, like, a really good question.

One of the things that's really important to establish early on is the benchmark of where you are with that product or service. And so if something that you're trying to improve, you have to know where you are to be able to improve it. And so what are those metrics that you define early on? And we work really closely with our product managers who play a central role in defining those metrics with our clients based on the business outcomes that they're trying to achieve. And so those become later on into, like, features that will be able to drive towards those outcomes. And so as you've defined a problem, validated that that is a problem that's worth solving, started framing a solution around it and testing that solution, you're going to have a lot of good data to understand, okay, you know, at least qualitatively, the users are wanting to use this product. But then once it's out in the wild and you're testing it with, you know, your early users, it's really important to have those metrics defined. And so depending on the business outcomes that they're trying to achieve, and then also the product goals that they had set at the beginning of the project, we will be able to define those metrics that are specific to that product. And so we can say, you know, the number of signups, for example, for this application or time spent on this page or time spent doing this or conversion rate of this specific, you know, sale of this product. And so those are something that we set afterwards and basically measure that with our team continuously going forward to see, you know, which feature is performing badly, which workflow is being abandoned, or how is it being improved by what percentage. And that's something that our product managers are really good at doing, and we work really closely with them to understand where is our product performing well.

And if not, how can we go back to the drawing board and iterate? Interesting. One thing I wanted to ask you, I mean, as we think about learning some of those metrics in this net, you also touched on earlier, even how you pair with different people on the team. And as you think of pairing across customers, and again, how you think about the right things you're tracking and measuring and even sharing inclusive design ideas, who do you pair with? And then back to the customer, do we always ask our customers to also provide a design person for you to pair with as well? Yeah, so one of the things that's really important working at Pivotal, you know, our mission is to transform the way the future gets built. And so what does that mean? That means, you know, we pair with our clients at labs to be able to teach them our software development, design and product management disciplines. And so they come into us, our workspace, we have co-located space for the team, we work together, we pair with each other. And that looks like an ideal situation would be that I have a product designer that's coming from the client side that I pair with throughout the day, throughout all of the different tasks and different workshops and different design activities that I do to help enable them to be able to work in the way that Pivotal builds and designs products. And so that would be ideal to have a client come in with a product designer. And so that's not always the case, you know, at times, you know, we may not start with a client designer at the beginning, but, you know, shortly after, we really encourage a client to help us to be able to deliver that value. And the only way we can deliver that value is to have a client designer to enable same thing on the product management side, same thing on the development side.

And so not only do we pair with our counterparts from our disciplines from the client side, but we also do that across disciplines. And so I will do a lot of pairing with my product manager from the client side and also Pivotal side. And same thing with the developers from the client side and our developers. And that looks like a lot of conversations. The nature of the way we work is so collaborative that, you know, there's very little need for any documentation or any specific meetings. So we can just turn around and swivel our chair and have a question, ask a question. We can do a quick dev design pairing where I can sit beside a developer and we can go through the designs and think, you know, really point out the areas that we need changes in. Same thing, our product managers are very involved in the user research and the interviews. And we also encourage developers to rotate in, you know, they may not always be able to be available during all different, all of them during all different user interviews. But, you know, we like to get pairs rotating in and sit in and really listen to the users. And that really helps them to understand the why. And I've seen like a light go off when developers are part of that story and they get really excited. And even through like through what we call a design studio, which is a sketching session that we do as a team after we've defined a problem that we want to solve. We write our hypothesis as a team and we go and sketch and we converge on a design that we want to go and test that fake. And so you're really able to bring in the expertise and the knowledge of your developers who are thinking about the feasibility of what we're building and also the product managers, you know, especially from the client side that are always thinking about those outcomes.

You know, those are our north stars that we're trying to drive for. And the designers, you know, who are thinking about how to add value from the user side and, you know, bring that moment of delight to the user. And so those three worlds coming together and sometimes data science, because that can really help us understand how to visualize things. We come together and we collaborate and basically design becomes a team sport. And it's a very collaborative process. And I guess as designers, it's our role to be able to facilitate those design conversations and help the whole team really understand how to do this for themselves and how to basically think about the problem from a user's perspective. Well, I have a final question, then we'll wrap up. I was, I was, I was doing my, my research and maybe there's, there's someone with your same name over there in medium, but I, I, maybe this is back when it was liking versus clapping. I just like to say clapping, but I think, I think you, you clapped. I don't know if you actually did it audibly or just clicked on something. That would be a fun design discussion. What's up with this clapping stuff or whatever it was that, but there was, there was a write-up of like the, the golden ratio. And, uh, I don't think about that very much, but, uh, you know, uh, I was reminded, uh, the question I always have is like, but why is that so appealing? I mean, it is appealing, right? Like, especially when you get the pictures with the shell superimposed on it and all that stuff. But like, why do you, uh, what it is about that thing that makes it nice? I think it's, um, it's really interesting because, um, I, um, into like a spiritual, um, world and have a lot of those kinds of, um, interests. And so I spend a lot of time thinking about these things. And so I guess, um, the golden ratio is something that exists in nature. And so you can see, um, it's the very beautiful mathematical formula and that creates this harmony in nature and basically the way the world is built.

And I think that's, that's, that's what's interesting about it. And if you think about, um, golden ratio and design, um, that's something that really allows the eye to be able to, um, understand what is pleasing. It's, it's a natural looking composition that you can leverage in your design work to be able to, um, create something that's harmonious and visually appealing. And this gets into a really other interesting area of called biogeometry, which is the study of Egyptian temple science that really measures the vibrational effect of objects and shapes. And the ratio plays a huge role in how you interact and feel about that object. Um, but that's a whole other conversation. Oh yeah. That sounds interesting. Well, I like, I like the, uh, so, so at the very least there's sort of like, I, I forgot that part about the golden ratio shows up in nature a lot. So there's, there's like a familiarity to it. Like if you end up seeing that over your lifetime, it's just like comforting, I guess. Well, I assume seeing things you're familiar with is comforting unless you're familiar with terrifying things, but there's, there's, there's things that are not trying to attack you in golden ratio. Uh, and then, and then also, I mean, I don't know if there's some sort of like, uh, evolutionary theory to design thing, but like, there's probably something that if all of this stuff has, uh, evolved to be golden ratio ish. Uh, not that it's sort of like, uh, I don't know, teleologically means something, but like that there must be something nifty about it, that things, whether they're plant shells or, uh, or people, but yeah, you see it in plants. You see it, I guess, in like at least 4,000 years back, you see it in the way the pyramids were built. And so, um, you see it in a lot of, um, art by Leonardo da Vinci is like one of my favorite painters and Michelangelo also, um, you see it in like the last supper.

It's really interesting. And so I think it's this underlying universal law, um, that is very mathematically driven. And I feel like we resonate with it in a way that, um, makes sense to us. There's a really, um, great biologist, uh, Rupert Sheldrick that talks about this theory of morphic resonance. And he really studies the, um, the vibration of things and the resonance that you go into with these objects. And it's really cool. That's also another whole topic. Um, but yeah, that's really important to understand the impact visually and vibrationally that your design has on the world. That sounds like something that would have put on the, uh, that gold disc on the Voyager or. Or the Joe Rogan podcast. Yeah, yeah. I mean, I mean, in, in theory, if, if something like the golden ratio is a, uh, I don't know, mathematical nature, uh, universal, then the fact that you could like, you knew about it and you could like print it on something would be one way of communicating with other intelligent things. Right. That like, yeah, it's sort of like, uh, somewhere a couple centuries below warp technology. Like we reach this level of understanding. So we must be intelligent. Right. Something. Anyhow. Well, uh, thanks for being a guest. That, that was good stuff. Now I need to go look up some, uh, vibration things. Now that I know the, the, the, uh, the sort of street name and the fancier name for it. I can go look into that. I was so, uh, in, in addition to having more, uh, design people on, which, which we've talked about a little bit, where, uh, where would you point people to if they were interested in, uh, more things, uh, that you work on or just, uh, pivotal design things? What's a, what's a, what's a, what's good follow-up for people? Um, I think the good follow-up for people from the outside looking into the pivotal community would, um, I guess we have a lot of amazing talks on YouTube, but I think we are, as I mentioned before, need to really bring out, um, and surface and communicate and share our internal stuff with the external world.

Um, and I think we're working on that now, so that's going to happen within the next few months. Um, so I think until then, um, there's not a lot of things that we can really point to, um, but hopefully very soon we're going to have our field guide that we're going to be able to share with the community, um, at large. Well, that sounds good. We'll have to, uh, we'll have to have a, uh, uh, uh, I don't know, a follow-up as, as that emerges. Yeah, totally. Well, great. Well, uh, thanks for listening. As always, this has been Pivotal Conversations. If, uh, somehow you're miraculously listening to this episode and you don't know where it came from, maybe, maybe, uh, there was a big conversation at dinner and Alexa just started playing something. This happens to me every now and then. Uh, if you want to find this episode and many others, you can go to soundcloud.com slash Pivotal Conversations, uh, with no space or anything. And usually every Thursday, if I've, uh, done my job, uh, we have a, we'll post the show notes over at pivotal.io slash podcast. And with that, we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.