Loading summary
Transcript55 lines
- [00:02]
A
Welcome back to Insights Unlocked. In this episode, we're joined by design and research leaders from trustage to talk about how they transform UX research from an ad hoc, inconsistent effort into a scalable trusted practice. Embedded directly within their design team. We dig into their cookbook framework, how it changed stakeholder conversations, and what it takes to operationalize research without slowing teams down. Enjoy the show.
- [00:30]
B
Welcome to Insights Unlocked, an original podcast from User Testing where we bring you candid conversations and stories with the thinkers, doers and builders behind some of the most successful digital products and experiences in the world, from concept to execution.
- [00:50]
A
Welcome to the Insights Unlocked podcast. I'm Nathan Isaacs, principal Content marketing manager at UserTesting, and joining us today as host is Natalie Padilla, a research consultant here at UserTesting. Welcome to the show, Natalie.
- [01:04]
C
Hi everyone.
- [01:06]
A
And joining us today from trustage are Benny Brooks, Nick Higbee and Betsy Drews, three design and research leaders who help transform their team's approach to customer insights. TrueStage is a leading provider of insurance investment and technology solutions, helping credit unions and their members achieve financial security through customer centric innovation. Welcome to the show, everyone.
- [01:33]
C
Yeah, really excited to have everyone here. And you know, Nick, I was wondering if you could start us off maybe by introducing yourself, tell us a bit more about truestage and the team's role there.
- [01:44]
D
Oh, sure. So maybe I'll. Maybe I'll start with trustage and then kind of talk about where we fit into it. So True Stage is a insurance and financial services mutual holding company. We're headquartered in Madison, Wisconsin, and our products really run the gamut between B2B, B2B 2C and also B2C. So we have three segments. We have our wealth segment, which is largely characterized by retirement solutions and annuities. We have our commercial segment, which has business protection products and lending protection products. And then we also have our individual segment, which is probably a little bit more understandable, which is auto, home and life insurance. So with regard to True Stage, we recently rebranded two years ago. So as part of a monumental single brand transformation product, we took went from kind of like a house of brands under CUNA Mutual Group, and then we unified as one True Stage. So currently we're kind of going to market as one True Stage, but we're also internally trying to operate as one True Stage and that's where our team fits in. So I lead our enterprise wide user experience and digital design practice, which includes design and research. Right. So from a user experience perspective and user research perspective, we're really kind of tasked with evolving from kind of like a historic resort of cabins into kind of like this new holistic modern hotel experience. Right. So specific to this conversation, we're really changing the way we do UX research. We came from a place in, you know, before the rebrand where we had kind of like separate research teams that the design team would engage with and partner with. And now we're really embedding that use that user research practice like into our design practice. So we went from kind of like engaging with separate teams to understand user needs to doing most of it ourselves. And so now we kind of need to have this practice that supports quick pivots between mindsets where we're either learning to build or building to learn.
- [04:11]
C
That's really helpful context and there's so many moving pieces. Nick, thanks for laying them out. I think what's interesting is that you and the whole trustage team have done such a good job of creating a repeatable high quality research program with shared standards, clearer planning and stronger trust. In the middle of all that and I was wondering maybe Benny, you could introduce yourself and help us set the stage for life before this project where you did all that and why did the team think that change was needed?
- [04:43]
E
Yeah, it's a great question, Natalie. So I'm, I'm Benny Brooks. I'm a UX design lead here and also design lead coach. And also sort of each lead does some other things for the team. So one of my pillars is helping to run and evolve the design operations for our group. So there's going to be, I'm not going to lie, quite a few food industry analogies being thrown around today and I'm just going to start that right away. So previously we were sort of running our research practice a bit like a potluck. So you know, everyone was showing up with their own contributions to the practice, their own like kind of recipes for research activities and insights and everyone was getting to see what everyone else could do. But in the sense of a pot, in the spirit of a potluck, it's like you just get to see this one thing that someone did. Maybe you learn one recipe, but nothing is really shared at a global level and there's no consistency. So that was fun. But we kind of wanted to figure out what we would need to do to stand up the practice more like a Michelin star restaurant. So we wanted it to be tight, consistent for our partners and stakeholders, polished. We wanted to document everyone's skills and abilities so we could learn from each other in a more Consistent way in a more professional way, and still creative. Like, we still want room to play, but just step it up to the next level.
- [06:09]
C
I mean, those food analogies, I think, really bring it to life in such a fun way and helps understand why we dubbed some of these articles that we're going to be seeing. The cookbook, the menu, all of that. I'm curious a little bit. Maybe you could expand on what inspired the framework. Like, how did you evolve, particularly the materials, from the idea of the playbook shared by user testing to what it became?
- [06:36]
E
Yeah, so that sort of happened over a few months. I think we had a research roadmap that was kind of set out for all of 2025, and over the course of 2025, these things kept evolving and changing. So you're absolutely right. We were also working with you. We had these monthly consultation sessions and we were working on a playbook idea. Y' all already had this playbook idea, and you had really good setups for what that should contain. And we were kind of coming in every month and talking about our progress. And I think what really happened is that playbook as a. As a sports metaphor, like, sort of worked until it didn't. Right. So I think what made it not work for us at a certain point in the year is we realized that playbooks are a secret. It's like the team and the coaches get to see that, but you keep it from the other team because it's an advantage. So for us, we needed a metaphor, like a framework to think about this stuff where it was both for ourselves and also at the right level for our audiences. So, like stakeholders and partners especially. So food became a really good way to frame that. And the more we pressure tested these food analogies, the more we were like, yeah, this is like, helpful. So just to run that down quick for you, it's like recipes for the cooks and menu listings for the diners. So they. They both describe a dish, but one tells you how to make it, and then the other tells the diner what they're getting and what the cost to them is. Additionally, that analogy led us later to the idea of, like, tasting menus or meal plans, which are helpful to both sides of the scenario. A tasting menu lets cooks know what each course needs to be and in what order, and then it lets the diners know what to expect for the whole experience. So as we started leaning into that, it was working. And what we ended up building is like these sort of flashcard esque components in figma, which we think of as Menu items, recipes and meal plans. And the set of them was about creating tools to speak to those two different audiences, the cooks or like the doers, the designers and researchers and UX and then the diners who are our stakeholders and our partners on these projects. And so just to kind of like finish the analogy or what that looks like when you take it out of the analogy and you make it real. These cards that we have in the cookbook describe specific research methods primarily. So, for example, we have a recipe card for usability tests, and that tells the UX team everything they need to socialize and plan and execute. And the menu version of that card. So the version we've been showing to stakeholders and partners is actually the same component in figma, but we use variants to turn on and off details. So that just explains the benefits, the required resources, and like the duration of a usability test without overburdening them with everything we need to execute. And then that third. Oh, go ahead, please.
- [09:53]
C
Oh, I was just going to say this is such a great example, but if definitely feel free to expand on it because I, I'm just so excited about it.
- [10:00]
E
Yeah, yeah, I got, I got you. So that third artifact is the, is that meal plan or the tasting menu, which we wouldn't have gotten to without recognizing the other things were separate. Right. So the meal plan is like a set of predefined studies that can be matched to various phases of a product development cycle. And so, for example, we have this program kickoff 1. Program kickoff is like a tasting menu. It includes stakeholder interviews, generative user interviews, and competitive analysis. And what's nice about that is then when a program kicks off, a design lead can just take that off the shelf, make stories in the backlog, get everything set and get things moving with like minimal rework. Trying to like reiterate our practice. Every time something starts up, they just, we just run the play or run the tasting menu in this case. So like a good case study here, just to give some backup for how it worked out, is we did have a situation a few months ago where a lead was asked to skip usability testing because we had the unfortunate situation where stakeholders believed that was going to take too much time, it was going to push off timelines, so we didn't.
- [11:13]
D
Have room for it.
- [11:14]
E
And so we did, we were asked, we pushed back, we did, we were asked. But then once the code was going to demo, a higher up stakeholder started asking for validation. They're like, well, did we validate this? And that was like a Tough spot for a design lead. Right? But because we had this, she was able to pull it, make stories, turned everything around in less than a week. And the quotes on both sides were really good. So our stakeholder came back saying, like, wow, I expect this would be a month before we saw results. And the design lead came back and said, this was very easy, and it. It was nice to be able to pull it into a sprint without having to reiterate everything that I had expected from the research in the story. I'd have to rewrite the whole practice. I just pulled the card and said, do this. And then that worked, and it pivoted and delivered very quickly.
- [12:07]
C
I find what's so compelling about this system is it's easy because it's embedded, it's integrated. And even though you have multiple customers, right. You have your team in some way. They need the artifacts. You have your stakeholders who also have different artifacts. It allowed you to design a process and a system that delivered real results. And I was wondering, Betsy, maybe you could expand a little bit on that, particularly introduce yourself and tell us a little bit maybe, about how the system helped the team to approach research more intentionally and with consistency.
- [12:44]
F
Yeah, for sure. Thanks, Natalie. I'm Betsy Drews. I'm a senior designer on the team, and I've been running UX research on UserTesting.com for, like, eight years or so. And then for this project, I'm also the team's point of contact with usertesting.com Working with Natalie quite a bit and just, like, earning her account. And I just want to say, like, I've always been a big fan of the platform, and then especially this past year with, like, research support, I feel like it's totally helped us focus and stay, like, dedicated to our objectives that much more. So, yeah, just wanted to call out that out as well. But getting into the question about helping us be more intentional and consistent.
- [13:32]
C
The.
- [13:33]
F
First thing that comes to mind is kind of a similar train of thought, how we engage with product teams, just that efficiency and that internal experience through the team trying to quickly spin up research, and then another piece of that. As we know, like in research and design, if stakeholders don't have the opportunity to see behind the scenes how we arrived at a solution, they're more likely to question it. And I think the Cookbook has helped us gain those research advocates quicker and easier, for sure. And one example I want to call it is a couple months ago, like, maybe a little more than that. Over the summer, Benny and I were pitching a research effort. So like kind of what Benny was mentioning added time to a project, which is not everyone's favorite thing. And then we were also with a newly formed product team and this was during a refinement meeting, so it could, it could get a little bit hairy. But because we had the cookbook just like already in Figma at this point and we were running refinement in fig, when our stakeholders had questions about our research approach, we just dropped the cards into our file. We used the program kickoff card, which helped align the group on getting started with a new feature. And then we had our research method cards. And I think it was like five minutes, maybe less, to run through our full research plan. And it removed a lot of effort for us as designers and just like recalling details on the fly and just Benny and I, even just between the two of us speaking the same language with stakeholders can be challenging. So it just like completely removed that. And then when we did that rundown of our research plan using the cards, it's just like the energy changed in the group and it seemed like the team was a little more at ease. You know, you're in good hands. It sparked more discussion and questions, like some immediate buy in which being in UX for quite a while now, like, I just feel like that's such a struggle sometimes. So I think just like the visuals itself, professionalism just like created that buy in. And then by like building that trust with our new effort, Benny and I were able to move into other design goals. We got through the whole refinement just like not having that UX education derail a meeting. The cards prevented that quite a bit. And then I saved a quote from one of our stakeholders from that meeting I wanted to call out. This is when we were walking through some of the method cards. He said, your team was already impressing me with your practice and your skills. The way you just have this all ready to show and explain is beyond my expectations. So just wanted to pull that quote. It's just good to hear stuff like that when you're, when you're with a new group. So just putting that intentional thought into the cookbook and how we wanted to interface with teams, I think it's already paying forward. And that's just one example how the card helped us with that newer team. But we have bigger plans and I think this is where consistency can come into play. And creating that common language that can be so hard to achieve, especially in a big organization. Different product areas, different design leads. Because our material in the cookbook and you were Alluding you were mentioning this too, Natalie, because it's like a visual artifact. I think those are already starting to form a consistency on their own. So as we test the cookbook and the cards across different product areas like we're doing now, I think it'll help just create that common language and then the organization as a whole start to understand our mechanics and like trust the process. Kind of like know what to expect, no surprises.
- [17:38]
C
Yeah, that's. That's such an amazing quote, Betsy. I mean with five minutes to run through the research plan, that is impressive. I can, I can see why it helps you gain quicker Research advocates get that immediate buy in, that sort of trust is invaluable. I think it reminds me, Nick, you mentioned that this resulted in a huge increase in research stories as well. The cookbook, is that right? Is wonder if maybe you could expand on that and, and tell us about what kind of supported that growth as well.
- [18:10]
D
Oh, sure, yeah. From like things that support that growth. So I would say like from the bump. Benny, who, who might downplay himself a little bit, is just our design and research ops master. So like a big part of like setting the foundation here is, is again, we were a UX design team engaging with research teams outside of our team. So what does that look like when that research practice is embedded in that UX practice? So it's no longer just a UX backlog, it's a UX and research backlog. Right. So we use Azure DevOps for agile product development management. And so one of the first things we did was Benny led an exercise to get some research stories in there. Right. So in the past, a lot of our stories in Azure DevOps or ADO as we call it, would be research support stories, so largely characterized by ourselves creating prototypes for someone else to bring into research. Or we would also have research stories for doing evaluative usability tests using usertesting.com so that pretty much were the two types of research stories that we had. So we needed to create a whole bunch of new research stories to include doing our own primary qualitative research and including a bunch of different methods. We have divergent user stories, we have evaluative user store or research stories. So we've got all of these stories which then allow us to measure. Right. So when we first started with this new mandate, our goals were pretty modest, right. So we were really thinking about this in a crawl, walk, run way. So we just were kind of saying to ourselves, we need to be doing more research. That's just the world that we're in right now. So like that was the first thing that we wanted to measure. And like the really cool thing is like when in 2000, in 2024, we created and executed and completed 83 research stories. 2025, when we kind of kicked off this whole thing, we created and executed 201 research stories. So we're essentially doing more than, more than double the amount of research. And I think like, for us, the, like the next horizon, you know, maybe part of like the, like the walk in the run aspect of the crawl walk run is like just the quantity of user stories doesn't really speak to quality and efficiency. Right. So now we're starting to think about, all right, how do we measure like quality and efficiency and just get like better data now that we have confidence that we're just doing more research as part of the new mandate? So the really cool thing is now we are starting to see, you know, when we first started, and I think you heard it all earlier, when we first started, we had a lot of anxiety about hey, we're going to pitch research or we have to like sell research. Right. So that was like a huge concern of ours. But what we're seeing now is we're starting to see research populated on other product leaders back my backlogs that we then need to create a plan for in, in our backlogs and where it's less of a push and like more of a pull. Right. So like we're now we're talking about articulating actors, needs jobs to be done for people who are like asking for it. And that's like a huge thing for us. Right. We, we feel like that's a really good indicator.
- [22:00]
C
I'm really curious with all those different research stories in Azure DevOps, how has this changed the approach that your team takes when collaborating with stakeholders? I imagine, for instance, prioritizing quality insights, for instance, might change expectations on time investments for those insights due to different types of research and wondering if any examples around that maybe stand out.
- [22:25]
D
Yeah, And I'm more saying this for the audience than you, Natalie. As you remember, when we first started talking about this stuff, we were concerned that people were going to have concerns about research and how long it would take and all of that. So we started like anchoring around this goal of like optimizing time to insights and that was a huge concern from the beginning. Right. But as we started to show some success, we realized we got very little pushback. You know, like, I'm lucky that like my boss and leader gives us a ton of latitude to do what we think is the right thing. And then when we were going out, you know, to our internal partners, we weren't getting as much, you know, pushback as we thought that we would. So then, like I had mentioned earlier, we pivoted to, you know, quality, consistency, all of that. So when we look back, it's just like a night and day difference from where we were like a year ago or a year plus ago, because most of our research support stories were simply trying to deliver the right prototype and, you know, for somebody else's research. And this is really like us needing to create a plan, articulate that plan, and then, you know, deliver that plan. So I hope that answers your question.
- [23:44]
C
No, it absolutely answers it. I think you can't underplay also the amount of work that went into this system. To your point, there were new needs really identified along the way and built into this. I was wondering, Benny, maybe maybe you could expand on the operations side a little bit about that. For instance, you know, requesting standard playbook materials and from consulting and then adapting those to your cultures. We talked about that a little bit early on, but would love if you could expand a little bit more on how you got that internal buy in, specifically with adapting standard materials, knowing what materials to get as well to fit those new needs and new use cases, all those new types of stories.
- [24:34]
E
Yeah, that's a really good question, Adalie. I have an example, I think, of this that sort of dances around your question, but I think it does get to the right answer and it's good because it's a specific example. So our. Our user test, research method card or our recipe. So when we, like when we started, we were just building out the first cards we had, we're still figuring out, like, what the scope of it is and how granular they got right. And we had this user test, research method card. And what ended up happening is we split it into three and this is, this is through working with you, I promise this is coming back to your question. So we first started on those cards. There was some aversion to complexity, I think, and making sure that the ops were at the right level was important. Maybe we were too concerned about complexity. I think it's like you got to feel your way into a new system. And so we wanted to start small and then include complexity where it was important.
- [25:42]
A
But.
- [25:42]
E
But I came to one of the consulting sessions and we went through a few rounds of this where we were kind of talking back and forth about how granular we should get, and this is like one of the first ones I remember I asked you about this and you had pulled up three test templates from your playbook. That kind of helped me see the error of our ways. So what happened is we implemented your advice. And what that did is it split our user test card into three separate cards, concept cards, concept tests, comparison tests, and usability tests. And that was a super important pivot because we took that away, kept thinking about it, matching it up to what we needed in our operations, and realized that the combination of the three could represent a repeatable meal plan, actually. And we have that now. And it's called like user test, concept delivery, which is a little bit dry, but that's the study plan. And it lines up concept test, comparison test, usability test, in that order. And that is a direct alignment with our double diamond approach to the product development lifecycle and the design practice. So if we had kept only the one user test recipe, it would have been a simpler system, quantifiably like a smaller system, but we might never have landed or it would have taken us longer to land, I think at this particular study plan card. Once we did that, to speak, to buy in, that was pretty easy, I think, because seeing the full ecosystem of those three cards together and how their relationship is synergistic and answers in a better way, a richer way, like big questions at a certain point or multiple points in the process, that was really hard for anyone to argue with, including ourselves. Once we had it out, we're like, oh, of course, it's this. This is actually more helpful than having it in one. I think the perceived complexity of having the three cards became sort of non issue because it would have been more difficult to continue trying to pile these different things into a single card. And so when we show that, it's kind of like doing a one thing per step model in a web form, right. It's like you think more clicks is a problem or more friction, but actually the goal is to reduce the cognitive load of getting through it. And I think that the full system pulled out of the playbook is actually an easier thing to understand because it makes sense. It's like a full loop. Does that answer your question?
- [28:13]
C
Absolutely. And I do remember that time as well. I feel the same that I think this thought partnership has helped me as well, because we bring different perspectives and build something emergent, layering these ideas and these processes. To your point, the complexity of the system actually can result in a simpler idea for someone to consume. And I kind of want to Pivot on that a little bit. Nick, I was wondering if maybe thinking about the system overall, we've talked a lot about buy in and stakeholders. Maybe we can talk at the level of how has the system empowered true stage designers to grow?
- [28:54]
D
Well, it's huge. So the, you know, as Benny mentioned earlier, when we've got a lot of research experience on the team, so we had a potluck before, right? Everyone kind of brought their experience and historical knowledge and skills to bear for potluck, but it was a really good potluck, right? It was good food. So, so you know, you take, you take Benny with his, you know, design ops chops, you take somebody like Betsy who's got eight plus years of, of doing user research, but the, the tools themselves, you know, and they just seem like, oh, these are cards or visual artifacts. They just really help people, like give people the confidence to get started and get started recommending strategies, right? And then, and then to quickly execute those strategies. So, you know, we're doing more of our UX research now, right? Like that's something that we used to outsource more almost all right. And we can talk about the pros and cons of having design teams and you know, embedded research within design and I think those are pretty well documented out there. But you know, for like the reality of having an external research team is that we would get stalled out like kind of wondering like who, who we're designing for and what they need, right? And it was really normal for us in the past to like have conversations. Which means these conversations mean we're spending company dollars having conversations about whether or not to reach out to a research team, right? Is now the right time to engage this team? And then we would have more conversations about like, oh, what's your availability? When can we, when can we queue up this work? Right? So like these tools given like the new operating model allowed us to just kind of like pivot on a dime and try to like fire up some research, right? So that was huge. The other thing I would say is like, it's one thing like at the beginning of 2025 I probably said this like, hey, now we need to do our own research. We need to do more research, right? So that's like really easy to say, but it's really hard to do, right? So know, we've got people with, you know, master's degrees and HCD on the team, you know, people who are really good at this stuff. But what this allows people to do is like, regardless of how much experience that they have in research. It gives them what they need to get started and kind of either you know, flex some muscles that they hadn't been flexing for a while or for the people with less experience to try a new method. And, and the brilliant part about kind of like these meal plans and like the, you know, the stakeholder facing artifacts, to those people it looks like a practice, right? To those people, they're experiencing our UX research practice and they can kind of, they can kind of learn, try relearn things in like, kind of like a quality controlled way, right. Like where it just appears more professional and gives our stakeholders more confidence.
- [32:05]
C
And I will say I am a fan of a good potluck, but I agree that a well run, a well run restaurant is something else especially for you know, the folks who are working there, who, the folks who are, you know, eating there. And I think it's such a fun metaphor. I just, I want, I, I don't think we can underscore how much confidence the engagement you're mentioning the adoption from the team really aligns to how fun it is. And I think Betsy, you mentioned that the team expressed having fun with this process. I was hoping you could maybe speak to that a little bit more.
- [32:39]
F
It's been such a, like, I don't say like breath of fresh air, but like such a change from the constraints we we adopt and embrace with our design work. It's just we could like the team energy totally built over time, like starting with the research practice. Like this is going to be a big effort but I think having the creative freedom and the democratizing it through the team has just really made it a fun process. Jumping back a little bit at the end of 2024, Nick made a research ops as an objective for 2025 and then another big piece of that, we co created a roadmap which led to all that research production. And the roadmap included scope, things like that of what we thought would fit into the vision we wanted to create for like the practice overall. And then with that vision we wanted to like distribute it through the team, like the ownership of the vision. We're all going to be executing this research, we'll all be picking up stories. So we all wanted to have that opportunity to weigh in on how we approach it. And yeah, that was something that was pretty cool. No constraints, like you have a focus area you're interested in, passionate about, like go for it. And we all had a big portion of this big research pie. So that in itself was super fun to have that Equal ownership. And then I think it also helped us evolve concepts faster. The most memorable point of collaboration, I think, was when we got together to build the first draft of the Cookbook. We had a full day workshop because we all had a hand in that pie on the vision and weighing in. It just like quickly evolved into our first draft and we're like, already working on our second roadmap for this year, but definitely has become like a fun, fun effort.
- [34:29]
C
That's awesome. There's. There's so much great content here, so many great learnings, workshops, approaches, assets. This question is for everyone. What advice would you give to other teams if they're looking to operationalize research in a way that works for them?
- [34:46]
D
Can I take it first?
- [34:47]
C
Absolutely.
- [34:48]
D
Okay. Yeah. So, I mean, I would say, like, lean into your strengths because a huge moment for us is when we just decided to use Figma as kind of grand Central station for this network of tools and resources. Right? So like with the Cookbook in Figma, we can link out to the things we use all the time, like usertesting.com and the other platforms and services and wikis and everything that we have. Um, but, you know, we just made that realization that we're like, we're really good at Figma and we're in here all day every day and why don't we just kind of meet the team where they're at in a tool that they love using. And then we were cooking with gas after that. So that was, that was huge for us. And that might be, you know, I don't know who's listening, but that might be different to whoever else is out there. But the moment we decided to use the tools that we loved and have fun doing things that we were good at, like, that's when we were really able to make this, like, part of our practice.
- [35:52]
C
Throw some fire on there. I love it. Benny. That's me. What about you?
- [35:58]
F
Yeah, I would say, I would agree with that for sure. And then I would, I would say using feedback and insights from the team and Retro. Running Retro on your research operations. Our research retros from last year just really brought to light how we could uncover pain points and different skills we wanted to pursue with support internally. And it's helped shaped our roadmap for this year. So it just kind of generated a new roadmap. What we want to do next. Um, yeah, everyone has like, valuable insight on, on how to make it better.
- [36:43]
C
Huge, huge fan of Retros. I think that's a really great way to use them as well. What about you, Benny?
- [36:49]
E
Yeah, I mean, Nick and Betsy nailed so much of it. I as I have three like bullets. One is like be aspirational about the objectives for the group. I think that like really helped us is like our objectives started at the beginning of 2025. It wasn't like time gated to a one month effort. It was like, hey, whole group, we're going to spend a year doing something really aspirational here. And that creates a certain amount of its own momentum, I think. And then I also think along with that, like not skimping on the philosophical conversations. I know that might seem like we have a lot of work to do all the time and there's always backlogs to hit and there's always deadlines. But a huge part of how this happened is that we didn't skimp on the philosophical conversations. Like we talked about the analogies and that spawned better thought. Like we had more creative ideas about, about what we could do with the ops because we spent time talking about the analogies and the metaphors and like what we were trying to do and what we weren't and leading from that. My third point is kind of what Betsy just said in her previous answer, which is that like getting everyone involved right away, not making decisions about those philosophies ahead and then handing it down or handing it out to the team, but allowing space for the team to like evolve it and everyone's involved and, and having a say in, in how the philosophy or the analogies are working or not working and how the semantics should go. I think that created that energy and that buy in later. So, you know, by the time we got to making the first rev, everyone like really had a stake in it.
- [38:26]
D
Yeah, we, I mean, we did a lot of learning by doing right? So like, you know, we can talk about, talk about these cards as if we send the printer and then these are the cards we'll be using for the next three years. We are evolving and iterating on these in figma. Like we do our designs right. So like giving ourselves the latitude to kind of like just get started and evolve as we go has been huge.
- [38:55]
C
What's great about that iteration is you have that philosophy underlying it so that when you're trying something new and iterating on it, you at least have that shared framework and language by which you can say, should we do it this way or this way? And why and how does that fit into the larger ethos? Which is, it's really very cool to see. I'm sure A lot of folks are going to take some of the learnings here and we'll provide more on that soon. I just want to thank everyone so much for being on the show. I really enjoyed our conversation. How can someone learn more about you, your thought leadership and learn more about True Stage?
- [39:34]
D
Well, that's a great question. We're pretty incognito over here, so we're very heads down. But you can find all of us on LinkedIn and we would love to hear your thoughts and debates with the minimum amount of trolling if possible. Natalie, I don't know if we can use this, but I'd love to to just say thank you so much for like joining us on the wild ride. Right, like with these weirdos from through stage. Join one of your meetings and start talking about restaurants and menus and what's in the kitchen. You. Yes. Anded the heck out of us and it was super helpful.
- [40:13]
E
Yeah, I did feel really supported, Natalie. Like as I was Nick's right. I felt crazy half the time and then you'd be like, nah, this is cool. You should push. I was like, okay, okay, I should push. So yeah, I also appreciate that so much.
- [40:27]
F
Yeah, it's a creative project.
- [40:29]
C
The.
- [40:29]
F
Yes. And it's just like, how far can we push this? Yeah, let's keep going.
- [40:34]
E
Yeah.
- [40:34]
D
And that helped with a ton of the kind of like the self doubt or imposter syndrome that we had trying to grow and build this thing. And it meant something that we had somebody who wasn't inside of our four walls to like give us that support.
- [40:48]
C
So yeah, it can be scary building out a new creative project. But that's, that's what was happening here. And I think it's important to kind of keep the idea generation going and you know, maybe if one iteration doesn't work, it doesn't mean the whole thing is wrong. It's just kind of idea. So I had a lot of fun as well. You can add me to the list of people that had fun in that process.
- [41:08]
E
Nice.
- [41:10]
C
Awesome. Well, all of those links are going to be in the show notes, so thank you everyone for joining and thank you everyone for listening.
- [41:17]
D
Thanks Millier. Thank you so much.
- [41:20]
E
Bye.
- [41:20]
C
Bye.
- [41:21]
B
Want to keep the conversation going? You can find the show notes@usertesting.com podcast if you haven't already. Don't forget to follow us on Apple Podcasts, Spotify, Overcast or Google Play so you never miss an episode. And if you enjoyed today's show, please please share it with a friend or leave us a rating and review on Apple Podcasts. And until next time, this is Insights Unlocked, an original podcast from User Testing.