Iterate Earlier and Faster in B2B Discovery with AI-Assisted Prototyping

Stephanie Reiner at UXDX Community: The AI Edge: Prototype Real, Ship Smarter. Video: https://youtu.be/6CJ2w86WJdo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The three layers of prototype fidelity

[00:00:08] Thank you for the nice introduction, and welcome to my first talk at this kind of event. I want to talk about how we at Trimble have now added AI-assisted prototyping to our discovery phase. Let me switch to my first slide.

[00:00:30] I guess all of us have been at that point where you work on a product for months or even longer, and when it gets launched, suddenly you realise: oh, this is not what the customers had expected. Suddenly they see it, and now when they see it filled with their own data, they come back with requirements that they never mentioned before, just because they can now see their own data and start to really interact with the product.

[00:01:10] Because of that, I would like to introduce, or I think a lot of you have probably heard about it before, the three layers of fidelity that kick in when we talk about prototypes. We have the visual fidelity: how real something looks. I guess most of us are really great with that when it comes to using Figma or other tools to make it look awesome. Then we have the behaviour fidelity: how real does the interaction feel when I'm interacting with the prototype, when our hover effects or micro behaviours kick in.

[00:01:53] But then, as a third layer, we have the data fidelity, and I think this is where a lot of us fall a bit short. The data fidelity is about how realistic the data feels in the prototype. Is it just dummy data, or are we able to pull in real customer data? And I think this is where the conversation changes a little bit, especially in the B2B context, because here are the blind spots. Users look at a beautiful design prototype, they give feedback on the layout and so on, but they are not really judging the data that they see in that moment.

A classic start, but no developers

[00:02:57] Last year I stepped into a new project inside of Trimble, and there we started by following a really, really classic workflow in the beginning. We interviewed our first customers that were interested in our product idea. We sketched our first user flows, pointed out the pain points, moved on to some wireframes, and did a lot of iterating together with the customers. So, a bit classic, old school.

[00:03:33] But then we got to the point where we realised: hey, we don't have any developer resources yet, so how can we get closer to more findings if we can't start building the real thing? So we asked ourselves: what if we just take all the information that we already collected, our learnings, our first wireframes and also the two or three high-fidelity screens that we had built till then, and make them into a product requirement document that we can feed into a vibe coding tool? How far would we get with that?

Prototyping the minimal lovable product with Cursor

[00:04:26] This was the experiment that we ran. We created that product requirement document, attached some wireframes to it, and uploaded it, in our case, to the tool Cursor. But to be honest, this could also work the same way with Claude, for example, or one of the many other tools that are out there. And this then created our first prototype of our minimal lovable product.

[00:05:01] To be honest, we were quite amazed that it worked so well, and we really easily had a running prototype that you could freely interact with. I don't know how many of you have been in the past in that situation where you had a really specific, stuck workflow inside of Figma. When presenting, you followed a really specific path. You could only click here, only click there, maybe apply this filter because you planned for it. Of course, with the evolution of Figma you could make that more flexible, but it was still a lot of effort to set up the conditions and rules.

[00:05:48] Now we had, with Cursor, a coded prototype that could be iterated with prompts and have features added on. It had a dummy data set in the background, of a dummy fake company that we created in the product requirement document first, and now you could just interact with it. You could click anywhere. You could interact with the table, play through all workflows, and even change the language of the prototype quite easily, because we just implemented it like that.

How it changed customer conversations

[00:06:24] This also changed, of course, our next conversations with the customers, because they realised in the talks that they could just freely ask us questions, like: hey, could you click here? We would just do it. Also, if we assumed already that some data could be important but we were not sure, and then they asked for it in the call, we would just switch on the correct data. If they asked for an additional column in the table, we would just be like: okay, here's the column picker, switch it on, because it's implemented, just not visible by default. Like that we could easily learn: hey, this is their data, their priorities. Or when they asked to filter for something in the call, in the interaction we could also easily show their data and how it was expected to behave.

Finding edge cases earlier

[00:07:17] And I have to confess that it also changed my own experience. I know we have that topic that we sometimes think a bit too late about edge cases and error cases. To be honest, just playing around with the prototype, I also realised: oh, hey, here we have a gap. I can just leave a screen without saving, or I can add data that doesn't make sense. I can add a date that is in the past or something like that.

[00:07:56] Now I could just start to directly put these edge cases into the prototype and just say to the tool: hey, we have an edge case, we need to make a rule here that this is not possible, and so on. So I could directly build on a lot more knowledge than I did before, when I was just building it in Figma, or when only in the conversations with the developers later did I come onto the path where I said: oh, this is missing.

Adding real customer data

[00:08:26] This was already quite nice, I have to say, but we asked ourselves: okay, could we not take that even a step further? We wanted to find out if we could also add real data to the prototype, if that is possible. What we did next was simply ask the AI tool, Cursor: can we just implement an export and import functionality, so that we can export the dummy data set as a CSV file and then manipulate it?

