Back to Blog

The Dirt: Rapid Prototyping with Fresh Tilled Soil CXO Alex Fedorov


Rapid prototyping helps you pick the right goals and designs early in the product development process. Getting it right early pays off – what costs $1 to fix in the requirements stage costs $3-$6 to fix in design, $10 to fix in coding, and $40+ to fix after release.1

In this episode, Fresh Tilled Soil’s Chief Design Strategist C. Todd Lombardo talks with Co-Founder and Chief Experience Officer Alex Fedorov about rapid prototyping, understanding the tools, the process, finding a workflow that works for you, and some of the inputs you need to create prototypes rapidly.

Follow The Dirt on Twitter

Listen to the Show

Have a question about rapid prototyping? Send an email to Alex.

Show Notes

1 Graham, R.J., & Englund, R.L. (2004). Creating an Environment for Successful Projects, Second Edition. San Francisco, CA: John Wiley & Sons.


C. Todd Lombardo: Beer, beer, beer, beer, beer, beer, beer? You like hoppy beers.

Alex Fedorov: Indeed, I do.

C. Todd: Excellent, and you are a hoppy UX designer.

Alex: Yeah, I guess you could call it that.

C. Todd: Because you’re fast like a rabbit, and we’re talking about rapid prototyping.

Welcome to Dirt, ladies and gentlemen. I’m C. Todd Lombardo. I’m here with one of our lead UX designers, Alex, and co-founder of Fresh Tilled Soil, Alex Fedorov.

Alex: Hey. Thanks for having me.

C. Todd: Welcome to the show. Alex, we were talking earlier about just how fast you can make prototypes, and you can make stuff really fast. I want to talk about that mental shift, that I think that you get into when you’ve got to put something together fast.

Alex: Yeah. I think part of the speed just comes with repetition, having done this for almost 15 years now. But, I’d say, part of it is just understanding the tools and the process and just experimenting to find a workflow that works for you, and just getting more efficient as the tools evolve. For instance, I used to design almost everything in Photoshop and it really took a long time since I have to get a number of different screens. Back when I first started, I was more doing rapid prototypes in HTML and CSS, and duplicating some elements to save time. Once you have a couple of different pages, you can start assembling things a little faster and linking them together.

But what I would say is a real game-changer recently is Sketch. The ability to create and reuse symbols and styles, duplicating art boards and putting them next to each other to see a whole flow and different states of navigation is great. It’s a combination of understanding process and tools.

C. Todd: Yeah. It seems like you’re borrowing an aspect from programming, which is “don’t repeat yourself,” right?

Alex: Yeah.

C. Todd: How do you, as a designer, reuse components and other things like programmers do with their code?

Alex: A lot of work goes into crafting one or two components or states of a page that has a little bit of everything on it. Really being careful about that, and making sure to convert those to elements to symbols and being conscious of style, symbols, naming conventions is key. I’m a little bit OCD in terms of how I lay out the actual canvas, so I stack things top to bottom and I name them really well.

I find in doing that for maybe a UI kit or something similar, you can drag those elements off to the side. Then, as you start composing pages, you’re using the same elements, but you’re just putting them in different places or maybe making copies to do state changes. It starts to come together pretty quickly. Again, with Sketch, the ability to have multiple art boards and see across different states and pages is really helpful.

C. Todd: I can imagine these prototypes are going to be thrown away, or are maybe just conceptual. They’re not production level work. In creating these types of prototypes, what are the inputs you need from product, engineering or other clients?

Alex: That’s a great question. It varies. The first one would be just the device. If you’re targeting a specific technology, that’ll help you physically set up your file and your canvas.

In terms of interactivity, user stories or any existing brand elements or pages you might have that demonstrate a particular workflow are helpful. If it’s completely blue sky, a back-of-the-napkin sketch or an explanation of what this product is, who it is for, and what are they most simple features as workflows that you need to user to accomplish. It always helps to have some kind of basic navigation in mind so that you can create these systems. Who it’s for, and what it has to do in its simplest form are the key information.

I find that by starting somewhere, making something visual, you can always adjust and iterate on a lot of these prototypes and products. By having some starting point and putting something on paper, for lack of a better word, like digital …

C. Todd: Digital paper.

Alex: Right. And putting it in InVision through Sketch, you start to be able to react to it and talk through the use case, show it to testers, or show it to the product owner and asking “How close is this based on what you told me?”. It can either be a description, an epic, a series of stories or even just a high-level sketch of what people have in mind.

C. Todd: Can you talk about setting up your page, and how you design a page or a flow? Talk about the differences between how you think about designing a page versus how you think about designing a flow.

Alex: In its simplest form, a flow is really just a combination of pages, but it takes into account the context of what someone’s doing. A common example of a flow that I’ve done countless times is a wizard. You’re either setting up an account, or you’re going through an on-boarding process, or even if you imagine an e-commerce flow like Amazon, you’re going through three or four distinct phases. Usually I will start with just a page. Even if I need more unique elements later in the flow, say step three or four, it usually makes sense to draw out those components at the beginning and use them throughout.

