Editor’s Note: This transcript has been processed using AI transcription and formatting tools. While we strive for accuracy, some errors or misinterpretations may have occurred. For the most accurate information, please refer to the original audio recording above.
Episode Trailer
How do you decide when to do a qualitative research or a quantitative research? It’s the budget of the client decides for me, I wish I had that autonomy to say, uh, one or the other. When you present findings and you have clients that says, well, we already knew this. Okay, if it was known, then why wasn’t action taken to alleviate this concern, this bottleneck, this usability flaw? How do we get to the point where the next time we do this research, it doesn’t exist?
The question of ‘Should designers learn how to code?’ has been an existential point of reflection. Yes, and I think that the answer now is, should designers learn how to prompt? If you’re looking to go against the trend and up-level skills go into qualitative ethnography, user research, extensions of project management and design. We can start to replace a lot of manual processes by using some of these generative tools, and it’s really finding their role and finding their place, and when does it have to have a human in the loop.
Introduction & Guest Overview
Vikas Gupta: Today’s guest is someone who spent over two decades making complex enterprise experience, feel simple and human. Please welcome Nick Cawthon, designer, researcher, strategist, and principal at Go, a consultancy he founded in 2001. Nick helps organization design better internal tools and workflows, especially for technical teams in industries like finance, healthcare, and cybersecurity. Right. Nick also teaches, uh, design strategy and MBA program and build open source tools for researcher. I don’t know how you do it, do it all, Nick. But yeah, really, really glad to have you. Still to have you on the podcast.
Nick Cawthon: Thank you so much. That intro, uh, is intimidating. I, I, I can’t believe, uh, I can’t believe you got it all down it. Um, yeah. It is, uh, a culmination of many, many years.
Vikas Gupta: Right. Two decades. It’s, it’s long, I guess.
Nick Cawthon: Mm-hmm.
Vikas Gupta: So how are you doing today, Nick?
Current Projects and AI Integration
Nick Cawthon: Not too bad. What’s on my list? Um, I’m putting together a course. Um, one of the things that, uh, I have just come off of a contract as, as of, uh, last Friday, uh, and it was with a financial technology firm, uh, based out of New York, and they had not adopted AI tools. Uh, and I’ve found some gaps in their workflow.
Uh, and so my mind is in two places. One is to create a product that will translate legal requirements into SQL statements to create a parser that will have some structure and maintenance and management to the variables and the operators and the, you know, projected values. And try to ease that transition between say, the legal team, uh, and the engineering team by using, um, models, language models.
Uh, and so that would be a summer project. And then the other aspect is to write a course description, as you mentioned, that I teach a MBA program, uh, here in San Francisco. Uh, and to start to redevelop a curriculum. Um, I’ve been teaching mid-career MBA students, uh, on how to use data more statistical and modeling and things like standard deviation and confidence intervals and you know, how to start to look at and process data.
Um, but that’s all changed since we taught last, uh, since last year because of the introduction of generative tools and, um, suites of analysis. And so another summer project is gonna be rewriting this curriculum and, and trying to figure out, um, how to use the new tools in the classroom setting.
AI’s Impact on Education and Design
Vikas Gupta: Oh, great. So basically, I guess everything is changing with the AI, right? The entire curriculum. It’s, it’s tough work, So, but before we get started, uh, Nick, just, just want to understand, because you teach, you’re changing your curriculum. What do you think, how will AI change, uh, like, uh, what are the effects that you see in the education and also in the design industry? But just just before we get started.
Nick Cawthon: Yeah, Vikas that’s a great question. Um, if you were to ask that question 20 years ago, um, it would’ve been around digital transformation where this new suite of Microsoft Office tools was gonna replace pen and paper. Uh, instead of having to write things down and photocopy it and fax it to other people, you could just send an email or put it in a spreadsheet.
Uh, I think that that is the error that is upon us is that we, uh, can start to replace a lot of manual processes, um, by using some of these generative tools. Uh, and it’s really finding their role and finding their place. And when does it have to have a human in the loop, uh, and when can we have trust and confidence that the data coming in is the right?
Uh, so I, I feel as if, um, the next few years is gonna be a second wave of a digital transformation.
Design Process and Research Strategy
Vikas Gupta: And I, and I can feel it, honestly speaking, there’s, there’s a lot of change that is happening, so let’s, let’s get on with it, uh, Nick. Can, can you just walk us through, uh, the typical process, the design process that you follow at Go or you, you’ve been following for last 20 years? Uh, how do you do your research and any strategy that you have?
Nick Cawthon: Yeah. Um, you know, that that hasn’t changed. That first part of your, your descriptor is, is pretty consistent. Uh, and by that I mean, um, doing research, uh, and sort of lining yourself up for strategy. And that is one-to-one, real human conversation, human factors testing, understanding of requirements and analysis, uh, and ensuring that what you design is the right thing. Um, because it’s so easy just to jump into design tools, uh, without kind of clear direction or understanding of what needs are going to be met or jobs to be done, as some people like to say.
Uh, and so that is something that has little change. Now, how we process the transcripts and the unstructured qualitative data that comes out of these conversations has improved greatly. Uh, but that process of, uh, initiation and, um, sort of generative thinking, uh, to go into requirements, uh, both engineering and design requirements is still very human related. So if you’re looking to go against the trend, uh, and uplevel skills that are maybe seen as more strategic, uh, go into qualitative ethnography, user research, um, that kind of, uh, extensions of project management and design.
Um, however, uh, once there is a direction in place, uh, it really has, um, changed. I’ve, I’ve now put down Figma entirely, um, which is something that I didn’t think I’d say six months ago. Um, but I don’t really see a reason to do, uh, I abstractions or interpretations of interfaces when you can just as easily, uh, begin to structure and, and lay out and, uh, coordinated interface using some of these generative tools.
Uh, and that includes, um, you know, bringing in component libraries and system design and design pattern libraries and using those as templates. We’ve been so good at, at, uh, beginning to establish patterns, visual patterns, uh, from a user experience and a design standpoint. And now as we’re seeing uh, that exponential effect of efficiency because these pattern libraries have been around for, you know, five or 10 years now. Um, and so if your tool, your generative tool can train itself on that model, um, creating interfaces can be quite easy. Okay?
Generative Tools and Component Libraries
Vikas Gupta: Right. And, and what do you think, uh, basically spoke about Figma and components and elements, right? Uh, one of, as, one of the, part of the entire, uh, process. Uh, do you think, uh, there, there’s still, I, I was looking at it and I did not find any library that can, uh, kind of merge or, uh, an MCP wherein it moves directly to us or any other, uh, AI tool out there wherein I can just import that element on the Li Figma library and it works seamlessly. Have you, have you figured out something of that sought out yet? Uh, at Go?
Nick Cawthon: Yes. I think that’s the misnomer of, um, some of the stories you might be reading on LinkedIn or Medium of, Hey, I’ve made this timer, or this app, I built it from scratch and it took me 10 minutes. Uh, and I went from zero to one very, very quickly. When you work inside enterprise environments, um, you are long past one, you are now in whatever version or digits, uh, however long the company has been around.
Uh, so there are constraints, uh, that need to be abided by when using these generative tools. Uh, and so that immediately takes out three quarters of the market, um, for lovable or rep or put, put V zero, put these names on lists. Um, and there are many articles that break those down one by one. Um, but there are two core components to, uh, these generative tools when it comes to design.
Uh, one is being able to have a collaborative workspace where multiple designers can work at the same time. Uh, and the second is being able to use an existing code repository from which it can build from. And that those are the, the preconditions is that you need to make sure that you can bring in or clone a repository, uh, and establish guardrails rules to say you do not bring in any external libraries. You do not change package JSON uh, you only use code components. And if you need to create a different code component because of what I’m asking you, you need to stop and ask permission in order to do so and much like you would in a design review process with an enterprise design operation team.
However, you know, that being said, that’s something that is certainly achievable where, uh, tools like Cursor, which I find great success with, uh, have given us an environment where designers, if they know a little bit of version control, uh, and they follow a few best practices with regards to their development environment, uh, and what the algorithm can do and what it should not do, um, make sure you mimic the commenting and code style of the existing repository. Only work within these folders. Uh, don’t go and change things, uh, outside the realm of where the UX, the UI should be authored. Uh, it, it can really be a powerful way to start to conceive of, uh, as well as port in, uh, data.
One thing that I’ve been doing um, is using some of the integrations with things like Google Sheets or MySQL Light, um, where you’re able to use a data structure to assimilate what will be done in an enterprise environment. Google Sheets is easy ’cause it’s so, uh, visible and you can share it out and, and especially as designers are able to see how that data’s being transposed and submitted and, and returned, uh, which mimics the interaction of the web.
Um, that was my main criticisms for some of these design tools is it didn’t feel like a website. It felt like an image map or something that had hot spots that you would click around. And yes, it, it was an abstraction of an interface, but it wasn’t the real interface. Uh, and so that’s, um, something that I would recommend to any designer that’s looking to adopt these generative tools is make sure you bring in the data component as well, even if it’s gonna be not in Google Sheets. Uh, but Snowflake or some enterprise tier database, uh, at least understand how that data is being returned and where you need to have the primary key and transposition and change data because that’s gonna help you learn and understand the flow of information, which the majority of the web is us filling out forms and providing information. It’s not all brochureware.
Vikas Gupta: Got it. So I guess you’re talking about, uh, don’t just make templates out of it, like which applicable templates get the data and see the real time? Right. Yeah. Makes sense.
Nick Cawthon: Yeah.
Vikas Gupta: No, no. And I guess designer have to adopt to it is what I feel. Otherwise they’ll be left behind. Thank you. Thank you for that answer, Nick.
Qualitative vs Quantitative Research Decision-Making
Vikas Gupta: Uh, so moving on, um, you, you do a lot of research is what I know at Go, right? You’ve been doing it for past five years. How do you decide when to do a qualitative research or a quantitative research? Like is there a method? Is there a process you come?
Nick Cawthon: It’s, it’s the budget of the client decides for me, I wish I had that autonomy to say, uh, one or the other. Um, you know, you can get a sense of the maturity of the organization by how much they want to put into research, how much time, uh, how much money, uh, and to what level they want to take that scope on. And it also has to do with, is this an internal tool? And if it is, then qualitative one-on-one conversations before and then after you develop an interface is, is enough. It’s sufficient. Your user base is small enough.
But when you’re starting to define personas or market fit, or you’re doing some analysis on prioritization of features, then that does suggest a quantitative approach where you want to be able to get a sense of numbers from which to draw from, and then hopefully, um, which would be a really, uh, nice scenario for every client. They want to go and find out a little bit more about these numbers of why we’re getting this point of feedback. Uh, and that could be done through qualitative research as well.
Vikas Gupta: Got it. But like, like you mentioned, it’s, it’s basically some, uh, clients majorly, right? Uh, the clients decide what kind of research, but when you are working with a new client, right? How do you assert or how do you tell them like, this is the best approach or, uh, how do you help the clients make that decision? Is there a process to it that?
Nick Cawthon: Yeah, the, um, you know, the, the diagram that I like the most for those of you who like frameworks and, um, structures and systems, uh, is the double diamond. Um, the British Design Council had this sort of, uh, I, I mentioned it earlier, this sort of generative thought, and then synthesis thought, and then generative thought, and then synthesis thought. And as if you can imagine my hands waving wildly, that’s the, the sort of creation of double diamonds.
Uh, and it’s, it’s admitting yet you don’t know. You don’t know what it, it is going to be. Uh, and you’re not limiting yourself to any preconceived possibility about what it should be. Uh, and that’s some. Well, that kind of abstraction is good to show clients because it, it starts with vulnerability of, I don’t really know how to fix this. I, I may not even be sure what the problem is. And if we can give ourselves time and money and, um, and pause and reflection to ask ourselves what’s the best way to solve this problem, rather than tacking on more to something that’s attempting, but failing.
Uh, it, it really goes upstream as we like to say, and becomes a lot more strategic, uh, in how we approach projects and how we, uh, uplevel our clients. You know, as a outside consultant, one of my sort of secondary jobs other than to deliver on time and on budget is to make sure that I up level my direct clients so that they can go within their organization and succeed and get more budget and more projects and things like that.
And so it, it’s not necessarily me delivering us delivering on the thing. It’s often allowing them to evangelize and level within their organization and become more strategic and more directive. Um, and that’s something research can really play a great role is to show that you’ve done the homework. You didn’t, you didn’t just jump to the end. You’ve really sort of backed up and made sure you’re doing the right thing and spending the organization’s money correctly.
Vikas Gupta: Nice. And yes, I, I understand. Double diamond. It’s basically, uh, diverge, converge, diverge, converge is what you’re trying to say. Right. Generate and now. Great.
Nick Cawthon: Yep.
Bridging the Design-Development Gap
Vikas Gupta: So now, now you’ve worked with diverse clients, Nick and, uh, you, you just spoke about, right. How do you do the research and stuff? Any, any, any challenges that you’ve uncovered that, um, that was hurting the customer experience badly. And, uh, you improved it and it changed the course of the entire project, or it gives, um, immense, improved the entire experience, immensely. Small, big. Any instance, any example that you would like to share?
Nick Cawthon: Yeah. Um, I, I’ll go big, uh, and I’ll talk a little bit more about this most recent one, uh, because it’s been pivotal to me. Um, it’s somebody who, again, because I’m coming in from the outside, uh, has license, uh, and permission to do things that aren’t disruptive or innovative that the internal team can’t do. Oftentimes I get brought in as a shadow design team, design and product team where I’m not following under the traditional design organization. Uh, and for companies that are large enough, you know, that can be quite freeing because you’re not having to be wait in line and go through an approval queue and go through the same kind of cycles that the greater enterprise teams have to do, nor are you encumbered by the same tools you’re given license to do, um, whatever you want, as long as you get to the, the deliverable. That’s really the big deal.
And this most recent one, uh, was with a, a, um, a company that hadn’t adopted generative tools. Uh, and everything was being done in Figma. Uh, and I, um, had worked with them in the past and it was a project that took 18 months and at the end of it uh, we had delivered, uh, wire frames, um, and handed it off and said, thanks for a great engagement. Good luck in building this. Uh, I’m sure you’ll do great. And when we came back for the second engagement, about 18 months after that, we saw what had been developed and the delta between what was designed and what was actually built was so vast that the legibility and the user experience and the quality of the product, um, had suffered so greatly because there wasn’t design sort of guiding it along and making compromises and sort of finding out solutions. It was just dropped and, and fairness, it was an internal tool.
You know, the prioritization may not have been there. The, the budget and the resources for developers to, to implement this. It may have been placed at more, uh, crucial parts within their organization. So I’m not blaming or, you know, criticizing in any way. I’m just observing that the last time we worked with them, the deliverables that we produced, uh, did not result in good outcomes.
So, uh, you know, the challenge was on us is that how do we fix that this second pass through? And it was to say, okay, if, if the challenge is that they don’t have, um, the front end resources to do this, um, what we’ll do is we’ll deliver a front end. We disguised it as a prototype where we’ll just call it a testing prototype. However we’re gonna use the same React version, the same tailwind version, the same package JSON. We’re gonna use all the different constraints, all the code components from the client’s, uh, repository that they’re using to build their front end code. And we had access to that because we had gotten a company email address, uh, and access to their GitHub repo.
Uh, and we’re gonna use that as the predecessor for our deliverable, which is gonna be, um, a prototype and a workflow that’s mapped into a Google Sheets database that shows all the logic and the air conditioning and the handling and everything that the front end developer would typically have to do to translate Figma or static design comps into, um into something that was, that was clickable, I’ll say.
Uh, and so that kind of process, uh, was a huge learning experience for me because it helped me align with their front end team to say, do this, not that. Uh, it helped me work with their, um, design team to show them that there are different ways of thinking about making our deliverables and solving our problems. And, uh, that’s where I say we, we started with on our conversation, that’s where my head’s been ever since, is how do I translate this into learning experiences and into curriculum and to, to walk people through some of the refineries of, of that kind of workflow.
Vikas Gupta: Okay, so basically you bridge the gap between what was designed and what was delivered or engineered. Basically, the challenge that we, I guess, most of the designers face, right. And, and you used generative AI basically to build the, uh, click a prototype tool, which, that’s it. And, and I know, which tools did you use? I understand Google Sheets is where you got all the data from and all this stuff, but, uh, which tools did you use to, uh, build it? Any, any, um?
Nick Cawthon: Yeah, we, um, that in fact gap, I’ll go back to the, uh, reflection that you just had. That gap has something that’s been existing for as long as designers have been designing. Uh, the, the question of should designers learn how to code, uh, has been an existential point of reflection for as long as I’ve been pushing pixels around the screen. Uh, and, and I think that the answer now is, should designers learn how to prompt, um, should they be able to figure out what it is they’re trying to convey in a manner that will get them to the end result in their head.
Um, and, um, you know, those tools were all the ones that I just mentioned about Cursor and GitHub and, and Google Sheets. And we tried with the Figma MCP, but it’s really immature. Um, you know, there, we even went into UX pin thinking that UX Pin has plugins or availability to integrate with a GitHub repository, but it’s really a workaround and a hack and it doesn’t go in both directions and you can’t embed one component within the other and on and on and on of like, this is not the right way to focus our energy is trying to retrofit old tools meant for a different workflow into new workflow process.
It’s now, no, let’s stay within the environment of which we’re constrained by. Um, and then try to find prosperity within them. Now that being said uh, and we talked about this from an organizational perspective of we’re trying to bridge the gap between design and development. I think that one of the advantages that development will receive is that they don’t have to, again, interpret the abstract of the design deliverable. Now it’s really about maintenance of code and, and hopefully time saving, um, of, of what they’re seeing being handed over from the product or the UX team.
The opposite needs to be true where designers are going to mess things up because this isn’t our core competency is understanding how to, um, resolve merge conflicts or, uh, rebasing branches or these sort of version control 101 that designers aren’t, uh, familiar with, um, natively, and to say, look, we’re gonna borrow some of this development time, which typically comes down this product development cycle, and we need somebody to shadow us for a couple hours a week to help us untangle and fix and do things like that. But, you know, we’ll put these guardrails in place so we don’t mess up too much. But there will be occurrences or occasions in which we will cross the streams, uh, and need a ghostbuster to, uh, to really help us stay productive.
Future of Design and Engineering Roles
Vikas Gupta: Got it. I, I don’t know whether, should I ask this question right now because I had this question in the later, but because we are discussing about genetic AI so much, what do you think, um, a, a role of a designer or an engineer, how’s, how’s, uh, that gonna shape up after this entire this thing? Like you mentioned, right? Um, it’s, it’s been a constant, or since last two years. It’s like when you, since when you’re pushing pixels, the designer, the end outcome is not the same. Right. Now, there is a chance for designers to obviously pick up and deliver something, which is exactly as design. So what, what do you think, where is the industry going with all these changes?
Nick Cawthon: Yeah, uh, depending upon your LinkedIn algorithm, you will get existential questions like, is engineering dead? Is coding dead? Uh, and mine says, is design dead? Is Figma dead? Are we, are we sort of making ourselves obsolete? And I’ll, I’ll go back to that metaphor of the second digital transformation, uh, that I mentioned earlier, is that are we, uh, sort of echoing these same sentiments from 20 years ago where like, have we just taken away the secretary’s job who used to type up emails and hand them to the boss, uh, because they didn’t want to read, uh, words on a screen? Like, are we making jobs obsolete?
Uh, and I don’t think, uh, any of that is true. I, I think that we’re just sort of changing our need, uh, to focus our skill sets. Uh, we’re sort of creating, uh, an impetus for us to uplevel our understanding of how to do things. Uh, ed it really is something that, you know, requires a curiosity. Um, it, my knee-jerk reaction was this big eye roll of AI. Oh, I hear this every six months here in San Francisco. There is just a latest buzz phrase between blockchain web 2.0 NFT, on and on and on and on, uh, billboards. So you go chrome across the bridge into San Francisco and there are billboards all using the same buzzwords at any given time. And you know what the buzzword is because there are 10 billboards left and right of you all saying the same thing about some startup and some product that’s trying to receive some amount of funding because they’re using this buzzword.
And my, my reaction with with AI has been the same up until the point where it starts to be so evident of how it can be used across multiple people’s workflows. Um, whether it be financial services to, you know, what, what we’re grappling with in education teachers using AI and students using AI, and how do our algorithms talk to one another? Or when do we, you know, take it away? You know, I think that the, um, the ubiquity of, uh, generative tools, uh, is gonna be something that is really, uh, fascinating, um, as it occurs over the next weeks and months.
Industry-Specific UX Misconceptions
Vikas Gupta: No. Makes sense. And I guess, I guess you’re right, uh, the LinkedIn algorithm, uh, does play on your mind if, if you, if you, if you’re not following direct people. Okay. So you spoke about like, uh, different industries, right? So my next question is around industries. You work with various industries like finance, healthcare, education. What do clients in those industries usually underestimate about UX? Like what do they don’t know? What do they talk about?
Nick Cawthon: Yeah. Um, I think what if I’ll, I’ll go back to that earlier story, uh, that I mentioned, um, about the client where here’s the deliverable and good luck and our contract has ended, our job has done, we’ve, we’ve met the requirement. Um, you know, I would’ve rather had seen a, uh, sort of a maintenance agreement where at the end of that 12 or 15 months, there was just a, you know, five hours a week of, um, hey, checking in and give us some, um, conflict resolution or some alternatives when we figure out that we can’t get this data store here to present this table there, uh, and give us some workarounds because if we sort of cut the architect out of the loop, uh, and allow the engineer to build the building.
Uh, but all of a sudden one of the, you know, anticipations of, of how this building was gonna be constructed, needs to be accommodated for, and the architect is gone, then you get angles that are weird or, um, you know, stairways to nowhere or things like that. Um, so I think that that might be a misconception of UX is that it’s a, a deliverable more than anything else.
So there is, um, this probably is a more prescient answer to your question and I’ll, I’ll try it a second time, is that a lot of UX or design as a whole is really, can be seen as somebody to help make decisions where you’re trying to be a neutral party between the products team and the engineering team and stakeholders and end users, and that you are as a sort of experience advocate, you are trying to negotiate where that compromise will be and authoring illustrating solutions of how you might, um, embody that compromise.
And so when you take that negotiator out of the loop, the power play becomes a lot different. Um, so that misconception of, of it’s, it’s a deliverable, and when the deliverables done, they can walk away. Uh, I think it, it, it behooves companies to sort of stay with the long tail, um, of, of UX consultancies. But again, I’m, I’m an, uh, a third party, I’m an outside influence and, um, you know, that, that can be hard to maintain from a contract perspective of somebody that just sticks around.
Vikas Gupta: No, I completely agree. I guess, uh, estimates it like it’s, it’s just a one piece in the entire puzzle, but design is not one piece is what, what I believe. Definitely. It’s, it’s like a complete. Uh, it’s part of every piece in the puzzle is what I feel like you mentioned, uh, basically, right. Someone needs to be there to negotiate what needs to be, uh, done or what. Yeah, no, completely say, completely agree to that.
Research Misconceptions and Setting Expectations
Vikas Gupta: So tell me what, Nick, now you talked about basically the under, uh, we talked about the underestimation, right? Wherein people think it’s just a deliverable. What, what are the, uh, misconception that, uh, the customers have right before, uh, you start any, uh, research for them? Right? And how do you kind of set early expectation on this misconception? Like if I have to give an example, uh, if I am working on an application at VWO right? I sometimes get from the product managers, like, let’s just, uh, go out and do interviews wherein that interviews might not be required for that project at all. Right? So I, I believe there are some misconception that are, uh, wrong processes that you might also be receiving from the clients? Like, do this for us. How do, how do you reset those expectation or?
Nick Cawthon: Yeah. Yeah, that’s a tough question. Um, you know, there, and because each scenario is different, the one you just described, um, it may be perfectly valid of we don’t need to do interviews for something this small or this trivial. There’s also this, um, artifact of when you present, uh, findings and you have clients that says, well, we already knew this. And then the question becomes, okay, if it was a known, then why wasn’t action taken to alleviate this concern, this bottleneck, this usability flaw? How do we get to the point where the next time we do this research it doesn’t exist?
Uh, and so there, it, it again, I mentioned vulnerability earlier of when you are dealing with clients or stakeholders, is there a desire to put them in a place of vulnerability? You know, I do a lot of like internal process reviews where I’m talking with people within the department or within the organization, uh, interviewing about current state, clipping together sound bites that describe the current landscape. And oftentimes critical because they’re frustrated and things aren’t working well. And if they were, I wouldn’t be there.
Uh, and so we’re using this human voice or these human emotions to try to get the stakeholders to a point of vulnerability to say, this is why things are broken, and how do we fix it? Um. And so it, I guess it’s, you know, to have a roundabout way of answering your question. I, I guess that it’s not necessarily about the unstructured qualitative data that you’re returning. You’re not doing interviews just from a transactional standpoint. You’re trying to get these participants to a place of emotion, and I think emotion can drive change a lot better than just C nine out of 10 said that word. Well, we already knew what that word was. It’s really more the stories and the frustrations behind, um, what that topic or that subject area was. So, um, very soft answer to, to, uh, an ambiguous question. But, but I hope it, it satisfied.
Handling Diverse User Feedback
Vikas Gupta: No. Definitely makes, and what do you think, you, you do a lot of interviews and it’s, it’s a bit off topic, Nick, but you do a lot of interviews or research, right? Uh, there are instances wherein one customer, just out of 10 or 20 interviews that you did, one customer said completely different thing, but it completely makes sense. How do, how do you take that particular feedback from?
Nick Cawthon: Uh, that’s great. That’s great. I, I it’s better when they say different things. I mean, provided you’ve got your recruitment structure right, and you know that you’re still talking to relevant users of the product or, um, sort of those who are going through the same experience. Um, I, I really think that is, is a, a, a really a gold mine when you can find a diversity and opinion.
Um, because again, they’re bringing different perspectives and the different goals and jobs to be done into whatever we’re trying to design for. Uh, and to be able to see and accommodate differences as well as similarities. Uh, it is, is a wonderful scenario to take place because now you’re not just serving one person, you’re serving multiple people. And what better responsibility is to facilitate different use cases and scenarios around that.
Um, you know, we’re starting to go into personas and sort of archetypes of users and, uh, those that are, are really trying to facilitate some task through a, a product. Um, and so maybe that’s where you go back and say, okay, may, maybe we didn’t think about our typical user like this. Maybe that there are these variances or these, uh, deviations from how we thought this was going to be used. Um, that’s a, again, that’s a good thing because it, if it has this shared utility, uh, outside of one use case or one experience case, uh, then that is something that, um, sort of shows that it has universality. Uh, and, and I would imagine that would be a net positive.
Vikas Gupta: That makes sense. And, and just just out of curiosity, how do you convince the client that, okay, you’ve just got one user who said this? And convince them, uh, why should we take one user’s feedbacks and change the entire thing or change, uh, some things in the flow or whatever, uh, the design that we are doing?
Nick Cawthon: Yeah. How do you not overreact? I think is a, a good question is how do you not, if you only have the budget to talk to five people, uh, how do you not overreact based upon that? Um, and maybe that’s going back into the quantitative where you say, you know, we just took this small sample size and we see that there’s this tier or this industry, uh, or this sort of seniority level that’s using our product. And this is just one small segment, uh, of our greater base. So let’s always sort of look at this with a grain of salt.
Um, sorry, that’s a, a phrase. Let’s use this, let’s look at this with a, uh, a limited perspective or let’s not overreact, uh, and think that this is something that, um, is for all users. Uh, but let’s contextualize those that are saying this, uh, in proportion to the greater user base. Um, and those are, uh, then those are quant skills, um, just as well as, as qual. And so I think that a good researcher should always have the balance between, uh, not, uh, jumping in because of emotion.
Um, but always sort of being able to look at the data and then the opposite’s true. I’ve just sort of come off of a project where there’s this wonderful data set and all of these sort of long-term longitudinal studies, seeing multiple, uh, hundreds of participants over the course of years and what the effect has on their life. But what it’s really missing is the emotional, is the qualitative. It’s the stories that come out of that data.
Uh, and so when you have the scenario in which you described, you have a very small sample of qualitative data, uh, what you can do is try to switch it and say, let’s take a inquiry into what context as the greater proportion of a user base these statements are coming from, so as not to overreact. And again, the opposite being true is that if you have data rich environments, make sure you pull out those emotional human stories, those narratives, so that it, it does more, more likely compel change.
Adapting to Organizational Maturity
Vikas Gupta: Yeah, no. Makes sense. I guess I’ll, I will try and use that myself as well, but thank you. Uh, now you, you do a lot of research and you work with a lot of companies. You’ve worked with fortune hundred companies as well, Nick is what I understand. Right. And different organizations have different maturity levels, right. Uh, in terms of their design and research. How do you adapt to, uh, your process, uh, design and research process, depending on the organization’s maturity? Is there a change in that or is it consistent across?
Nick Cawthon: Yeah. Um, I’ll, I’ll reverse the question a little bit. Um, I work in this sort of motion picture model of, based upon the project, we staff it differently, where if there is a mixed methods, um, in home, uh, project across the United States uh, I will go and find ethnographers that have that kind of background, uh, and that expertise, uh, to do multi-region, um, face-to-face, one-to-one interviews, uh, in that area.
Um, and the opposite’s true. If there are, uh, international studies, uh, that require, um, language translation and mobile survey apps and, uh, you know, ethnography in, in different subcultures, uh, in each of those cities, I will find teams to go and execute, execute, execute, as well as manage and maintain, um, on the application side of things. And, um, you know, that that is the reversing of, you know, how do you find or change or adapt. Uh, it’s really letting those professionals that are really good at doing that one thing start to change or adapt you where your process starts to change because you’re seeing what they’re doing.
I had initially come into user research thinking it was just being able to be a good conversationalist. It was just being able to get the person to talk, and it didn’t matter what the content was, but it wasn’t until I had, um, worked with and met and, and collaborated with a trained qualitative researcher, a principal investigator, an ethnographer that could go in with a structure or an idea of the conversation in mind and gently guide their participants to really make sure that structure was followed, uh, and do so in a manner that ma looked at the clock and knew how much time they had that made sure that the question that they asked were answered, but wasn’t transactional to the point where you’re just getting yes or no answers to questions that needed that kind of expansion and justification and context and reasoning as to why.
And so that flexibility of being able to work with a number of different people to staff the right people for the right project and then to grow and adopt their skill sets into your process, uh, has been something that I, I’ve been tried to have been flexible with, uh, throughout my career.
Vikas Gupta: Right, and, and does it change basis, the maturity of an organization, the process that you follow?
Nick Cawthon: Yeah, yeah. Some know exactly what they’re looking for, especially the consumer focused ones that know what customer research and market research means and how to start to position marketing or product cycles based upon that initial research. Um, if they’re working at a scale, uh, where you can have that kind of impact of tens of millions of users or consumers they know to be more strategic about the research process before jumping into execution of an idea.
Gaining C-Level Buy-in
Vikas Gupta: Got it. That makes sense. Um, now your work, I guess, uh, let’s, you work with a lot of C-level stakeholders as well, right? Uh, is what I understand. And they are often focused on growth efficiency or risk reduction. Right. How do you connect value of research or design, uh, to their priorities and what’s worked best when gaining buy in that debt level because getting buy-in for design and research, uh, is extremely difficult?
Nick Cawthon: Yeah, I, you know, the analogy is like a, we have a fish called a salmon. Uh, I don’t know if there are salmon in your part of the world, but here, the salmon, they go from the ocean into the deltas upstreams towards the mountains, and they find a protected pool where they lay eggs. Uh, and then they come back the next season and the eggs have hatched. Uh, that’s a nice, nice way of describing it. I’m not sure if it’s, it’s actually correct, but, uh, we’ll go with it for, for this morning’s conversation.
Uh, and the analogy that we use is like a salmon, um, swimming upstream. If, as you mentioned, these C-levels that have the huge budgets, uh, and are responsible for growth, um, think that they’re just able to jump to that end pool, uh, it, they’re very quickly gonna get washed back down again. Uh, and these salmon, I neglected to say, they jumped from pool to pool up the river. And so that’s where the bears will, will bite them out of the air because they’re leaping to try to find that protected, uh, eddy, for which their eggs can be laid.
And that analogy is that if you make these errors and you go too quickly, the salmon gets washed down again, and growth doesn’t occur, the numbers don’t improve because you’ve launched something that nobody accepted or that wasn’t tested. So the, the prudent and judicious and the strategic C levels know that the user centered research and design process means that you as the salmon, you go hop, hop, hop, hop. And if you skip over any of those parts, the likelihood of you getting washed down and starting over again and, uh, you know, uh, encumbering your growth, uh, will increase. And so it’s better to do it from a more, um, methodical perspective rather than just let’s get to the end and cut to the chase and jump right into something that we don’t quite know enough about.
Vikas Gupta: No. Makes sense. I, I’ll, I’ll, I’ll sit down with that analogy and I’ll think about it in more detail, but Yeah. Makes sense.
Nick Cawthon: Because don’t, don’t get washed downstream. You want to be methodical about how you’re about to lay eggs.
Teaching Data Storytelling
Vikas Gupta: No, I, I’ll definitely try because I, I, I deal with the C levels. I, I kind of understand what you’re trying to say, but yeah, moving on. And I guess, um, I asked a lot about research and, uh, your design process. Thank you for answering those. Now, just, just a question about you teach, right? Uh, and you teach the newer generation that is coming in, right? So you teach data narratives and design strategy MBA program. How do you teach future experts to move beyond their dashboards and tell a clear, actionable story with their data and how client is data storytelling, especially with the evolving role of data analytics in driving business outcomes?
Nick Cawthon: Yeah. Uh, I mean, you said it yourself is that you go beyond the dashboards and get to those clear stories. And we’ve covered that, uh, quite a bit in our conversation already, is the importance of balancing mixed methods qual and quant, uh, so that you’re able to pull out those anomalies, those factoids or those outliers. Uh, and try to understand the why.
Um, there’s also the notion of being able to process and analyze statistical information in a way that, you know, what the data is showing, kind of, you know, the disbursement or, you know, the, the segmentation of data and can begin to work from there to, you know, create personas as though we’ve run this through, um, you know, a factor analysis and seen that there are these segments that are arising in our data. So how do we begin to use those to, uh, yeah, as we’ve described, uh, define personas, uh, and what needs does this segment have versus this segment? Uh, and so those basic core competencies of statistical analysis and how it relates into a user focused cycle, uh, is something that we’ve been trying to lean into.
Um, to bearing degrees of effect, um, as well as to just basic, uh, getting your hands on data. Um, that was something I always struggled with early in my career is I wanted to do these cool visualizations, but I could never get my hands on real world data. And I mentor a UC Berkeley program, uh, of undergraduates of data scientists, and that’s all they wanna do is just give us something to work with.
Um, and so I think, you know, the, what we can come up with is well go and launch a survey. It doesn’t cost much money at all, uh, and generate your own data sets. And let’s get some participants in this. And let’s try to see, uh, how we can begin to define something, uh, or go. And let’s, let’s go through some scraping algorithms, uh, and let’s scrape data and make our own data set based upon two very disparate and separate sets of data. Uh, and then from there we can, um we can start to make assumptions on, on, uh, our hypothesis or our investigation and bring out the stories from there.
Uh, and so that kind of just utility of not thinking subjectively, um, might be, uh, a good way to encapsulate it. You know, if we’re, you know, designing things for the sake of making pretty pictures or pretty, um, you know, pretty visualizations we need to make sure we understand the underlying of it, um, and the data itself.
Vikas Gupta: No. Completely makes sense. Uh, Nick, and then yeah, you’ve, you’ve summed it up pretty nicely.
Nick Cawthon: Data pretty nicely.
AI’s Impact on Design Workflows
Vikas Gupta: Okay. Um, I guess the last question, I guess, I know we’ve spoken about it, but AI is something which I believe is difficult to leave behind. Uh, we’ve spoke about, spoken about how designers should use AI, but what are the changes in the workflow for a designer right, that you think will be coming in with the use of AI? Right. So currently it used to be like you used to get a PRD from the product managers, so you used to have discussions, then you used to do wire frames and stuff like that. Right. Do you see any changes in the workflow that, that are gonna come? Um, going ahead?
Nick Cawthon: Yeah. Yeah, I talked about many of them. Um, I think that the plugins are really immature right now to try to bridge the gap between, uh, generative tools and design tools. I think that there’s, there’s gonna be a need to just to dive in head first, uh, and see what kind of mistakes you’re gonna make. Um, a change in the workflow would be you’re not just gonna hand something over in Slack, uh, and pass it over to developers and say, good luck. Here it is.
Um, it, it’s something that developers should be brought into the conversation earlier to, again, to be guides. Uh, and to help us, um, uh, underwrite the errors of which, uh, we will most definitely write. Um, you know, I, I think as well, uh, just as when I see product managers, uh, use, uh, generative tools to try to, uh, make bullet points and PRDs, um, it, it doesn’t go very well. Uh, it, it may give them some lateral thinking to see or to cite use cases or scenarios they may not have thought of.
Um, but to think that that’s gonna be their deliverable is a, um, generated, um, PRD that hasn’t been either edited or authored by a human being because that’s who we’re designing for our human beings, oftentimes, um, that, uh, that’s something that’s not quite mature enough that it can pass muster.
Um there’s also this, I, I find myself within these cursor prompts, um, actually writing what feels like a PRD. Um, I find that talking to the algorithm, uh, in a sense of, um, requirement for the sake of a third party, meaning the user is a good way to, um, start the conversation where we’re not talking about the application, it should do, this button should do that, but we’re instead talking about the user. The user would like to switch the lights on. So how would the user do that? And the application will say, oh, we’ll do a button and the the button will switch the lights on.
Um, and that, that’s kind of an interesting way of looking at it, is to really have it be, um, something that is, is user focused. Even it in its definition of not only the PRD, which is fairly commonplace, but also the generation of the chat with the algorithm that’s going to suggest the application.
Vikas Gupta: That makes sense. Okay. Yeah, that definitely makes sense Nick. So can, can you just elaborate, I know, um, I’ve been talking a lot, but can you just elaborate about the last sentence that you said wherein, uh, you, uh, the switchboard thing? Right. I just, uh, if you can lead, uh, elaborate a bit on that, that that’s?
Nick Cawthon: Sure, sure. So, uh, you know, we’ve been trained as designers to, uh, try to define the UI.
Vikas Gupta: Right.
Nick Cawthon: And I think what is more helpful and more efficient I is that instead of trying to define the UI, we define the UX where we do not say, uh, I put a button to turn the light switch on.
Vikas Gupta: Got it.
Nick Cawthon: We speak to the algorithm in a third party to say the user will come into a room and needs to turn the light on, and then the algorithm will know, in order to meet this product requirement, what I need to do, what it needs to do is to place a button, uh, in this place. And so you’re giving it that room to interpret. And there’s actually, there’s a, a oftentimes, my points of joy and delight from using these tools is seeing things that it’s come up with that I didn’t think of, and to think, well, maybe that this algorithm’s gonna do a slider, or maybe this algorithm is gonna do sort of mouse over or something. A motion detector, like, why do you need a switch when the, the, the room should know that there’s a person in it and the light turns on.
Um, if those are, are some moments of joy that I’m still having on a daily basis, but in order to get there, you need to allow the room for interpretation, uh, and the algorithm, the ability to play with all of those guardrails, uh, and, and constraints built in so it doesn’t, uh, break the repo or, or take over the world.
Vikas Gupta: No. Completely makes sense. And, and I’m also very honestly, uh, the way you’ve just structured the entire thing, you are making it more, um, open-ended and at the same time, um, not putting it in a box. Right. Do this for me rather. I want, uh, the user wants to, wants light in the room, and how do you do that? Right. I guess. Yeah. That makes sense. Nick, thank you. Thank you for answering that and elaborating that. Okay. Any, any final thoughts, Nick, uh, before we call it up?
Nick Cawthon: No Vikas. Thank you for having me. It’s been a great conversation.
Rapid Fire Round
Vikas Gupta: Okay. Uh, but we’ll not let you go, uh, go like this. We have some rapid fire questions for you, uh, before we move on. Right. Um, and let’s, and please, please answer them as quickly as you can.
Nick Cawthon: I’m ready.
Quick Questions & Answers
Vikas Gupta: Okay. So if we, if you were to, uh, start a career in design today, what is the one thing that you would definitely do?
Nick Cawthon: You would, uh, I would understand JavaScript better. Um, yeah. I, we didn’t, when that came out, uh, early two thousands, uh, it was supposed to be this sort of castaway language, Java script. It was sort of a, a, a distant cousin of Java. And we weren’t learning Java as, as, uh, as designers. Believe me, I tried, uh, but JavaScript was never ever, at least in my, my loose knowledge of engineering, uh, seemed to be the language that was gonna stick around, uh, and become so crucially important. Um, and that’s most of what this, uh, you know, this generate generative tools are, are authoring. Um, and so yes, to rapidly answer that question of, I would, um, I would learn JavaScript.
Vikas Gupta: Okay. I have a follow up question, which I’ll ask in the end. Uh, a newsletter that every UI UX, uh, designer must follow?
Nick Cawthon: Who, uh, the Merhol agenda, uh, the Merh, M-E-R-H-O-L-Z, uh, he was one of the organizational leaders of design and its role within organizations, uh, Peter Merhol. Um, so find the Merhol agenda, uh, a good newsletter that talks about where design falls within organizations.
Vikas Gupta: Got it. Um, three books that you would recommend our listeners?
Nick Cawthon: Uh, Mapping Experiences by Jim Kalbach. Uh, it’s an O’Reilly book, uh, I’m just looking at my bookshelf right here. Um, Design Beyond Devices, uh, by Cheryl Platz, uh, and Surveys That Work, uh, by Caroline Jarrett. Uh, those last two are Rosenfeld. Uh, those are very practitioner books. Um, but as we talked about collecting quantitative data through surveys, uh, as we talked about mapping experiences to try to understand the journeys and the jobs to be done. Uh, and then lastly, these sort of design patterns and these systems of which we’re going to use as our pallet, uh, from which to paint from.
Vikas Gupta: No. Extremely useful. Thank you. Uh, what’s your go-to travel destination?
Nick Cawthon: My go-to travel destination, uh, out of the city somewhere, uh, to try to calm things down a little bit. Uh, anything along the coast, uh, towards the ocean, um, is always very soothing, uh, and oftentimes cooler, uh, in the summertime. Um, so I, I am fortunate enough to be, uh, on the shores of the Pacific Ocean here in California. Uh, and when I need to go to someplace out of here, uh, it’s always, uh, as west as my dry feet will allow.
Vikas Gupta: Got it. Um, the next one again is AI. I guess. So one thing that AI will replace in next three years. Okay. Let’s, let’s take it one year, I guess I, I, because I believe the, the pace that it is moving in one year, three year. What do you think, what’s gonna change or replace what will be replaced by AI?
Nick Cawthon: Yeah. Um, let’s, yeah. Uh, it’s like travel agents, you know, have travel agents gone away or are they more niche now? Um, because you could book everything on the internet, right? You could, you don’t need somebody to book your airline or your bus ticket or your train station that’s just click, click, click and done. But there’s still a very large industry of travel agents who know the right things. I’d like to think that we are all becoming travel agents. We may not be booking the airlines anymore, uh, for our clients, but we are letting them know that you want to, going back to your earlier question, you want to go to this destination and go to this restaurant and make sure you see these things because it’s just to, just because you can get there doesn’t mean you can experience it. Uh, and so I will give you a very, um, metaphorical answer of, um maybe not replacing, but certainly making more niche, uh, our roles as designers and engineers.
Vikas Gupta: That’s, that’s a great way to look at it, Nick. So it’s major, it’s transformation rather than replacement is what you?
Nick Cawthon: Mm-hmm. Yes.
Vikas Gupta: Okay. Uh, if not design or UX researcher, what other profession you would’ve chosen?
Nick Cawthon: You know, I’ve asked this question myself. I’ve been on podcasts and I’ve asked others, uh, hosts, uh, if you were, let’s continue with this travel metaphor down the coast, somewhere where there wasn’t technology and there wasn’t, uh, these jobs, these tech jobs, uh, and you found yourself in a small town, what would be your profession? Uh, and my answer that I like to give is that I would open a store for picture framing, uh, for those of you who may be able to not see the video, uh, over my shoulder as a, you know uh, lithograph. Uh, and those skills of balance and color and hierarchy and proportion would come become beneficial, uh, when dealing with picture framing. Uh, and so if not UX, it would definitely be a visual medium, uh, that I could leverage those same skills.
Vikas Gupta: No, with the way you’ve been telling stories, I, i definitely feel you could be a great storyteller. Uh, Nick, honestly speaking.
Nick Cawthon: Why Thank you.
Vikas Gupta: Uh, one UX metric that you wish people would stop, observe, obsessing over?
Nick Cawthon: Uh, NPS scores.
Vikas Gupta: NPS course. Uh, I can’t agree more. Can’t agree more. A dream or goal you want to achieve in the next three years?
Nick Cawthon: Dream or goal in the next three years? Uh, I want to, uh, offer an online course. I want to, uh not just in-person courses here, which is odd because in COVID all I wanted to do was get back to in-person courses. And now that we’re past COVID, I want to be able to sort of standardize and templatize, um, my versions of, of in-person courses. So, uh, the tables have turned because?
Vikas Gupta: Okay. And then why is that? And just a out of curiosity.
Nick Cawthon: I, it goes back to your question about, um, retraining, um, where I think that design teams, especially design leaders, are under threat. Um, because now all of a sudden, or soon they will find their design and maybe engineering as well um, resources get called into question, um, budget and staffing. Uh, and because of that, um, they’ll need to be able to adopt these new tools and these new workflows. Uh, but who’s gonna teach ’em? Uh, and so as we focus on enterprise environments and design teams, I think somebody needs to come in and say, Hey, here’s how you go from a requirement into code that can be integrated to whichever, uh, code stack or tech stack that you might have at, at your company. So that’s a goal, is to be able to retrain.
Vikas Gupta: Got it. No. Makes sense. Okay. I am done with all my questions, but as I mentioned after I asked my first question, and you talked about JavaScript, so there’s, there’s always a buzz in the industry about full stack designers or developers, right. What you think, because you talked about JavaScript and you talked about code so much, I just wanna understand, what is your take on a full stack designer or a full stack developer? Should a designer learn coding or not?
Nick Cawthon: Um, yeah. Um, we use that metaphor of, uh, architect. It is like, you know, should an architect understand building materials. And I believe that if you go to a school of architecture your first year at university, you will have to understand, uh, the tensile strength of concrete versus, uh, I don’t know what, what the equivalent to concrete, but let’s say silicone. Um, that you need to understand the constraints of which you are designing in.
Uh, and it’s too easy to say, well, they’re just pixels of light on the screen. And, uh, you know, if I can put that button there, that’s all that’s, that’s needed. Uh, that I think is a misnomer. I go back to curiosity a lot, um, is the curiosity of these frameworks that engineers use. Uh, the curiosity of, um, the implementa implications of going to and from database calls or the routing of API queries, those aren’t things that designers typically learn or care about, uh, when they’re at their practitioner schools are taking their courses, but it certainly makes them better designers to know that they can work within a context of development.
Uh, so yeah, absolutely. There are some designers that, you know, leave that to other people, uh, creative directors that can say, Hey, here’s a vibe I’m going for, and can you make it real or realer for me? Uh, but the more that you know and understand the context of, um, of what you’re designing for or developing for, um, that the better off your deliverable will be.
Vikas Gupta: No. Makes sense. So basically knowing what is, what are you designing and developing for at least, at least the basics of it is what I understand is what you’re trying to say. No, makes sense.
Nick Cawthon: Yes, sir.
Closing Remarks
Vikas Gupta: Yep. Thank you, Nick. Thank you for answering all my questions patiently.
Nick Cawthon: We’re right on time.
