BUILDSUCCEED
Kyle Crouse - Transforming UX: The Power of Design Technology
On today’s episode, we’re joined by Kyle Crouse, whose previous roles include Senior Manager, Design Technology at Amazon, Principal Design Technologist at frog and Creative Technology Director at Method and Visa. He is currently Director of Concept Technology at Very Good Ventures. Kyle discusses the integration of design and technology in product development.
Host - David DeRemer: Alright. [00:00:00] Hey Kyle. How's it going man?
Guest - Kyle Crouse: Good.
Host - David DeRemer: First, first VGB podcast. It's pretty, pretty cool. I know. And,
Guest - Kyle Crouse: honored to be your trial.
Host - David DeRemer: and to do it with a good friend. Um, so, so, uh, how are things in California these days?
Guest - Kyle Crouse: Uh, nice and warm. Uh, you know, summer's, summer's here. Ready for the beach.
Host - David DeRemer: Nice. Well, for us East coasters, it sounds like that place is about to fall off into the, some sort of weird crack in the earth and do some weird stuff. But, um, yeah, I guess that's a good segue. So you're out in California. Why don't you kick us off by telling us a little bit about your background and where you're at.
Nice.
Guest - Kyle Crouse: I am sure. So I am, uh, based in la um, I, uh, been with VGV for about a year. Um, prior to that, uh, I was in a design studio, uh, within Amazon, um, both here in LA and in San Francisco. Um, doing advanced product, uh, design and concept work, coming up with new devices services. Anything really within the entirety of the Amazon ecosystem.
Um, and generally speaking, I have a background in, uh, design agencies as a design technologist. Uh, I worked with you at Frog for a very long time. Um, and then at uh, Method. Um, mostly all of that in, uh, in New York City.
Host - David DeRemer: And I famously defeated you in the one and only frog foosball tournament we ever [00:01:00] had.
Guest - Kyle Crouse: hey, hey, hey, I don't wanna, I don't wanna hear about that. We were formidable on the, on the team. Wild stallions forever, you know.
Host - David DeRemer: Yeah. Well, you know.
Guest - Kyle Crouse: ha.
Host - David DeRemer: Couldn't, couldn't defend us, but, uh, yeah, I'll get it. Well, so listen, you say you're a design technologist, creative technology. I thought maybe we'd start there. Cause that's something that, you know, I've talked a lot about and. Um, even within VGBA, as we start building out new disciplines, I think that's a, a category of work or a role or function that confuses a lot of people.
And I was wondering if you could just start by explaining what you think those, like, what is that? What is that discipline?
Guest - Kyle Crouse: Sure. So design technology I think really is what it says. It sits kind of right in the middle of both disciplines, design and technology. And, um, I think folks who specialize in this kind of creative technology, they're, they're makers, they're tinkerers, um, hackers, experimenters, but they also tend to have a really strong sense of, uh, you know, User experience and quality in that regard and like a focus on details and patterns of design and why you do certain things you do and how they're in service of quality [00:02:00] Customers so that you can, um, bring technology expertise to the design process.
Um, so that as you're thinking through new concepts, you, um, have confidence knowing that things are, might be particularly feasible one way or another where trade offs can be made for like. Uh, expediency or cost savings or whatever it might be. Um, you can very quickly, uh, prototype options to prove out design hypotheses and kind of iterate really rapidly to gain more and more confidence in the, in the, uh, Feasibility of a certain design.
Um, and then importantly, go back downstream as something transitions from design, goes more into engineering. Um, it's a bridge opportunity to take the knowledge around design and how something is, Is meant to be implemented and translate that downstream to make sure that, uh, the, the, the fidelity of the user experience is, is maintained as much as possible that the, uh, technical criteria that were kind of defined as you work through the design are kind of successfully [00:03:00] transitioned downstream.
If there's more prototyping that you need to do in more detailed level, that's great. Um, oftentimes design technology, design technologists, um, can and do play like a bit of a front end UI engineer type role sometimes. Um, you know, with such a keen eye for making sure that there's a high fidelity of user interface implementation, that can be a good role if it's someone who is well versed in the nuances of, of production engineering and what the differences are for more of that upstream, like, you know, quick and dirty, uh, prototyping type of engineering.
So it's, it's, it's a nice hybrid, you know, , in both places, but you're really there to like ease that transition and make both ends, uh, smarter.
Host - David DeRemer: Do you think it's, um, mindful and purposeful that it's called like design technology as opposed to like technical designer or, or sort of the inverse of that? Like, is there a difference between, is it more design led or, or engineering and making led? Does that make sense? Thanks.
Guest - Kyle Crouse: Yeah, it does. And I, I've always. appreciated that it kind of is design technology or design technologists because I think with design first it's accentuated more that it's about design and [00:04:00] technology within design. Um, I think the inverse, you know, has a much more specific, uh, role connotation around technical designer and, you know, being someone that's coming up with more of a, of a, of a hardened technical solution, right.
Um, whereas I think in the, in the, in the other sense, you are more designing through technology. Um, and. I've seen it used in a lot of different ways, and they have, think they can have slightly different connotations, whether you think of design technologist versus a creative technologist, you know, um, and and what that might imply.
But either way, you are someone who is more trying to come up with solutions for customer experience, and you're just looking at whatever technical options you you have that you can bring to bear that might get you to that solution in an elegant and efficient way.
Host - David DeRemer: Yeah. I was curious, you know, a lot of people who maybe haven't heard this might think it sounds like, well, wait, when you're doing a startup, you're doing a lean MVP, you're kind of just, you know, trying stuff out, prototyping, shipping things quickly, how would you compare sort of like that type of activity where you're kind of like literally a lean MVP and you're just going to build something and putting out there and see if it's successful?
[00:05:00] How would you contrast that with the actual discipline of, of design technology or creative
Guest - Kyle Crouse: I think it's very similar. Um, I think, you know, I think the biggest trait of the biggest traits of design technologists are that, you know, you have a keen sense and understanding of design. Um, you have a thorough understanding, um, uh, an aptitude for technology. Um, but you're really adaptable to whatever the situation might be.
And you're really comfortable with ambiguity. Um, because I think You know, if there's if there's three kind of aspects to general like technologist, you know, there's the ability to like, build an idea out of thin air, there's, you know, create something out of thin air, there's ability to like, make it into a real thing.
And then there's ability to scale that thing. I think, you know, more often than not, any kind of technologist is really going to be good at Two out of those three things. Um, and I think a design technologist and people, um, in that ilk, which is where you compare to startups, I think they're going to be really, probably pretty good at like coming up with a new thing, building through like, uh, how to make that thing a reality, um, and getting it out there to a certain state.
And then. You need to start shifting and think like, how does this become durable? How do we scale [00:06:00] this? It starts to become a whole different animal. Right. And a lot of times there's a real difference in, uh, design technology because you don't concern yourself with scale more often than not. Right. You don't concern yourself with like longevity of something you are building things to kind of prove a point and then throw it away.
Um, or kind of like get to a certain point. And, you know, uh, move on from there. Um, so. That might be the case early on in a startup when you're just trying to ship something to market you're just trying to get It out there and you're not trying to be considerate of where you go with something long term Which you probably end up with a lot of technical debt because now you have something out in the world that wasn't built hardened in the first place But but going back to the original question, I mean, I do think that there are similarities in that regard It's just that you know from a startup perspective.
Ideally, you're more concerned with like What is going to happen to you once you do get it out there? And I think on the design technology perspective, um, you, you might be a little bit less concerned with that depending on where you are, uh, what you're working on.
Host - David DeRemer: Yeah, I think they're like if I understand them correctly, they're both trying to get at similar results, which is how do I improve my product? But when [00:07:00] you're thinking about a lean startup MVP type thing The idea is like get it out there and your users will tell you if this thing is being successful whereas as In our conversations and my understanding of this is you're investing in some technology and prototyping and explorations really to inform and improve the design, um, which is a little different than like once out there.
You're like improving the product or getting a sense of are the features doing well with clients or something like that. Um, so I almost think that the same mentality could live in both areas potentially. Um,
Guest - Kyle Crouse: A hundred percent. Yeah. Yeah. A hundred percent. I think you, you are trying to improve, um, inform and improve that design process. This also kind of, uh, is under the assumption that you're building functional prototypes to begin with. Um, you know, I think it's, it's, it could. often be the case, you know, within design technology that what you're building is not even functional.
You know, you're doing something more smoke and mirrors, Wizard of Ozzie, you know, where you're just trying to understand and experience, um, or, or hook up small component of it and not try to build something more functional. Whereas, you know, on the lean side, you You know, your, your primary focus is to make it functional, um, and worried about checking off those boxes of something working, um, versus, uh, uh, proving out some discrete aspect of the, of the, of [00:08:00] the feature.
Host - David DeRemer: Yeah, yeah. Um, you've worked in places where these companies have prioritized this. You've worked at some pretty amazing places, you know, so like Frog Design, one of the top design agencies or consultancies in the world. Method, owned by Global Logic now, which is another big, incredible, one storied firm.
And Amazon, of course. Everyone knows Amazon. Um, yeah. So, you know, what is it about those firms that allow this, function, this capability really came to bear? Because I think especially these days, it might be hard for a lot of companies to understand how to invest in this. You know, everything's so lean, so fast.
Um, what are the situations that kind of like allowed this discipline to emerge? And what is it about, you know, those types of companies that make this discipline thrive?
Guest - Kyle Crouse: When you look at companies like frog at the time when we were there, you know, frog did not have any engineering capacity other than, you know, it's kind of wholly separate, um, engineering company that sometimes it would deliver things to, but the majority of the client engagements, um, that, that, that we would work on would never, have a specific engineering resource or capability attached to it.
Um, so you, you ended up with these scenarios where you would design all of these beautiful artifacts and then [00:09:00] hand it over and Whatever happened to it happened to it. And more often than not, because of handing it off to an engineering team, uh, the, the faithfulness to the fidelity of whatever that design was, uh, may not be met.
Um, design technology helps you fill that gap because the role that we played in that scenario was to, um, Help bring the technical knowledge from the client teams upstream into our design process so that as we were designing, um, we weren't doing so in a black box. We weren't handing things over that we knew would not.
Like, things that we handed over we knew could work some way in their system with some level of effort attached to it. Um, and then we might, uh, prototype some of those to give to the client as examples, especially if they were for, uh, richer, more fluid things, not just flat screens. Um, If we, uh, if, if, if in some scenarios we would develop like what we called reference code, where we would basically build the front end of the application in a way that would be appropriate for, um, integration into their systems and then production hardening.
Um, and then kind of, as I was saying earlier with the two sided nature of it, then going and sitting with the client team and actually helping them. [00:10:00] implement the front end, you know, whether it was the code that you delivered or, you know, just helping them build out the designs within their front end environment, you were able to kind of bridge that gap to ensure that the client had more success in what they shipped because it met more of their expectation on their users needs around what was originally designed in the first place.
Right. And it made sure that their investment in all of that design was was sound because they ended up with the thing that they spent the money on instead of something subpar.
Host - David DeRemer: Yeah, I feel like so much of it is still, we, we talk about this even still today. And it's one of the things we're trying to do here is. improve that designer developer handoff, right? And a lot of times there's a lot of gap, you know, you go develop, like you said, you develop some beautiful artifact and then you hand it off to the developers and they're like, okay, uh, what do I do with this?
And how does it behave? And you missed a million things and bugs in code are obvious, but bugs in design often are not. Um, so is that one, like, do you think design technology helps to identify bugs in the design as well?
Guest - Kyle Crouse: 100 percent and gaps. Um, I think that that was one of the bigger things where, where we kind of started was, you know, you, especially before like some of the more modern tools came online that allowed you to be more, um, [00:11:00] interactive in your design. Um, you dealt with just flat files, right? Like photoshop comps and things like that.
And as, um, you moved away from like traditional web pages that were just like one page, one page, one page more, kind of like almost like print layout. And you thought about web applications and how things moved and transitioned and like going from one state to the next, um, and, and more discreet components, um, the design technology.
was really vital there because you could stitch together those different flat artifacts, um, as references and have a deliverable that highlighted those transitions and that overall, like, statefulness of the application, right? So that you could have a much more robust, uh, deliverable while not having to overextend, you know, the, the, the skills and time required of the design team.
Host - David DeRemer: I mean, you mentioned that it's like it's changed a lot, right? I mean, back in the day, you're right. Early on, it was just Photoshop. I mean, people were designing early iPhone apps and, uh, and things like that in Photoshop back in the day or Adobe Illustrator or those types of tools. And obviously the tech [00:12:00] has really come a long way of tools like Figma and other things where you have all this capability to develop clickable prototypes and, you know, Design to code solutions and things along those lines.
Um, but I think we, we all still feel like there's oftentimes a real need, not just to just have that sort of clickable prototype that you need a kind of more fully formed experience to really validate the design or really learn from it. Um, so I know you've had probably a ton of these examples from your time at frog method or, or Amazon other places, but are there like any specific examples you could talk about where.
The, the ability to really do this, that you had the, the client, um, the budget, the, the mandate, or the, at least the, uh, uh, the permission to build something real to validate the design, um, do you have any examples where that really proved to be vital to the success of the product?
Guest - Kyle Crouse: Yeah, one really stands out to me that was really a comprehensive effort, um, was while we were working at Method, um, working for McDonald's. And it was around the time Method was working on design of a new mobile application that was meant to kind of globally [00:13:00] serve, McDonald's across, uh, almost every country that they operate in.
And as a part of designing this application, um, we started working with the restaurant innovation team to understand what is the digital to physical transition when a, uh, McDonald's customer, uh, starts, uh, creates like an order or starts approaching the property with some kind of intention to take a digital behavior into the physical world.
Um, and we, uh, answered that question through many, uh, rounds of, uh, physical prototype testing, um, and doing lots of research that started out, um, very, uh, um, uh, paper prototype, kind of, uh, uh, quick and dirty around, like, creating totally fake drive thru screens with applications that didn't work, that just had like comps and things like that, whatever would answer all these questions.
Because what we first needed to add, uh, to understand was, um, there are many different types of McDonald's in the world. Um, and from one country to the next, uh, customers engage with McDonald's in different ways. And they have different expectations of what happens there. You know, in [00:14:00] some countries, McDonald's can almost be considered, is almost considered like a morphology.
Um, and then you also consider, um, you know, the formal, like, night out kind of dining experience, where you go and you sit there for a long time and, and you, you
occupy your table and you, yeah, no, it is, but it's like, it operates differently, right? In some countries, this was kind of, before it was a bigger thing here, um, but in some countries, it was all about delivery.
Um, you know, and then you also consider, um, you know, All the different ways that you can engage with McDonald's, whether it's going to the drive through going up to the front counter, um, you know, curbside was a nascent offering at the time, um, and considering like table service and things like that. So you had all these different ways that a customer could just appear within a McDonald's environment and expect their food, um, or from an ordering perspective.
Um, so, you know, we. sat down and first tried to identify it. Well, what are the technologies that we could potentially bring to the restaurants that would enable this handover? What are the pros and cons of each, um, in terms of cost, ease of implementation, ease of like fleet management, ease of integration with the app, customer experience, crew experience, like all of these different things, and you create.
Um, all of these really rapid prototypes, um, that will [00:15:00] allow you to test out all of these different types of configurations, some more or less functional than others, um, and you, we created, you know, like a, a fake drive thru board and had people drive around a parking lot and pretend that they were using the drive thru and testing this app and we had like crew scripts that we would read out as if we were actual McDonald's people where you can basically get to an assessment to say like, These are all the impacts of these different technology and UX experiences on drive thru, on in store, um, et cetera, et cetera.
Formulated down to, like, what's your plan, so that we've kind of eliminated a lot of the, like, trial and error around, like, big technology investment to really be able to hone in on what's gonna work for the different types of configurations that would exist country to country. Then, once we kind of have that Simplicity.
Then we can invest a little bit more to do a higher fidelity round of prototyping. Right? So we actually built a mobile application. We connected it very lo fi connected it to, uh, the, uh, in restaurant. APIs [00:16:00] to submit. Uh, orders, deals, whatever, into the restaurant. Um, and then start taking people through a live restaurant.
Um, going through the drive thru, going through the ordering, having them do all different kinds of things, having them experiment with many different types of user interfaces, different methods for checking in, etc. Where, you know, By spending a week on site run running, you know, five or six customers through an hour of trials every day.
We can very quickly identify this technology is not going to work in the restaurant for these reasons. This UX is not going to work in the restaurant for these reasons and and say, and I and narrow it down to solutions that we have a lot of confidence, um, if we were to invest in a production, build and roll out of this technology and this design.
it will be successful. Um, and then we iterate over that, you know, uh, for a couple of months through different kinds of tests, getting more refined and more refined and more refined to a point where a crew playbook is written, restaurant functionality is developed, mobile functionality is developed, and then it ships in [00:17:00] the application and you have a successful mobile check in, you know, that you don't need to go and do a lot of amending to, you know, you've proved out and gotten to the point that it works well.
Um,
Host - David DeRemer: designers do some research, design something, do some user research again, um, and then just fund a development of something and you better hope it's right. Right. I mean, if it's, if it's, if you missed a key detail, uh, some of these things you unpacked, like, were there some, well, maybe not some key details, but you know, it's, it's interesting to think about like, what are the, uh, The things you learn from having a real experience for people to interface with, um, to validate your design versus just a, you know, focus group or some sort of online tool or, or something like that, you know, people don't give the same answers a lot of times.
Guest - Kyle Crouse: being able to iterate on it in the real world without just, you know, kind of coming up with comps and putting, you know, ideas in front of people and asking them how they would, how they would behave or how they would use it, you know, having it functional in the real world, um, allowed us to see the like, nuance in interaction, um, and, and difference in impact to the overall experience in business at a much more granular level and allowed us to [00:18:00] iterate much more quickly, um, to, to have a higher velocity overall to get to the end point that we needed, um, without having to, um, you know, reset the whole process and do all this guess, guesswork and like, You know, be uncertain if something will work or not, go with a gut feeling, right?
We can actually prove it out and generate the data that we needed, um, to, to get where we needed to get. You know, and it's like you're talking about like, one interaction would, uh, have like a five second difference on drive thru. Um, overall time and drive through, and that doesn't seem like a lot, but when you stand up those experiences side by side and you see a difference like that, that's like thousands of dollars a day to a restaurant in something like that, right?
So, like being able to prove it out at that little bit of detail, um, and generate data around that has a huge return on investment.
Host - David DeRemer: Not only that, but customer experience too, right? No one likes to sit there for five seconds, even five seconds, right? Um, it, it's, uh, when it could take one or less, uh, and you have that, you're sitting there waiting, should I advance? Should I move up? What should I do? You know,
Guest - Kyle Crouse: Yeah, well, you know, we can even see that by like by running through a very, you know, diverse customer base through all these things we can [00:19:00] start to identify things like, you know, there are certain things that people are more inclined to say than not that we want to lean into. There are certain, um, uh, like if we give them a code.
Um, there's certain letters and numbers that we can kind of reduce it down to that will remove any like language challenges, you know, as you communicate over sometimes not a very great quality speaker to someone on the other end and things like that. So like having real people go through all of this stuff and then be able to iterate super quickly.
I mean, we make, you know, changes day to day, uh, in the mobile application to try out an entirely different scenario the next day. Um, so yeah, it's very, very quick.
Host - David DeRemer: Yeah. Yeah. What were some things about those environments? You know, what, like, again, this sort of the, to the question of, of the environments you've worked in, um, are there certain like cultural, Behaviors that teams need to be able to be effective with this type of approach. Um, like what kind of collaboration do you need between different disciplines and how might that be different from what a lot of like large organization product teams might be used to.
Guest - Kyle Crouse: It's really helpful when the organization, um, I think first and foremost appreciates the customer experience and that, that, that [00:20:00] making sure that, um, what they're providing to their customers is, um, something that is going to be as friction free as possible and as delightful as possible. Trying to eliminate frustration, right?
And, and if you have a, a client that's really invested in what they are giving to their customers, that's a big start because you can ground your conversations in what's going to create value for the customer, what's going to create delight, um, uh, for them. And then. You know, it's, it's, it's added bonus on top of that.
If it's a client that can recognize the value that design brings to the table to answer those questions, um, to generate data and validate hypotheses that get you to a solution that you have confidence in implementing so that you're not just. Going and running off and building, um, without data, um, that talks about how customers would use something, how they would feel, uh, about something, um, [00:21:00] that allows you to craft something and bring the data to the table that will influence how something gets implemented, that you can then take those requirements to a build and say, like, we know that this is what we want to put together and then let's go do that.
And you can just have more confidence that what you come out with the other side is not something you're going to need to go make like a huge new reinvestment in because you like miss the mark or something like that, right? Um, it just gets you there faster.
Host - David DeRemer: Yeah, so I'm curious, like, obviously that's a huge company, this example you're giving, and they have tons of locations, and you would think of the, the cost of getting it wrong would be really, really high. Um, but I think these, these ideas and these approaches are useful for any company, even a two person startup.
What would you say to like the early stage company or, or, or a larger company that's like, ah, we don't need to pay for this. This sounds really expensive and let's just like, you know, we got smart designers, smart developers, and we know our business really well. Um, you know, how do you sort of like get around that, you know, how do you kind of illustrate this value?
I think the things you're saying are like long, long-term value. Like, hey, you're gonna really de-risk your future and you gotta invest a [00:22:00] little now to do that. Is that really the case? Or what are their business results? Um, would stakeholders be able to look at here that would help, you know, unlock new value or justify an investment.
Guest - Kyle Crouse: I think that's really where the where the opportunity is, is, you know, if you have the patience for what an investment in this type of work is going to provide for you long term, you're going to get like compounding value on that as you go through this process, because you've you might have spent a little extra effort initially.
to really understand what it is you need to do and validate that it's the right thing to be doing. But you can have that confidence so that when you then go into the next phase and you start putting it together, it's not really an unknown. You, you have all this data that confirms that you're going in the right direction.
You're not going to have to undo things that you, uh, that you did. Um, you can spend less time on, uh, uh, Like iterating and trying to get it right and more time on [00:23:00] growing. Um, and because you've already started with that really solid foundation. Um, and then, you know, specifically from a design technology practice, I think you also accelerate that initial handover right into knowing that what you might ship, uh, From a code perspective is going to be more robust, um, more elegant, um, more capable because you've had this transition from design through engineering and you can really focus on providing like quality code quality for an end, um, you know, and, and I think in the end it all adds up to, uh, maximizing that return on investment so that you have more opportunity to grow in the longterm and maximize your, your, your revenue and things like that versus, you know, sinking it into trying to like fix the things that you didn't get right the first time.
Host - David DeRemer: Yeah. And get that delightful user experience too. Right. I
mean, I mean, I think that's, well, that's it. Let me ask you about that one. Cause you said that a couple of times earlier and. You know, I think people talk about user experience and the importance of it and the quality of it. And I think, um, a lot of times when we're talking about design, we're trying to get that right.
Um, and that we, we inherently feel like there's good value in safety. You know, obviously there's real value, like saving [00:24:00] five seconds at scale. That could, that's a lot of time, a lot of money. Um, but what, what is delightful? Like what is a delightful user experience? Like how would you actually define that?
And what is the real value of that?
Guest - Kyle Crouse: Yeah. I mean, to me, delightful is, um, doing something that giving, giving a user something that saves them a few seconds in their day. without frustrating them. Um, you know, if, if I can, if I can make someone's life through some kind of digital product or experience a little bit better, happier, less painful, then that's success.
That's delight, right? Like they don't have to like use something and have like a giant smile on their face. That'd be great if they did, you know, but at the same time, it's like, if you do something and you think, Oh, that was easy. Or if you just don't even think about it at all, then like, It's worth it to put that effort in because it doesn't end up with a negative connotation,
Host - David DeRemer: I think that's super key. I think so many companies, they focus on like, we need some, we need to win a design award, right? Like we need some flashy UX that Apple will celebrate or something like that. And I think you're right. Like realistically, like, you know, you want to get in and out. I think I've always appreciated Uber's approach to design in that sense where they're [00:25:00] like, It's almost like their metric is minimize the time in app, you know, like I want to open it, get my car and that's it.
And then next time I open it, that's when I rate and add a tip or whatever. And like, you're not trying to keep people in it's exact opposite. I think a lot of people focus on, we have to have some beautiful design, you know? And I think that's an important, really strong call out that sometimes it's just like making it more efficient, making it so you're like, huh, I didn't have to waste too much extra time doing that thing I needed to do.
Guest - Kyle Crouse: yeah, it's really about getting out of people's way, right? Like, meet them where they are, and then get out of their way. Um, and I think that that's, that's where you really have a lot of opportunities to, engage with people and make them feel good about an experience that they're having is if you don't, uh, if you aren't making things difficult for them, right?
It's like, look at like, um, things that, People complain about a lot, um, you know, different experiences that they have a really hard time with. And there's always some kind of like really complicated friction associated with that thing that's like a huge pain point that just makes it difficult on people.
And if you can like remove those little tiny points of friction and just make it overall better for them, you save them some time to go focus on something that they want to be focusing on versus like making [00:26:00] them slog through whatever to like deal with, you know, whatever you've given them.
Host - David DeRemer: Yeah. Yeah. Yeah. You mentioned when we were talking the other day about this, so like sort of The role of, of thinking about the customer and these experiences as well. And sort of the, the confidence to push and test and prototype. And I think that's also part of it. I think a lot of companies. Or teams wanting to start something, they're afraid to put something out as a prototype.
They're afraid to like, engage real customers with something that's not like, totally perfect or done. Um, and you had this comment, I think about like, they will never know what you didn't do or couldn't do. Um, and I was just wondering if you could like, elaborate on that a little bit more in terms of like, how to think about how to engage technology and design in an early prototyping phase and have the confidence to test with real users.
Guest - Kyle Crouse: Yeah, I think, you know, sometimes, uh, going through the prototyping process helps you narrow in your focus. Um, and maybe you have, like, some great idea, um, or some, like, really cool functionality, and you would love to be able to work that in, and you would love to be able to provide this experience or that experience, but your kind of prototyping process allows you to Assess those things in a [00:27:00] way of like, well, how feasible is this going to be?
What value is it going to give me? And if, if it becomes too difficult or it's not even possible to do this kind of thing, then like, well, that's a really bummer. We'd like to be, we would have liked to have been able to done that. Let's hold on to that thing, you know, and keep it in our, in our backlog. And maybe the technology becomes more available or our systems become more capable
or customer acceptance is higher, uh, in the future for this kind of behavior. And let's focus on the things that we know would meet our, uh, criteria. Because while we might be disappointed, we couldn't have necessarily shipped a particular thing, we can still provide a thing, you know, and we've kind of proven that we can provide a thing that will get the job done and make people happy about it.
And they'll be fine with that because they're happy. They're not going to be disappointed necessarily that they didn't get the great thing because they never even knew the great thing was something we were considering, you know, but we shipped them the thing that works and that made their lives better.
And that's the important thing.
Host - David DeRemer: Yeah, I think that's super important. I think if people are looking for that great thing and, um, executives push for that, designers and product people push for that. You know, I think there's a healthy [00:28:00] tension that comes for that. You want to push, but you're right. You know, you gotta realize that only, only we know the people making the thing, uh, all the deliberations we had or the things that we talked about doing or could have done, no one externally knows about those things and you can't get hung up on that stuff.
I think it's a really good insight as you think about building a product. Um, what other like insights have you collected over the years that you have stuck with you and that you kind of have taken forward with you in your career as you continue to grow?
Guest - Kyle Crouse: Well, I think, you know, even back to what you were just saying, I think that that's where really the, the, the generating the success, um, you know, as you work through a product like this, I think, you know, that's where it's really important is to say like, you know, By going through these prototyping processes, you can, uh, and validating feasibility and desirability of these different things.
You're like guaranteeing more opportunity for success, um, in how you're going to ship these things because you're not. Designing some pie in the sky feature that can't be done. And then, you know, internally, everyone is upset that they couldn't make it happen. Engineering teams miss marks and people start, you know, uh, uh, [00:29:00] flailing, trying to make things happen or something gets said out in the world and everybody's disappointed that you never met those marks, right?
You know, by, by putting in that extra effort, you can kind of shape What success is really going to be with confidence. Um, so that you can, you can really get there. And I think that, you know, that's being able to establish the right expectations, um, and, and, and generate that confidence is like one of the biggest things I think you can really do when you're working with clients to like, get products out in the world.
Host - David DeRemer: That's, that's really, I mean, I hadn't really thought about that exact angle before about the influence that building something early in the process has on the, on the output. Because if you're going to get to build that automatically is a constraint on the experience because you have limited amount of time and it takes extra time to build something.
Right. And so I've seen this in my career, working with especially, especially a startup team, small team where the founders are really design oriented. You know, in the absence of having a technical partner, what do they do? They iterate the design. They just keep like adding features. They keep twiddling, like twiddling things around, tweaking things around.
Um, I don't think twiddling is the right word, but you get my point. Um, and, uh, and before you know it, you have this like [00:30:00] design that is like version seven and it's got all these things and you hand it to an engineering team and they're like, this is going to cost like a million bucks. You know, it's so much stuff.
Um, but if you inject a little technology early on, Like you're automatically going to put a little bit of a throttle on your design execution ideas in some ways, right? Because you, you, you need to think about testing the features that you're already working on, not the next one. You know, um, and I think that's a, a good compelling way to think about it.
Not to say that you're limiting your creativity. That's not what I'm trying to say, but it's like, it forces you to test your assumptions and the things you've already been thinking through before you just move on to the next feature or the next designs concept. Right.
Guest - Kyle Crouse: I think it's about being clear eyed around, you know, what, uh, what's, what's, what's possible. Um, you know, and, and it's like, we do ideation all the time where we just come up with as many things as we can throw at the wall and, and try and synthesize that down into, you know, interesting ideas, um, that we could potentially try, um, either as a new product or as a part of a product or a greater service offering or experience, whatever it may be.
Yeah. Um, part of that process is to use, you know, our expertise [00:31:00] in technology and the current landscape and user behaviors and all of that stuff to kind of categorize those ideas in order to understand how to interrogate them so that you can say, you know, this is a near-term idea. This is something that people know how to do.
I have the capabilities to pull this off. It's technology that exists. We could consider this. Much closer in if we wanted to, you know, on the other hand, you know, we have our far, far out ideas that are, you know, maybe we need, uh, to build out some other systems on our side. Um, we need X, Y, and Z services to come online.
Maybe we're still trying to like get customers used to a particular new behavior that maybe this is something that's like two to three years out on our roadmap before we really get there. Maybe something is totally speculative whereas like 10 years from now. When, like, these technologies align and we have this kind of customer experience, this is what we can enable, right?
And it becomes more of, like, a vision, um, something that you can work towards. But in all of those buckets, you are, you know, using that expertise you've acquired through, um, understanding users and, and technical abilities [00:32:00] and client needs and all that stuff to, add that correct lens to everything. Um, you know, it's essentially, like, you know, like prototyping.
The ideas, you know, without actually building them out to figure out where they could potentially come into play.
Host - David DeRemer: Nice. Yeah. Makes sense. Um, so this is great. I mean, we're getting close to our time here, so I just wanted to see if you could bring us home and. Just ask you if, uh, if you had advice for people building digital products out there, it's a complicated world. There's a huge variety of scale and different, you know, platforms and ways that you can build these things.
But someone out there who's, you know, maybe working on a team and trying to be successful in their career with their company and with their product, like, do you have any advice based on the experiences you've had in your career and in your life, um, for those people who are looking to maximize their, their chance of success?
Guest - Kyle Crouse: I mean, I think the thing I would say is like experiment early and often and put things in front of real users as often as you possibly can to get feedback, you know, show them different versions, whatever. Try and validate, um, As soon as possible, um, to before you [00:33:00] get too far along in a process, um, and kind of end up doing something that you can't undo.
Um, I think the more you can do that, the more you set yourself up for success long term. Um, and then I would say from more from a practitioner's perspective, you know, Be curious and don't sacrifice quality, right? Like, I think that you always have to be asking questions. Why this? What about this? How about that?
Etc. Right? Like, just be constantly interrogating stuff to like, you know, find the right avenue, poke holes in things, test them. You know, it's almost like asking those questions or like trying to like prototype something before you've even prototyped it. Um, and then, you know, Don't give up on aspects of the user experience because they're really important and like, don't sacrifice that quality because that's what really differentiates is delivering something that gives customers something that is going to provide that delight that we talked about earlier.
Um,
Host - David DeRemer: Um, I have one more question for you. Um, have you, uh, given all the, the topic of this conversation, have you had any experiences recently, like a, a, an app or digital product, or even like a real world experience where you're like, damn, like, this is really great.
Like [00:34:00] clearly like a really smart team of designers, design technologists, engineers looked at this. Um, anything come to mind of just an example of that?
Guest - Kyle Crouse: well, to toot our own horn, I'm really happy with an internal app that we've been working on around some race data and visualization. And I think that there's been some very smart people on our side that have been putting that together. And I'm really excited to someday be able to kind of generate some content around that to talk about AI and things like that.
Providing better user experiences through, um, you know, more natural inputs and things like that. It's super exciting space, really looking forward to work there. Um, I think if I was going to call out a third party thing, um, I'm I just, uh, picked up, uh, an app called Copilot, uh, like around personal finance, um, management, like, uh, kind of along the lines of like what, you know, Mint and things like that tried to do back in the day, but I think that there's some really elegant design pieces in that, um, that try to simplify a lot of what, uh, makes someone like me that is terrible at it a lot better at managing their own personal finances and things like that.
I think there's a lot of elegance in that. It's in the application and a lot of great functionality um, and it's brought in a lot of, uh, uh, smart capabilities under [00:35:00] the hood. You know, the thing that I really like about it, um, that I try to bring into my work is that, um, you don't often see is that, I think the technology kind of recedes a little bit into the background.
Um, and I think that that's really important because you don't want to like hammer people over the heads with like a technical capability. You kind of just want to like use it to get the job done and be out of there. Right. Like if they never even see the technology, that's great. Um, and I think that this app does a good job of that, of, of, of kind of putting that stuff in the background and really maximizing the value to the user.
Yeah.
Host - David DeRemer: technical. Um, cause I, but I think it's, it is the same idea that we've been talking about here, which is, um, I got this bag recently, just a, you know, a travel bag for my laptop and stuff by this company called air. I might've shown it to you last time we got together and it's like, there's this pocket on the front where you can put like your keys or your, you know, Pack of mints or something like that.
And I took the bag off and I like realized that it was weird to like get to the zipper. And as I'm trying to use this for the first time, there's just a little flap of nylon, just this little flap. And it was like perfect to grab it. So you could have a posing force to open the zipper. And I was like, this is the type of thing, right?
That you need, you need to test with it. You need to see someone [00:36:00] actually use the bag because a designer or a product person would be like, um, you know, Oh, this works. It should work fine. Or maybe like, ah, the engineer would be like, ah, some extra stuff costs more money. Like every little piece we add to this costs a bunch of money, but seeing real user behavior where they probably had a prototype of that and someone struggled to open that zipper and you're like, Oh, we got to add this little, you know, little flap, you know, and I think it doesn't like it's obvious in a physical product.
Um, cause you can like have a visceral reaction. You can observe someone do it, but I think the same things apply whether you're building like a drive through experience or a mobile app or something like that. You need to observe real people and all the myriad ways that people find freaky, bizarre, strange ways to use your product, right?
Um, to react to those and improve the product along the way. So, um,
Guest - Kyle Crouse: Yeah, well, it's an attention to detail that's really important, you know, and it's like you recognize that that there's something there. Um, you don't just skip over it. You, you give it the, the appropriate attention and you put the little extra investment in it to make it, to make it worthwhile. That's the, that's the
Host - David DeRemer: Yeah. And despite all the research we might do, how much we know our business or our company, how much we think we know our end user and our customer. [00:37:00] The reality of it is, is like, we probably don't know them as well as we think we do. And you got to get real people to test it out. So, um, well, Hey man, this is awesome.
Really appreciate you taking some time here today to do this. Um, it's really exciting to think that I get a chance to do this with you after all these years, uh, here we are doing this, um, appreciate you coming on and I'm just really psyched that we get to hang up this call and go back to keep working together.
So that's pretty awesome. Um, all right.
Guest - Kyle Crouse: man. Enjoyed it.
Host - David DeRemer: Yeah, I appreciate it. Thanks very much. Catch you soon.
Guest - Kyle Crouse: Yep. All right. I had to resist the urgeto hang up there.