Build a Prototype

The core purpose of the prototype, the assumptions you are trying to validate/invalidate or the knowledge gaps you are trying to fill should have all been discussed in Converge.

During this phase roles shift. Designers are typically the ones building the prototype unless it is low-fi enough for everyone to contribute. The rest of the team should be in charge of getting realistic information, data and copy into the prototype. It should be clear what everyone's role is before the phase starts. The team should check in with each other as much as possible to make sure everything is on the right track.

Tools & Methods

There are lots of different tools out there to build a prototype with. Picking the right tools depends on the goal of the sprint, how many solutions you want to test, and how the real tool will work. For example anything that is going to be used primarily on a smartphoen should be prototyped on a smartphone, if your product is going to be a service a script and a prototype paper form could be enough.


  • Figma: A great all-in-one power tool to create and share prototypes with users.
  • Webflow: You can create realistic websites quickly with Webflow
  • HTML/CSS: Sometimes that key interaction simply cannot be faked so HTML/CSS (and a bit of JS) is a good choice.


  • Miro: There are lots of easy to use UI kits for Miro, this is a great way to involve everyone.
  • Keynote/Powerpoint: These tools are familiar to lots of people and can be used to quickly create a prototype.
  • Paper: When testing in person paper can be surprisingly effective.

At thoughtbot we primarily build our prototypes in Figma or Miro.

When building any prototype it's important to remember to balance time and realism. The prototype needs to be realistic enought to understand, but not take too long to build. An unrealistic prototype will distract potential users, and taking too long risks wasting the teams time if the solution is not well received. It's a principle that Jake Knapp calls 'the goldilocks quality'.


  • When working with digital tools start with text, it's much easier to get a good foundation and slowly build up the fidelity from there.
  • Use scenarios if you're testing more than one functionality. It can be tricky to come up with realistic reasons to test some features so skip ahead.