Pavel Samsonov is a design architect and UX Practice Lead at Amazon Web Services (AWS) based in New York City. With a background in graphic design and a passion for human-computer interaction, Pavel has spent the last three years at AWS helping large companies adopt cloud computing and build innovative products using design methods. His professional accomplishments include being named a top UX designer by prominent industry publications, and his work has been featured in major design exhibitions and conferences worldwide. In addition to his work at AWS, Pavel is also a contributor to UX Collective, a prominent online publication in the design community.
Check out the video here: https://youtu.be/XmCY_oSmL4U
Pavel Samsonov is a design architect and UX Practice Lead at Amazon Web Services (AWS) based in New York City. With a background in graphic design and a passion for human-computer interaction, Pavel has spent the last three years at AWS helping large companies adopt cloud computing and build innovative products using design methods. His professional accomplishments include being named a top UX designer by prominent industry publications, and his work has been featured in major design exhibitions and conferences worldwide. In addition to his work at AWS, Pavel is also a contributor to UX Collective, a prominent online publication in the design community.
Check out the video here: https://youtu.be/XmCY_oSmL4U
Amy: [00:00:20.6] Pavel Samsonov is a design architect with a background in graphic design in ux. For the past three years, he's worked at Amazon Web Services, helping big companies rethink their business practices to better serve customers. I connected with Pav because like us, he's one of the few people to use low fidelity storyboards, that focus design discussions on your customer's experience, not on the details of screen design.
Pavel: My latest storyboard spans over two weeks of usage. It doesn't have a single screen. The whole thing takes place via SMS and retail interactions. And when I put it in front of stakeholders for three hours, all we talked about was whether it's the right [00:01:00] experience and if not, what is the right experience?
They never asked me to move a button. They never asked me to make the logo bigger because I didn't ask them for that. I asked them, does this make sense to you? And they were able to respond to that.
Amy: Join us as we explore how to use low fidelity storyboards to design a great user experience. and
Amy: I'm here with Pavel Samsonov. Welcome, Pav.
Pavel: Glad to be here.
Amy: I'm so excited to get to hang out with you. So, Pav and I met fairly recently, and when I saw that he uses low fidelity storyboards in his UX work and understands how powerful that is, I knew I had to learn more about, who this guy is, what he's up to. And today you get to learn more too. So, I wanna start off Pav by just having you introduce yourself and your role and tell us what [00:02:00] does a typical day look like for you.
I bet there's no typical one, but maybe like last Tuesday,
Pavel: absolutely. So I am a, design architect. Broadly speaking. I, work as a consultant on behalf of, uh, aws, so Amazon Web Services, working with, our customers who are large companies, typically trying to adopt the cloud. And that is something that most designers, I think, are fairly hands off on, but a lot of technical transformation like that is actually also a product transformation.
And so what we do, and what I end up doing most of my time is helping them build products in this new world where suddenly you can move faster. And obviously Amazon is known for being innovative and customer obsessed, and it's a very easy pitch for us to make to them that, hey, we will help you innovate like Amazon and build product like Amazon.
And [00:03:00] so what I end up doing day to day, is working with C-suite people, executives, directors, to help them understand and align on who is their customer, what is the problem they're trying to solve for them, and what are some new ways they can try to resolve that problem. it's been a very interesting kind of journey cuz I joined right at the start of Covid where we were just transitioning the practice to fully remote.
So, I spend a lot of my time in Miro now. that was one of the tools we adopted, and I bring those folks into Miro and I help them, facilitate, all of these workshops to get the stakeholders to understand what is going on, how can we get them to move forward in an aligned way, and what are some of the things that we need to test for them?
What are some of the assumptions they've been making that might not actually be the case.
Amy: So, what kind of decisions are they making that you're part of? Is it whether or not to use AWS? Is it best practices to get better use out of it? All of [00:04:00] the above?
Pavel: So typically the decision to use AWS has already happened at their level, and the most obvious thing for them to do is what's called lift and shift, where they just take their entire software suite that they've already built out, they package it up into containers and they host it in the cloud. But that's actually a terrible way of doing things because obviously it's not, it's not architected for that.
So, what we help them do is if you're gonna be rebuilding your software anyway to take advantage of the opportunities in the cloud, you might as well make it better than it was before. And one of the most important things, what we call cloud native product development, is testing is really, really cheap. Building a minimum. We call it minimum lovable product. There's people who say, minimum viable product, I don't like to discuss the difference. It doesn't matter. but we help them figure out how do we get that built quickly and how do we build it not just as a product to [00:05:00] release, but also a tool for learning to continue learning more about their customers so that the next release can also be helpful.
Amy: Fascinating. Tell me a little more about how you use Miro.
Pavel: So, as I mentioned, it's really the place that we use for all of our workshops. And as I like to say, a workshop is really just a meeting with guardrails and people who we work with typically, you know, these C-suite people, executive level people, they're so used to.
And when they go into a regular meeting, their meeting brain switches on and they're used to making decisions and they're used to being asked what to do. They're not used to being told what the right thing to do is in the meeting. And so when we bring them into a workshop into a space they're not used to.
It's a concept that's called cognitive estrangement, where you take them out of the space they're used to. And when you show them things that are familiar to them, they suddenly look at them with fresh new eyes. And so when they come in and they give them a workshop exercise, even if it's [00:06:00] something super simple like let's populate the customer journey.
What, where are the pains in that customer journey? Things like that. Suddenly they're able to look at it without making the assumptions they're used to making. And even if they do make an assumption, someone else can see that and someone else can say, well, hang on. You know, I haven't heard that or I've heard something else.
And it's really the catalyst, that drives those conversations is the mirror because they can see what everyone else is doing. They're not the main character of that, meeting anymore. And we typically do something like five minutes of workshop, exercise, and then 30 minutes of conversation based on that exercise.
And I'm taking notes down the whole time that's happening. And we typically end up with more content on the page than they put down. But it's that alignment conversation that's really, really critical. and that Miro really helps with a lot.
Amy: So, it sounds like you're using Miro as a shared workspace that you then make visible.
Pavel: it [00:07:00] is, in a supervised, supervised way. I don't like to use, to kind of let people look at it offline, or not really look at it. They can look at it. I, I often tell them, hey, if you, if you wanna come back and add more things to the board, feel free to do so. No one's ever done that, in my experience.
But it's that structure that's added to the collaboration during the meeting that I think really helps, by themselves when there's no structure. I don't think it's as helpful because, once again, it's really the conversation that's catalyzed, that's the important part. That what, that's what Miro helps with.
Amy: Got it. So, let's wind it way back now. How did you first get into design and tech? What pulled you into the.
Pavel: All right. So, I started out in high school, way into fine arts, way into illustration. when it came time to think about a career, I was thinking, I, I don't know so much about that. What can I do to, to actually make money? and I ended up looking at graphic design. I went [00:08:00] to a graphic design undergraduate program.
There, I fell in love with interactive design. My entire family has a computer science background. I was the only odd one out. And so I was kind of natural that I would think, Hey, I'm gonna add, you know, programming, coding, interactivity to these, these artifacts, these visual designs that I'm making.
And I, I felt like there's a lot of potential there to do super, super interesting things. I think at the time I was one of about five or six people in that program of about 80 students who was doing interactivity. In retrospect, going through LinkedIn, I think everyone else ended up making that pivot, at one point or another.
And so, starting out with that degree I was looking at what could I do, what are designers doing at the time? You know, this was about, 10, 12 years back. So user experience design was not the field that it is today, and I felt that I actually needed to take it a bit further. So I went to a, uh, Carnegie Mellon for a Master of Human [00:09:00] Computer Interaction to really see how far it could take that to really see, what's there beyond just doing surface level clickable objects that look really good on a website.
Amy: So how did going to CMU shape your approach to UX?
Pavel: It's actually very interesting the kind of stuff they get up to there. the biggest thing for me was getting exposure to the PhD level program, which is probably the better known one, and looking at a ton of papers for, you know, human interface devices, which is something you don't, you really do in graphic design.
And I, I saw that everything that's coming out today is, oh, this is the cool new consumer product 20 years ago. It was a paper 10 years ago. It was a crappy consumer product. And then technology has caught up. So if you think about the iPhone, 10 years before the iPhone, there was the PDA. 10 years before the PDA, there was the Park Tab, and no one's ever heard of a Park Tab.
And you know, the PDAs didn't [00:10:00] really leave a mark, but they were predecessors to something that was coming once computing technology reached that point that it could provide that experience. So that was something I think I could only find at, a, a, an academic and more computer focused discipline. but surprisingly, the other thing that I learned there is very, very, very design focused.
It's very, on the other side of that spectrum is a low fidelity tooling as a research artifact, not just as a. Deliverable artifact. Most of the things we focused on in undergrad were around, here's how you do process. Sure. But process is just what you do to get to a really nice visual deliverable. And at C M U, they, they were showing us this whole other side of it that you do a ton of research, you do a ton of synthesis.
And these artifacts are tools for research and tools for synthesis that never land into the final product, but they're [00:11:00] ways to anchor your exploration. And that, I think is much more valuable as a process or a sub-process within your design discipline than just a sketch. And then you go to higher and higher, higher fidelity, but it's always the same screen.
It's almost like if you don't even think about screens for a moment, you don't even think about buttons or devices. What is the ideal experience? How does it look like? How is it situated within the customer's current context? And then that's where you could really, build something new. And in innovative,
So you learned that at C M U, or at least it sparked you. And the thing that's fascinating to me is that you came outta graphic design, and that's not an easy transition for everybody to make. Many graphic designers really struggle with interactive design. They struggle with letting go of beauty and fidelity.
but somehow you made that leap. So clearly you still have a [00:12:00] graphic design background. You have that eye, that sensibility, but you fully embrace the power of low fidelity techniques to help you design the right product, design the right experience. What were some of the moments or struggles or pivot points in that transition that maybe could help other people who would like to make that transit?
I think that a big part of what got me thinking about this in the first place is the pivot to product management. My previous role was actually as a PM at Bloomberg working on API design rather than anything design related, which sounds like a really massive pivot. But having looked at software development and UX design from all these different angles, what I've realized is that the disciplines have different names, but design is always designed.
Design always has the core design process, the feedback loop [00:13:00] that exists at the center of the discipline. And regardless of whether you're building, you know, industrial products or you're building software, or you're doing interfaces, or even if you're doing service design, And operations work, and you don't have a single visual artifact involved in any of that.
It's always the same process. It's always that iterative critique driven, user research driven, cycle that doesn't rely on thinking, oh, there's something wrong. or doesn't really think there's something wrong, and then you just go and fix it, and you build it and you get it right the first time.
the, the core of design is you start scrappy, you start very vague, and you assume that you are not right, you are still wrong, but you want to be wrong in a safe way, and you wanna be wrong in a way that tells you more about what right looks like. And that's the only way that you can really solve these wicked problems of design.
[00:14:00] They're problems that are poorly defined and they're always gonna be poorly defined all the way up until you've shipped your product.
Pavel: These, this is really the reason. I think that's the core process that has, is the reason, we call it user experience design. And we say design thinking. We don't say user experience programming and programmer thinking.
And I think that if you brought programmer thinking to an executive, they would recoil in horror because they don't want to think that way. But there's something about design that has allowed it to integrate cybernetics, human computer interaction, psychology, behavioral studies, anthropology to an extent, and bring all of these together into what we now call ux.
But it's at core a design practice because it still has that same process that allows you to use all of these tools in a really, really powerful way. And so having that perspective of a product manager and a graphic designer and a UX designer has really helped me see that the process remains the [00:15:00] same, is just the application of it evolves.
Right, and you said something really critical in that process, which is being wrong in a safe way. And I think from what I've seen, and I'm curious what you've seen, there really is a difference between people that think in pages, people that grew up in the web, and they sort of, that's how they think about, it's like page design and there's a sequence of them versus people that think about experiences.
Game design, people like Jesse Shell at C M U comes out of Disney Imagineering designing rides. It's a different way to think and it's a different way to think about what someone experiences over time. Right. So how have you found that low fidelity methods, particularly storyboarding, can help bring a team into that headspace, even bring an executive into that headspace?
Maybe some examples about how you use low fidelity methods to get into that. Let's be [00:16:00] wrong together quickly and learn what's right. Headspace.
Pavel: Yeah, so it really started, I think as a product manager because I realized that not only do you have to kind of sell your vision and get alignment on your vision for a product to get buy-in, but even when executives come to you and tell you, I want you to build this widget, they don't really know what they want.
There's no coherent, strategy there for every single outcome they're looking for. And so capturing that vision and turning it back to them and saying, is this what you mean is super critical to get anywhere. Otherwise, you just spend your time chasing features and you never have any impact yourself and you get fired.
So, In that way, low fidelity artifacts, especially storyboards, are really, really useful because it actually captures that customer experience without touching, as you mentioned, any pages, any buttons, [00:17:00] anything like that. As soon as you have those things up, in my experience, what happens is they start giving you feedback on the buttons.
I want that button there. I want that button above the fold. I want that button in a dropdown. But if you don't focus on that, if you look at the experience, they can only give you feedback on the experience. My latest storyboard that I did, for my most recent customer at a Ws, we cover interactions between four different user roles.
It spans over two weeks of usage. It doesn't have a single screen. The whole thing takes place via SMS and retail interactions. And when I put it in front of stakeholders for three hours, all we talked about was whether it's the right experience and if not, what is the right experience? Are we proud of delivering this experience?
They never asked me to move a button. They never asked me to make the logo bigger because I didn't ask them for that. I asked them, does this make sense to you? And they were able to [00:18:00] respond to that.
Amy: Right, so. In a nutshell, you're communicating at the right level of granularity. If you show people detailed designs, they'll tell you about what they think about the detailed designs, but if you don't, you're forcing them to deal with it at a higher level. The experience level. One of the greatest things I learned from working in game design and, you know, merging that, that divide between game and product design was something Will Wright said over and over again, which is the most important story, is unfolding between your players' ears.
It's like it, maybe it's a sequence of screens to you, but to your user. It's a story unfolding over time and they're telling themselves an internal story about themselves using the product. And your method helps an executive imagine what's going on at that level.
Pavel: Yeah, there's another quote by, Scott McLeod, [00:19:00] and it's something like when you look at a cartoon and as an abstract drawing, you see yourself, you don't see the face of another person. And so in that way, the lower fidelity is actually better because executives look at this and they don't think of, oh, here is, you know, Joe, customer using a screen, which is something they deal with every day.
They think of how would it be for myself? To have this experience. Is this the experience I would want to have? And a lot of the time the answer is no. They want me to change it. And then I spent like half an hour working on this storyboard instead of days or weeks working on a high-fidelity design.
Amy: Take us down one level of granularity in your storyboarding. What tools are you using for storyboarding? What do you have a framework you use? just tell us a little more about how you apply that craft.
Pavel: So this is incredibly embarrassing because the two main tools that I use for storyboarding are PowerPoint and Adobe Illustrator. they're not exactly,
Amy: [00:20:00] Kicking it old school.
Pavel: There you go. They're not exactly the most up-to-date tools. I have used Sketch, I have used Figma. It really doesn't matter to me what the actual.
Software is where the tool is. for the visuals, typically I pull out, different images from kits there's, there's one that I like to use, that's just got some pre-canned, you know, backgrounds and people, I've built up a, an archive for myself of objects or, you know, like laptops, phones, sometimes interface elements that are easy to insert into these things.
And so those, those are the visuals that's the, the comping for that. I've seen some people use, mid journey and do. and things like that to generate panels. I think it's interesting. For me, the manual work is actually really, really important because as I am thinking about that scenario, as I'm inhabiting the problem space, I start to realize [00:21:00] in my head, what is the detail that I'm missing?
What didn't we think about? What did we not, you know, provide as an, as an output for the customer that we might now be expecting for them to give us as an input. And as I do this, as I write, even write the script, which I typically do, you know, in mi sticky notes because it's easy to move around. But as I write that script or as I draw those visuals, I start to think about does this actually make sense?
Is this something we can expect a user to do in this context? And it's that context that I think makes a storyboard so much more powerful than just a scenario. A scenario is great. A scenario I think is mandatory to have. Even, at the very inception of things like personas, Alan Cooper said, personas have to have scenarios because the scenario is what makes the persona real.
But with the storyboard, you also bring in the context. What are the things around them that are beyond the [00:22:00] experience they're having? You know, not describing them, the user as someone who only exists as they use your product but describing them as a real person that exists in their own world. And, you know, five minutes of their time for that day is taken up with your device, but they're still sharing their attention between you and a ton of other things.
Even if they're using a website, you know, I have this recording studio open in one tab, and then I have about 20 or 30 other tabs open, and my attention, you know, in a normal day might be competing between all those different tabs. And when you have just a scenario, you don't have the fidelity to do that.
But when you have a storyboard, you can capture all of that implicitly and bring it up in a discussion and added to the conversation at that level where it needs to be. Not focusing on it, not emphasizing that while our customer is gonna be distracted, because it's not the most important [00:23:00] thing about that conversation, but you keep it in mind, you don't forget it, and it helps you shape your design decisions implicitly as you go through them.
Amy: Yep. It's also a way that you can communicate what happens over time. , and especially if you're dealing with any kind of progression system or you're trying to drive retention, just looking at screens doesn't l let the whole team see. Oh, okay. So 30 days in, given these systems we've set up, this will be happening.
Pavel: Yeah, it's actually why they're really good to show to executives because executives by and large don't use their own product. And so when you explain to them, this is how many steps you have to go through to use the feature, you know when you wrote the user story, it sounded so great. As you know, user, I want to click the button to get my package, and then it turns out, and then after that button, there's 50 forms, or you have to go to customer support, or they don't do the delivery.
They tell you, oh, we couldn't deliver it even though you were by [00:24:00] the phone all day. And you have to call them and get them to reschedule it. When you go through all those steps and you show it to them, they start thinking, wait, we really make them do that. And that element of time is super, super important for.
Amy: Right in the micro, but also in the macro. Like one of our clients was trying to figure out the five-year experience. They're in automotive, right? So there's a like a whole different time. to be figured out. And so is there anything else that you can tell us to help demystify storyboards because you're one of the few senior designers other than me, that fully understands and embraces this and I'm trying to, trying and somewhat succeeding given everyone here really spread the gospel about the power of low fidelity storyboards that show your customer in a context using your product, but not the details of the product.
What else can you [00:25:00] tell us about like that would motivate people to try this?
Pavel: Oh, absolutely. There's one thing that I think everyone is really surprised to learn. The Amazon working backwards method, the whole press release, frequently asked questions, flywheel approach, they released a book about it a while back. Even. this thing's flying off the shelves. Everyone on LinkedIn's talking about it, storyboards are critical to working backwards because the full, the full name of that, of that tool is prf AQ plus visuals.
And the visuals are precisely what captures that experience of the five working backwards question, which is kind of the, the key to this whole process. One of them, and it's my favorite one, is what does the experience look like? And that's where you start, that's where you work backwards from. And so when you get that storyboard together without focusing on features, just looking at what is the experience, you're able to create that alignment.
You're [00:26:00] able to do. What we call disagree and commit one of the leadership principles where you've agreed that the scenario is valuable. You know you can disagree about the particular aspects you develop the scenario, you iterate. But once you've got that scenario nailed down, all of you commit that this is the experience we want to deliver for the customer.
And that really prevents a lot of arguing down the line because now you're talking about does the feature that we're thinking about, does the solution actually deliver this experience? without this tool. I think a lot of people are very good, are talking about high level vision and strategy, and a lot of people are very good, are talking about low level features and how do we make sure that you know, the, create, remove, update, delete whatever functionality backend stuff works.
But the power of the storyboard is to, to identify that missing middle piece that connects the two. It connects the high level vision to the feature we're gonna build. [00:27:00] It shows that's the experience that makes the vision real and that the feature supports. Without that storyboard, it's very difficult to communicate the missing middle, what we call the most important customer benefit.
And teams just keep talking past one another. And a lot of the time you don't get anywhere because the people with the strategy and the people with the features, Don't have anything in common, and so the storyboard really enables that. So for people who are skeptical that, oh, well, we have design systems, now we can just do it in Figma and high fidelity, what do we need storyboards for?
This is what we need storyboards for. We need storyboards so that we can do something new and not just rearrange our existing elements into new layouts to try and create a strategy and try to jump over the step
Amy: Experienced first design, not feature, first design.
Pavel: Precisely.
Amy: So, what are some [00:28:00] common mistakes that you see eager UX designers and eager product managers make when they first start embracing this? What are some things to watch out for?
Pavel: So I think that the, this feature aspect is really the, the first thing I see People get excited and they say, I have this super cool idea. I'm gonna build this feature. It's gonna be so great. And they start illustrating the feature. But getting agreement what the problem actually is, I think is the first thing that a senior practitioner in any discipline needs to do.
This also applies I think, to product management and to engineering just as well, is someone's having a problem, someone's told you I want a solution. You have to understand the problem first. A lot of the time people don't spend a lot of time on the problem and they just assume, oh, we need to make this easier.
Make this easier, is not a problem scope, because there's no solution criteria there. There's nothing you can do that checks off that box. It's [00:29:00] just a. infinite progression into doing something you believe is wrong. And so this is where the storyboard, I think, helps a lot because you are forced to talk about the problem rather than jumping to the solution because you don't have the fidelity to really illustrate the solution.
What people think is the weakness of a storyboard is actually the point of using it in the first place, because once you've put that storyboard together and you can't have a high-fidelity solution in there, you're forced to think about what else do we know? What is the customer problem, what is the context?
And what we even do is we show these things to customers. A lot of people are really scared of that and they say, well, what? We're gonna embarrass ourselves. We're a multi-billion-dollar corporation. We're gonna put a little black and white thing in front of the customer. Customers don't care. They're totally fine with this.
They can give you feedback and if they don't relate to what you've put down, they will tell you. They'll [00:30:00] say, this makes no sense to me. And once they've done that, that's really when you know you're in the money because you start asking them, what do would you relate to? How is your experience different from this?
And you've spent half an hour drawing this storyboard. You've spent a couple of hours talking to customers. Now you have something to bring back to executives to tell them your assumptions were wrong. And that's so valuable because you're gonna realize at some point or another that the assumptions were wrong.
And it's better to realize that at the storyboard stage. Then add the release stage when your metrics are not growing up, no one's using your product, and now you're the one to blame because you didn't catch it earlier.
Amy: Beautiful. You did mention, a storyboarding kit that you enjoy, and I'll follow up with you and get that link and share it with everyone in our ongoing quest to get more people's storyboarding for all the reasons you just laid out.
You did some [00:31:00] interesting, writing and by the way, we'll share Pavel's, medium link and place where you can find him and get his writing with everyone in the show notes.
But you wrote on, ChatGPT and LLMs recently, and I'm interested in right now in the world. Where you're paying attention, what trends are you following? What's your current take on what's going on with AI? What do you see when you gaze in the future?
Pavel: Two things. One is (an) a (pe) pessimist, so I'm gonna start with a bad one first. The struggle that a lot of designers have had historically is getting managers to understand why what we do takes a long time. Ironically, product management has the same problem because it's a very process heavy discipline, but the artifact produced at the end is fairly simple.
You know, a screen, a mockup or prototype doesn't really capture all the work that went into deciding [00:32:00] why these are the right things to put on the screen. In the same way, a roadmap or a user story doesn't itself capture all the user stories that weren't included. All the roadmap items that were cut, and looking at that output makes it look like it was simple to get to that output.
And so it's very easy to create the output without doing the thinking, and it's the fact that it sucks is invisible. And so that's really what a lot of the AI driven stuff is that I've seen. It tries to skip to the output, but the thinking is invisible. And managers who are used to low quality, mediocre artifacts, managers that are used to driving process to be faster, faster, faster and not better, who don't have a, a way to determine what good looks like, what good enough looks like will start using these mediocre inputs.
And that can only produce mediocre products. So that is [00:33:00] a negative that I have seen, which is I think something we're gonna have to fight against.
On the positive side, a lot of the drudge work that has been happening, is now able to be automated. People say, oh, it's gonna make junior positions disappear, but junior work is not necessarily drudge work.
A lot of the work around formatting large amounts of text in a particular way, so it can be visualized effectively or organizing data that you already have that is not a job, that is something that this tool is perfect for. I've seen some uses of G P T to do synthesis. I don't think that's a good idea, partly because there's privacy concerns about who came up with that data in the first place and where it goes once you've put it in.
But partly because synthesis is the way that your brain starts going by looking at that information, you're not [00:34:00] just thinking about the words, you're thinking about the meaning of those words, which the computer can't do. And that's in the same way that while drawing a storyboard, I start thinking about what are we missing while doing synthesis, which I can do with my team.
We all start thinking about, okay, we, we were wrong because of this piece of information, but also this other piece of information means that there's another opportunity for us. And automating the synthesis makes a proper, it problematic by doing things like taking all the sentences from a user research session and putting them into mirror, putting them into sticky notes.
That's all keyboard controls. I used to do a lot of, robotic process automation design at a previous job, and I think that's something that we haven't really looked at yet for G P T as much as we could because hooking it up to things through an a p i is fairly difficult. takes some programming work.
Doing RPA with it should be [00:35:00] fairly straightforward. , and that's when we get to the change that I think is gonna drive to a certain extent, the change in, in inputs. So as an as, as a person with an HCA background, that's maybe more of a, of a pet interest that some people don't share. But I think that the same way that touch screens have, had a very big, impact on interfaces the way we interface.
I think that GPT signals in some way the return of the command line, that instead of a graphical interface, it's now a text interface you've got. One line of text, the standard user journey page to page, to page to page disappears with a cli because you as an expert can just give it one prompt that does everything you want.
But an someone who's not used to it has to iterate on that prompt. And that's the, that's true with GPT. And it's true with, you know, DOS or Linux, where you navigate directory [00:36:00] by directory, or you just put in one three-line command at a time and sit back and watch the computer crunch through your request.
So I think that in the same way that we now use mouse and keyboard in Figma to design for a touchstream interface, it's a bit silly, probably going to change. In the same way the tools with which we design for CLIs don't exist right now. And. The explosion in tooling that I think is starting to happen.
notably ai, I know they've added, GPT support to their research tool. I've met the founders, they're incredibly smart people. I'm looking at that with a lot of interest and a lot of attention. and I can't wait to see how that works.
Amy: What does notably AI do?
Pavel: It's a tool for research and synthesis. So it's exactly what I was talking about in terms of bringing in information, supporting user research. I intentionally don't say usability testing [00:37:00] because I think a lot of people equate one with the other. I think notably it is much more useful for that, exploratory generative research.
Where you're looking at different data points and trying to see how they fit. So from that perspective, I think it's a very underappreciated aspect of the discipline and it's a very underappreciated aspect of tooling. And so this company that is building a tool that a lot of people don't even think they need, using a technology a lot of people are desperate to use in some way, to me is, is super, super interesting because it's, there's actually an opportunity to build something new as opposed to trying to graft AI onto tools that don't really need it.
And it'll already worked fine without it because they've been iterated and they've been perfected over years and years and years, and thousands of practitioners used to, you know, working with them as the standard. So for example, I don't [00:38:00] think that you can do a lot with AI in Jira. Jira is. what it's going to be.
Jira is a dead end in a way, but something like notably is it's a new branch on that tree. It's a new branch of opportunity and I think that AI is one of the things that can really catapult dead, into a much more powerful tool than we've ever had before.
Amy: I like your analogy of the DOS command line or the Unix command line for that matter. And then the explosion of things that got built on top of that. I think that's accurate for the stage that we're at. So what kind of projects light you up the most?
What's your superpower?
Pavel: So I think I touched on that a little bit, but my biggest interest, the kind of things where I really get, you know, firing on all cylinders is when the company or the customer is open to discovery. They understand what success looks like for them, but they don't necessarily know or have a preconceived [00:39:00] notion for how to get there. And let me say, it's quite rare. when customers even know what success looks like for them, and I'm happy to help them get there first, but there are a lot of projects out there where their focus is on validating their one favorite idea that they have, and then the definition of success becomes we ship that idea.
The kind of projects where I really love to work on is where we are able to create many ideas. And so when we go into research instead of validating the one idea, we can invalidate as many ideas as we want because we've always got more ideas. We are not afraid of being told, oh no, one of our 10 concepts, one of our 10 solutions is bad because who cares?
We've got nine more. But when you only come in with one, then at any cost, you must protect it. You have to ignore all the information and tells you you're wrong, or you [00:40:00] have to be the person who tells management. Hey, you spent all this money for no reason. So the opportunity to actually practice design at its most true and most real level being wrong safely.
Part of that means safely for the practitioner that I don't wanna bring those bad news to, to, to the people who pay me because I might not get paid next week. But making it safe for myself means that we come in willing to fail on any one idea because together all of those ideas mean that something will get traction and we can learn from those iterations.
So I'm not sure if that answered necessarily, that question, but that's really the kind of project that I enjoy working on.
Amy: That's fantastic. I relate very much to that. And interestingly, I noticed at, in my career that the game studios and companies I [00:41:00] worked with that most followed that practice were the ones that produced hits. And it is fairly rare, but it's very correlated with market success, which is probably why you like it too.
Like it's really frustrating to work on something that bombs
So I think what you brought to today's discussion, which is. , make sure you're solving the right problem. Consider it a hypothesis tested and low fidelity with the user is a message that needs to be heard more. Thank you so much for sharing your wisdom and your stories and your experience and advice with us.
Pavel: Thank you for having me. And I'll send you those links. [00:42:00]