I pay a lot of attention to form inputs and labels, the progress indicator at the top, how buttons look and how cards or modules look. Then, I’ll duplicate that art board and just start changing the content, or rearranging the fields, accounting for what needs to be in each of those steps.

It helps to consider error states and success states while you’re doing that. Especially when the user completes the form, because a lot of people will just assume, “Oh, okay, I’m at the last step and I hit Submit and it’s going to go back somewhere,” but it really helps to understand that you’re ending that flow and you want to reassure the user that …

C. Todd: Where do they go?

Alex: Yeah, there’s a success state and what do you next, just understanding how do you get in and out of the flow …

C. Todd: Kind of like when Netflix just automatically plays the next video, right, or YouTube plays the next video.

Alex: Absolutely.

C. Todd: You said a couple of other things that I want to unpack a little bit. One was using certain components. Do you start with a component library of sorts when you’re thinking about, “I’ve got to make this prototype. I’ve only got a day or two to make it?” Do you start with a set of components, or do you make them on the fly and symbolize them as you go?

Alex: It depends on the case. If we know that we’re going to be rapid prototyping something that has to do with a very iOS look and feel, then I’ll see what the latest is in terms of their UI kit or a public UI kit that is using that style, and I’ll try to follow that; same with the Android and material design.

But if it’s a web application, even if it’s responsive and we’re targeting an iPhone size or a tablet size, and the company has strict brand guidelines, nice branding components like a good logo, color schemes, and good font choices, it’s pretty easy to create those components on the fly.

In some cases, I’ll create symbols and styles as I go, so I might have a text input and then, a select menu. Then, later on, I’ll realize, “Oh, I need a checkbox and a radio button.”

It’s not too hard to interpret what those are going to look like and, then, create symbols as you go, so I don’t always start with abstracting everything. I’m big in building things in context and assigning two symbols as I go and, then, just making sure those are cleaned up later.

C. Todd: Interesting. Some people might do the opposite. They get their symbols and things in place, know they need some buttons and form fields. Then they’ll design as they need to. It’s probably a six and one-half dozen of the other type of stylistic approach of how you approach prototyping.

Alex: Yeah, I think it’s really just a matter of preference. Even people here on the team I work with a lot of times will just want to compose a few pages and really not even think about naming the layers or creating styles or symbols. Then, they’ll take a break and come back to that same file and, then, really start organizing things when they feel like their creativity has been captured.

C. Todd: Talk about being in that creative mindset. How different do you approach a rapid prototyping project when you only have, literally, maybe a few days, max, to create the prototype versus a longer project where maybe you have weeks to months to actually create a prototype. How do you approach those two differently?

Alex: Well, I guess for the more rapid prototype, for instance, if we’re doing a Design Sprint, we have on the fourth day, just a day, to do the prototype. I eliminate as many distractions as I can by letting people know, “Hey, I’m going off Slack. I’m not going to be available for a lot of meetings,” and just clear out that time.

Start somewhere and be able to get a sense for which things are you going to be able to tackle that day. Whereas if it’s a longer project, being more conscious of where you are going to start. Are you painting yourself into a corner in any way with the way that you are approaching navigation, or something like a dashboard, or series of components there?

Yeah, the rapid prototype is usually meant to just tackle one particular feature, or feature set, but I don’t think the approach is totally different. I think it’s just more like slicing out what you’re going to focus on, being able to talk about elements to iterate or add on later. Just try to avoid setting up something that would preclude you from doing something elegant later.

C. Todd: I talked to Hamy, one of our other designers about this a couple of months ago. She came to this epiphany that having certain elements perfectly designed out could actually be a distraction to the user. It was about actually designing the onboarding flow. Even though there were some elements that made the prototype look like a finished product, the tester was never going to touch those elements.

Alex: Yeah, absolutely. Say that you have a panel navigation for a mobile web application, or even just something that’s on desktop. If you’re really focused on validating or de-risking one of the sections with say 12 pages, that are part of the flow and something changes in the IA, it’s easy to update the IA since the navigation items are one symbol.

It’s really easy to update and reorder pages in a clickable prototype in InVision if you’re using templates wisely.

C. Todd: If you’re using a design framework like Bootstrap or Material or Foundation where there’s a existing level of componentry there, and you’re doing some kind of rapid prototyping, what’s the thought about just doing the prototyping in some kind of code? What is your take on that, and how would you approach that from a rapid prototyping perspective?

Alex: I think it’s really valid. One of our designers earlier, Jenna, was mentioning that in this type of case, it might be overkill to prototype the entire thing, knowing that these patterns are pretty strict. In this case, I think we’re talking about a material design project, knowing what the title bars and navigation are, sort of the componentry and workflows are probably going to look like. In that case, you could really whiteboard or sketch it out on paper, work side-by-side with a developer to be really collaborative in that approach. I am totally a proponent working in code if that’s for efficient.

