I just finished up a three week long, rapid prototyping project with a development team of four: 2 designers, 2 developers. Since SEP may have more prototyping opportunities, here’s what you can expect from this kind of engagement.
First, what is a rapid prototyping project?
A short, intensive, and focused effort designed to learn more about a product’s fit for market need, usability, or technical feasibility. New information that is valuable to overall product development initiative is gathered, producing outcomes such as prototypes, idea validation or technical proofs of concept.
What should you expect out of a prototyping engagement?
Expect a team lead who isn’t a developer.
This is pretty different from our normal engagements as, by the numbers, your lead is more likely to be a former or current developer.
The more I work with our designers, the more I appreciate their mastery over discovery work. It’s like they’re built for taking point on a discovery project like this one. As a result of having a design brain at the helm, we built questions rather than answers.
Less of “the client wants the user to be able to upload a file.” More of “how would the data get imported into the app?” In either case, you may build a modal that uploads files, but in the second case, you’re expecting (hoping?) to be wrong in some way. In the second case, the outcome – the answer – feeds into the question you build next.
Expect to have more than one prototype media.
Obviously there’s the code prototype we built. We also had a ton of paper prototypes drawn by the designers, as well as pixel prototypes in Figma.
We used the code prototype to discover the primary workflows our clients were interested in.
We used the pixel prototypes to probe a bunch of different, divergent ideas our clients didn’t necessarily ask for.
We used the paper prototypes as a shorcut to peek into our designers’ heads.
Expect to use very few tools.
We used the create-react-app code generator, Tailwind for styling, and Electron to deliver our prototype to the client.
No backend. No tests. No Kanban Board. Total chaos. 😅
Expect to have very few rules.
I think the one ritual we had was to meet first thing in the morning. That meeting started whenever the four of us got into the office, and we talked about whatever we needed to in order to get the ball rolling.
We collectively dumped all of the information we found out, and collectively came up with a todo list. Throughout the day, we each just picked a thing to check off the list. We paired when we needed. We soloed when we needed.
The one thing we did mandate was constant communication. Since TODO items were a matter of minutes or hours, minutes or hours was how often we’d check in with eachother for advice or status updates.
Expect to hack.
#SmokeAndMirrors feels super gross after working on nothing but production code for years, but you’ll realize that the prototype only has to last three weeks and so you’re free to do some shady things.
It’s hard to strike a balance between writing just enough code that works long enough for a question to be asked, and writing code that isn’t too brittle to build off of when we do find our next question.
There were quite a few times us developers were in the middle of coding up something “the right way,” and realize it’s something we should have totally been hacking together.
There were other times where we were hacking something together, and realized it was easier and faster to built it “the right way.”
Expect to not want to be done.
A prototyping project is all about asking questions. The prototype will ask a lot of questions of our client. How would you use this page? Is this how you would want to upload the data? Is this how you would search for something?
Since we were never going to run out of questions to ask, we needed some way to force ourselves to stop working on it.
To help us ramp down, we created a punch list for our last week. This helped us define when the prototype was done done.
Finally, what could this engagement opportunity look like?
<insert-rumor-here/>
We tossed around the idea that SEP could have a dedicated rapid prototyping team. The team would get really good at spinning up these prototype artifacts quickly. They would get really good at one tech stack to do so. They might offer their services to pre-engagement discovery sessions. They might offer their services on-demand to existing projects. They might offer informal, ad-hoc services to teams in need of a quick proof of concept. They might train teams in the art of hacking so we can rock our clients’ hackathons.
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