[00:09:11] We also used that to prepare our customer calls differently. We actively asked our customers: hey, is there any dummy data that is related to your business? In our case, the product is about orders and order exchange between companies. So we asked: can you give us some orders from you that are anonymised, so that we can use them for the prototype that we will then share just with you, but where we can show you how your own data would behave in the prototype?

[00:09:52] This was great, because in the CSV file, of course, we could already see: hey, this is the terminology they use, this is how they do it. And when we imported it into our prototype, we realised: oh, hey, there are maybe fields we hadn't foreseen in the prototype yet. And also maybe data we thought would be important in the new product, but it seems it was not important at all for our customers, because we couldn't find the data. Or we could at least now go back and ask them: hey, is this really something you don't need, or is it something that we are just missing at the moment?

[00:10:36] It changed our conversations with the customer, because it was not about "does this look good, does it look right to you?" anymore. It was really starting to be more about: okay, but is your data missing? Is it really how you communicate? Or we saw fields where they were like: ah, well, this is a number that we use only internally. Our suppliers don't even know that number; they don't need to see that.

[00:11:13] So we directly learned much more about what really needs to be on the screen to enable the exchange with their partners, but also how we need to organise the screen so that it just works for this user. We learned how to better prioritise what we see here. And that's much earlier in the process than we used to, because at least for us it happened quite often in the past that we had that conversation only when customers had already started testing the product and came back with: oh, but we need additional data, or we can't use the product at all and don't want to pay you for this yet. So we could now spot this missing data much earlier, and that helped.

[00:12:10] And also, of course, if you are in this position, you can already see that you're not testing just the usability anymore. You also now start testing if this is worth putting the development resources into and really building it. So, testing assumptions quite early in the process. Sorry, I missed... It's a question that is usually answered much later.

The prototype couldn't go to production

[00:13:00] And then something not so good happened, because till here it was quite nice. The story sounds great: we had a great-looking prototype we could interact with, and we had quite a great exchange with our customers. But we finally got at least a backend developer, and the next question, especially from management, was: is it not possible to just push this front-end code to production, because it already works? It looks great. Why can't we just push it?

[00:13:31] But the developers, of course, said no, that's not possible, because the code was just too bad. It was thousands of lines, some of them really unnecessary. The dummy data was just mixed into the code and not in a separate file. It was, I have to confess, really a mess code-wise. So it was not easy to just scale that and push that.

[00:14:04] We stepped into that because when I first started running that prototype test, I didn't expect that it would grow so much, at some point contain so much behaviour, and be kind of the blueprint for our product. And I didn't know how to do better, because I guided the AI in this example quite well from a UX perspective, but I don't have the coding perspective. I was not giving it the correct prompts in the beginning to build a solid architecture for that front end that would have been able to be pushed. So it was also a lack of knowledge on my side that was the stopper here.

The handover problem in a new form

[00:14:54] And then we came into the next situation, because our developers said: okay, sorry, we need to build the front end from scratch too. At this point we were suddenly running into a classic problem that we probably all have known for years. We suddenly had a handover problem, because we had a prototype that contained all that behaviour, but we didn't have good documentation about it.

[00:15:33] So the developer started the front end, we realised, okay, but this is not working the same way as the prototype, and we suddenly had to do a lot of iterations again, even if we were already a step further. So it was really again that classic handover issue, just in a new form.

You still need the research first

[00:15:57] What I also need to mention here is that the prototype still had a lot of value for us, and we could only make it that way because we had done our research first. We had a really clear picture of what workflows and user flows would be integrated into the product. You need this valuable, qualitative input for the AI to build a good prototype in the end. You can't take a real shortcut here. Of course, you can also do your research supported by AI tools in a lot of places, but you still need to have that foundation before you go and create something more with it, because if you give it a prompt that is not concrete, the output will not be good.

[00:17:11] And that also happened to me, to be honest. I had to learn in a tough way what happens if I give the AI only a rough explanation of what I want. For example, when I did that export and import functionality, from the export perspective it looked really awful, I have to say. I was just telling the AI: this is what I want to do. I was not guiding it on how it should look from a UX perspective. How it should behave, yes, but I didn't say how it should look at all, because I just wanted to have that functionality and quickly get in different data. And it came up with a really weird UI that was not what I had expected, but also because I was not giving it the idea of how I wanted it. That's the thing: you still need to guide it and give proper input to it.

What AI can't replace: research and judgment

[00:18:18] Because the difference in the end isn't the output, isn't the tool. It's the thinking you bring to it first, and then working with that. This is also where I see the two things that AI still can't replace. It's still that we need to have the research first. You need to understand first: hey, what is the issue here, what do we want to solve, what is our use case? Because only if you understand it and can explain it to the AI, to your team, to your stakeholders, only then will you create great output in the end.