C. Todd: It seemed like in this case, it was more about the pieces already being there. You didn’t necessarily have to design the aesthetics. The designers were tasked more with designing the workflow.

How do we solve for the job to be done here? How do we solve for that user story? That’s where the designer can come in if you’re doing like a pair design in code, or if a designer can code, you can just put the pieces together that are already existing from some of the design framework. I thought that was kind of an interesting suggestion.

Alex: Right, it’s almost like an assembly of the pieces in a way that’s really taking into account the experience in the context of the user and, like you said, so much less about the aesthetic details because that’s already sort of nailed down for you.

C. Todd: The design brings that thought process on the experience workflow to the table. If you have developer or the designer can code, the prototyping happens much, much faster.

What are the tradeoffs in rapid prototyping, whether it be code, or in InVision, or Sketch? What are some things you have to be careful of?

Alex: In the context of what we were just talking about, the assembly of different blocks, one of the things you could run into is it looks very similar to what’s already out there. It looks almost like too native and, then, it starts to look like applications you might be already familiar with, which can be good and bad. You’re using existing styles, but are you able to express yourself creatively, and is this unique enough that it’s reflecting the brand guidelines? That could be one thing.

Another thing I would say is definitely one of the downsides with rapid prototyping, if it’s static, in Sketch, InVision, Photoshop or whatever you have, there is no data layer. There’s not application logic, so especially when you’re doing user testing, you have to ask people to suspend their disbelief to some degree. I’ve done countless user tests where I’ll show someone a login page and ask them to sign in. They always tap on email, password, and then hit “Submit.” Usually all three of those fields will link to a state where there’s either some input, or they’ll go right to the dashboard and be confused. They won’t have typed in their email or ask what the password is. You have to explain that it’s a flat representation of an interface and ask them to talk through what to do. You have to be pretty specific with people.

I’ve seen other people prototyping with React or Rails. Geordie, on our team, has done stuff where you actually do create a user account for somebody and what they type in on a certain form, will appear on the next screen after they hit “Submit.”

What I do just to get this done rapidly to test these ideas and get a workflow down, get some reaction to it, is create fake dummy placeholder text statically. Sometimes people react to that, but you just have to prep them.

C. Todd: I experienced that as well, and I’ve done some prototypes in Laravel to help with that. We mocked something up with Sarah as the user, but the person we were testing with was named Lance. He was like “Yeah. Wait. Huh? I’m not Sarah.” There’s a mental map that has to happen for the tester. That’s definitely the downside to rapid prototyping, especially if you’re doing more static deliverables and not prototyping in code. If you can do the Rails, Laravel, some kind of app that does have that data interactivity or logic layer, that’s vital.

Anything else that’s a challenge or friction points when doing rapid prototyping?

Alex: I guess the level of fidelity is kind of a tradeoff. If you have, like you mentioned earlier, maybe a couple of days or a week, you might be able to really refine the elements and make it aesthetically pleasing, but you might not really be focusing on that. You might be focused on the steps in the flow and the composition of each step. Maybe you don’t always have time to refine anything in some cases. A rapid prototype should be a little bit lower fidelity than a final design for a finished product.

C. Todd: If a tester or client looks at the prototype and sees that it’s overly polished in certain areas, that might change their expectations. They might think it’s already finished.

Alex: Yeah, you’re right. In the spirit of iteration and feedback, you don’t want to set the bar too high, or the standard where it’s like, “Okay, we think these workflows are good. We’re ready to test them. By the way, it’s so polished that it does almost feel like we’ve thrown this back over the wall to you and we’re done.” Obviously, that’s not what you want.

C. Todd: What other challenges do you face? Somebody brand new to rapid prototyping. You got a fresh designer. She’s fresh out of college and she needs to do some rapid prototyping. What are the first things she should think about before she does this?

Alex: I guess just approaching it with a mindset where you’re not too fixated on making something perfect. Just start by defining something, getting something on the screen, starting to iterate, maybe making these symbols and making these components that you know you can adjust later.

To your point earlier, I think you said that towards the very beginning of the episode, in a lot of cases, these rapid prototypes are going to be completely thrown away, or there’s elements of learning and sort of the validation that you do around the prototype that will be kept, so there’s a lot of thinking. In some cases, visually, they might resemble the prototype. But just getting out of that mindset that it has to be perfect, it has to be sort of the product itself is important.

C. Todd: I think that’s a great point to end on. Especially in rapid prototyping, it’s about learning. It isn’t necessarily about creating the prototype or product itself. It’s like you’re building to learn. Thank you for hopping in the studio and joining me today, Alex.

Alex: Yeah.

C. Todd: It’s been a pleasure, and we’ll see you next time on The Dirt.

Author Heath Umbach

More posts from this author

Sign up to receive updates from our blog

What we do Expertise

From concept to design, we'll partner with your team to deliver amazing product and website experiences.

Recent Projects Work

See the results of our most recent digital product and website engagements.