No formula for prototyping?
People often say there’s no formula for prototyping. We’d beg to differ. It makes no sense that we can perceive black holes from aberrations in optical data, but not be able to formulaicly define the prototyping process.
Maybe there’s no formula for prototyping yet.
We don’t have it either, but there are some commonalities we’ve noticed…
Excitement
You have an idea that you’re pretty sure can be done. You just have to figure out the finer points! It’s time to start banging things together until something new comes out.
Frustration
You’re trying to make something that you’ve never seen before. If you have seen it, you’re either buying it and skipping this process, or trying to make it better, cheaper, or slightly differently. You’re prototyping because you know what you want, but you don’t know how to get there.
There’s bound to be some frustration when you come up against problems you’ve never solved before. You have no idea how to solve them, but have to get past this in order to trust yourself enough for these problems to get solved.
Fear
Some issues, tight timelines, short budgets, difficult materials or projects, can really put the pressure on you or your team. Combine this with frustration and you may wonder if you can ever solve the issues you are working on.
Gathering information and people
A fair amount of problems are multidisciplinary, require a breadth of experience, or are really difficult. This usually means you need to know more in order to finish your project. A shortcut to learning quickly as a team is to consult with people or informational sources that will fill in the missing pieces. In some cases, you may not even know what those missing pieces are.
You may find you need some extra help as you add people to your team temporarily or permanently.
Some people skip this step and bang their head against a wall forever, but we don’t recommend it.
Timelines
This should really be your first step. Start from the ship date, add about 20–30% of flex time, and then work backwards. Be as detailed as possible. Create mini-deadlines that show you’re on track. Assign tasks or projects to people. Make sure there is appropriate talent, support, and responsibility backing the project.
However, if this is your first project, you may start to develop a timeline at about this phase, or even later on in the project.
Projects can become so expansive that you forget all of the little details, and then they creep up on you. Detailed timelines keep things running smoothly as much as the team that is running the project.
Going down the correct path
Usually, you don’t know what you don’t know until you explore a few things you think you know on the project. How can you really know the path you’re going down is fruitful?
The quick answer to that is data analytics and UX feedback. It would behoove you to collect data before you think it’s relevant. You don’t have to review data daily. But if you choose to review at any time, it’s easier to review data that is there, than data that isn’t.
You may also run into the issue of hitting a local maximum without knowing it. But realistically, a local max is still an improvement over a local min, and knowing about this phenomenon will allow your team to embrace methods that will push you towards a better max, if possible.
I’d also have in-depth conversations with people who are interested in your product. Many people in startup culture know the basic description of UX and data analytics, but less than you’d think actually know how to leverage or interpret them.
You’ll want to know from the users’ mouths what they do and don’t like about your idea. At early stages, this kind of feedback is much easier to interpret. You don’t have to treat this feedback like dogma, but without it, you will be moving in the dark, armed with only your opinions of what is going on inside of other people’s heads.
My favorite anecdote was one my boss told me. I related this exact problem to him, and he said “Look. If one day, we learn that some disease comes along and kills everybody who can’t stand on their heads, we suddenly learn that we should have been practicing standing on our heads the whole time instead of running this company, we’re all going to be dead, because how would we ever have been expected to know something like that?” Other people just call that idea a black swan.
There are ways to compensate for black swans, usually erring on the side of complexity. The simplest way I’ve found is just to give yourself more. Order more parts than you need. Order them earlier than you need them. Raise more money. Give your project more flex time. Leave 15 minutes earlier for a meeting than you need.
Hopefully you’ve been doing your best to improve within the circumstances you understand. When a black swan hits, who really knows what will happen, but at least you’ll be prepared enough to scramble.
Trial and error
Learning about search algorithms for computer science is a really interesting way to look at approaching trial and error methods. I won’t go into it, but if you’re so inclined, you can read more here.
Another method we’ve run across is the smorgasbord option, where you literally find every idea, product, or theory you can on your project and try to get them in hand. This method is more common with products as you just buy them and then look at them all when they arrive.
A more focused version, when developing, is the shotgun method, where you choose about 5 versions, try them all in parallel, review and kill two, develop the remaining 3 in parallel, kill 2, and refine the remaining one.
We’ve gone with the shotgun and the smorgasboard methods. Whatever method we happen to choose at the moment, they are coupled with the fact that someone in the company is probably thinking about what ever issue it is we’re trying to solve, so when we have an initial meeting about it, at least one person in the room is willing to start with a wealth of ideas. It’s also easy to restrict input to people who “understand” the problem. However, it’s hard to know who is really going to give that winning piece of advice. We recommend to genuinely listen to and share issues with anyone on the team who is interested.
As a product company, depending on the volume we plan to order in, different designs will make sense. We’ve found that out of 5 or more designs, one will make sense for small production scales. While the other will be made out of completely different materials and make sense for larger production scales.
Because of this, we may put one design on hold for later to revisit when we’re placing larger orders or have better ideas about how to manufacture it.
Record keeping
Duplication of work is not a great thing. It’s a large time waste to have two people solving the same problem concurrently without knowledge of each other. Open communication is a great way to solve this issue in small to mid sized teams.
In many companies, projects change hands more than once. When this happens, it’s really helpful to have documentation of your work. Much of what you do will be esoteric and limited to the framework of the project you are working on. This reason is also why simple problems don’t always have simple solutions.
Keeping records allows you to do many things. You can see if you met deadlines on time. You can see what you thought the problems were going to be versus what they actually were. You can see how much longer the project took than you predicted. You can see projected budget (if you actually set one,) versus real budget. You can see the issues caused by running low on budget. You can have a document that can be passed on to other workers joining the project, reducing their overall learning time and hopefully reducing the likelihood of work duplication. You can use these same project documents in your personal portfolio if allowed by the company. The opportunities for improvement really open up once you start keeping good records.
Defining methods
At this point you should have done enough trial and error that you’ve found certain patterns.
As a company that designs products, we’ve found that we need to take an idea to prototyping phase and then to manufacture. While we’re prototyping, before we try to take it to manufacture, it helps to know what amount we’ll be making, and then consult with someone who specializes in manufacturing techniques (an industrial designer, or potential manufacturers themselves,) which allows us to understand what materials we should be working with, what production techniques are available, and the overall cost differences between each idea we have. This allows us to spend a bit more time at the drawing board in exchange for spending less in a meeting room with manufacturers, thus getting our product on the road a little bit faster.
That’s an example of a method. You will find your own if you look back at what you’ve done. Once you’re aware of your methods, you can refine them on future endeavors.
Redoing everything when you try to ship
Normally when you try to ship, if you aren’t super familiar with every process available, you’ll make some mistakes which manufacturers, subcontractors, designers, UX designers, etc, will tell you you are making. It’s very prudent to listen to these concerns and address as many as possible, provided they are relevant (which they almost always are.) This can be frustrating or scary because you were so close to the finish line, but now it feels like you’re back at the starting line. You aren’t, but it can feel that way.
Shipping anyways
Sometimes, you can get so much feedback that you’d need to double the size of your team to address it all. Sometimes, you are very aware that shipping a product that is a drastic improvement from your previous product is better than never shipping a product that you are constantly perfecting.
Shipping anyways can be easy. If you have a deadline, you hit it and you ship. If you have a bar that you have to achieve that is very obvious and defined, you wait to ship until you hit that bar.
Shipping anyways can be difficult if there are no timelines or rules defining your end result. It helps to show what you’re doing to other people, think about the result of shipping your product (good and bad,) and why you started developing it in the first place.
If you do some meta thinking on why you’re supposed to ship your product, it can make it easier to know when ship time should be.
In conclusion
This is our non-formula for prototyping. Expect it to be fun. Expect it to get hard. Expect it to get confusing. Plan for that. Find people to help when you need it. Don’t worry about your mistakes, but fix them if you can. Get excited and celebrate when you’ve made something you’re truly proud of. It’s no small feat!