[00:19:10] The other thing that AI can't replace here is the judgment. You are the person who still needs to review everything that the AI creates, just like the example with my additional functionality. Also, it's trained on what it can find on the internet, so it will maybe come up with a really generic solution to your problem if you don't have a specific idea already of how it should be solved, because it's not thinking that uniquely yet. So you still need to have been there in that space where you try to create a new solution, and from there you can do amazing things with it and be that product creator, just in a new way.

What we want to test next

[00:20:07] To be honest, this is the next journey for us, because we don't feel that we failed with our first prototype just because it was not ready to be pushed to production. We see that there are a lot more opportunities now. For example, we would like to test: what if we just let the AI create the documentation that was missing? Also, can we do co-vibe coding between UX and development?

[00:20:41] This is why it's hard to make a talk about AI, because it's changing so fast. I also learned that last week Cursor dropped Cursor 3 [?], which is more about orchestrating several agents in parallel to solve an issue. So it's not even prompting, reviewing, prompting, reviewing anymore. It's more about first explaining the whole feature, then letting the agents run and do it, and then reviewing the output. But the question is still: can UX and development together create a much better input for the AI first, so that the output will also be much better in the end? And will that maybe solve our handover issues somehow, or how would it at least influence that? So these are a lot of things that are next to be tested.

[00:21:33] Also, of course, running additional tests. For example, what I'm doing at the moment: I have access to our product repository, and I'm now doing UX reviews on a feature branch. Cursor has that design mode where you can just click and point at an element and then tell it: okay, I want this button to have this colour variable, and this padding to be this padding variable. Then it will suggest the code changes. You push it, and the developers can review and merge it, without first documenting for a whole while, "oh, but this should be like this, this and this", and the developer does it and you review it again. We take a little bit of a shortcut here so we don't have this back and forth just about pixels.

[00:22:24] These are things we really would like to explore next.

Would we vibe code again?

[00:22:35] To come to kind of a conclusion here: would we vibe code again? Absolutely yes, just because you get a visual so fast, and a visual gets an idea across faster than any brief can. It moves conversations forward in a way that nothing else does. This is why we would always encourage everyone to just try it out, and let's see where it goes next. Thank you for listening to this topic, and you're welcome to ask any questions now.

Q&A

[00:23:29] Host: Excellent. Thank you very much, Stephanie. It was lovely to see how you evolved through, as you were saying: you've learned from your first iteration and now you're ready to go and do it again, which is always how it happens anyway. As Stephanie said, if you have any questions, please do write them in on whichever platform you're watching this on, and I'll put those questions through to Stephanie. But one thing I want to start with: you mentioned that you started using Cursor. Is that something that somebody trained you on, or did you just find it online and figure this tool would be really good? And was there a learning curve to get up to speed with that?

[00:24:11] Stephanie: I have to confess it was the tool that was available in our company, where we already had an enterprise license, and it was easy to at least get started. To be honest, I did the setup together with one of the developers and then I was quite on my own for a while. But luckily I had a co-worker, also UX, who did exactly the same, just in a different product, and we had an exchange where we were just like: okay, what did you try this week with Cursor? And we pushed ourselves to the next limit and shared ideas with each other. I have to confess it was especially a hard learning curve how to prompt better, because I didn't do that before.

[00:24:57] Host: Yeah. And as you were saying, you have to think through all of the edge cases, because otherwise it doesn't catch them. One thing I'm curious about: I don't know what your design system is like, but did you find it was difficult to get consistent-looking prototypes that matched your existing designs? Was there a way that you were able to incorporate that, versus, as you said, going and saying, I want this padding, this colour, and all of that?

[00:25:25] Stephanie: I have to confess, most of the time I was building one screen in Figma and then using an MCP connection from Cursor to Figma to let Cursor just gather the concrete requirements. My team also uses a design system, components called MUI, and like that I could guide Cursor with both. I could say, "Hey, use these components, but with that styling from Figma," and most of the time it already got there, let's say 95%.

[00:26:05] Host: Excellent. That's great to hear, because to me one of the challenges is that consistency, I guess. I've been trying to jump straight in, skipping the Figma there. But maybe that's the key.

[00:26:19] Stephanie: Yeah. Especially because if you do it that way and then add on to that later, you can be like: okay, take over the modal or pop-up design here and do this. And then it works quite well for additional features to build on it, if you have at least the base correct.

[00:26:38] Host: Great. And what was the developer reaction when you handed them this? Was it "this is fantastic", or, because as you said there were gaps, were they saying, I still need my spec and I need my traditional documentation?

[00:26:54] Stephanie: Yeah, it was tough in the beginning. I quite often had the question from them: why are you even doing that? Why are you starting to code here? Of course, we had a good excuse, because we said: well, we had no developer yet and needed something better to show. But on the other hand, it was still tough to hand over, because I think they still felt uncomfortable using the Cursor project and just being like: hey, tell me the specs for the UI. They still kind of expected us to deliver that to them. So that's why we are still at that point where we need to decide here.

[00:27:42] Host: Yeah, your idea of experimenting, and hopefully you can get a dev on board where you have that close collaboration. Great idea.