Startups are notorious for bringing an idea from a concept to a finalized product fast.

While there’s certainly something to be said for taking our time and doing in depth research at every milestone, sometimes we just need to get an idea up and running as soon as possible.

Rapid prototyping in a startup culture slims the typical design and development process to hit the high points and retouch the lows after the fact. We can learn a lot from this methodology and apply it directly to our own work, even if that work isn’t for a startup.

Strangely enough, this methodology often requires less doing, and a lot more thinking and planning.

Outline everything, seriously… everything.

Rapid prototyping has traditionally referred to the trial runs and testing of products before they’re sent to mass production for the general consumer. We’re going to aim for something similar here with this approach, but with the idea of keeping design and development time to a minimum.

In order for this to work, we must have a clear idea of what we’re building, and why it’s being built. Feature creep can easily kill off your ideas by sheer complexity alone, so we’ll want to keep things minimal and barebones for our core product.

Strip away your idea until it’s purely a product name and a single core feature. (What is the problem you’re trying to solve?) Then build around that. You can add more core features if absolutely necessary, but just know that additional features will add even more complexity into your outline.

It’s always better to do one thing elegantly and well, rather than doing five things poorly.

Branching out and growing your product

Now that you have a core to focus on, you can begin adding in the more specific features. Branching out means these features are not essential for the product’s main focus, but add value in their existence. These “branches” are add-ons, additional tidbits that add interest and eventually become selling points that separate you from the competition.

But while they certainly add interest or value, they also add on R&D time as well, so keep that in mind. You’ll want to thrown in enough to fuel future design and development, but not so many as to make your outline look like a spider web.

Speaking of spider webs, they’re a fantastic way to visually outline this data. In the center, you have your core purpose. Adding an additional ring of features outside the core are your most important non-essential features. Each ring after that grow less and less important. Using this idea to visually outline your product can help organize it in a more natural manner – with the focus flowing from most to least important elements.

Develop an MVP and run with it

Your minimum viable product (MVP) is the very essence of your product. It and it alone is the core and main focus from which everything else branches off.

Remember that outline you likely spent days or weeks on? Ignore everything else right now except the things needed to make your product functional. This, is truly a minimum viable product. What you’ll end up with is not only a to-do list to get the most functionally basic product possible, but also a clear outline of features to focus on after, as well as a general idea of what to expect even farther down the road. The idea here is to have a road map for design and development for the next year or more. By the time you near the end of this outline, your product will either have matured enough to have a clear direction with which to build more on, or you’ll have seen what did and didn’t work from your outline and adjusted accordingly.

Plan and outline now, design and develop while running — that’s the key.

Now is also the time to do light research into what technologies and practices you would use to flesh out this idea of yours — including some of the farther out features. This could only involve you, or it may require an entire team to discuss options and settle on what would be best. It’s important to do your research after planning a MVP so that everyone from design to development has a clear idea what to expect. Not only focusing on the core, but also looking at the farther out branches and ensuring to plan for those as well. After all, there’s nothing worse than getting six months into development only to realize nobody planned for a highly anticipated, but non-essential, feature…

High fidelity can starve you, low fidelity can mislead you

Everyone loves the beautiful high fidelity mockups posted on Dribbble or in designers’ portfolios. It would be amazing to work off something of that clarity for all products too. But usually those mockups take weeks, if not months, of work and iteration to get to that level of fidelity. Even then, sometimes those mockups are more focused on aesthetics than any data driven analytics or user data.

While super high fidelity is obviously out of the question, low fidelity sketches are still an option right? Well, most likely not. Show a few sketches on napkins to a developer and they’ll have no clue how your product will look or more importantly how it will feel to use.

Medium fidelity is generally the right answer for a rapid design and development environment. Pair this with the textual outline generated above and both sides here should have a good understanding of the UX behind features.

Medium fidelity still generates mockups, but more granular elements are bootstrapped by using existing research or use patterns, not based on custom research of previous user analytics or A/B testing.