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.

Design and development doesn’t have shortcuts

The most important note to make here is that there are no shortcuts. Nobody can skimp out on design or development time and have it go unnoticed. While we can stick to common use cases and implement popular code libraries to solve the problems of today most, if not all, products stand to benefit from some one on one attention in both design and development. Rapid design and development methodologies are taking the traditionally more custom approach in these areas and cutting things down to be revisited later. It’s expected that products are revisited to give the proper attention to design, and to optimize or even run with a more custom developed solution. So while we can save on time and resources today by taking a more rapid or agile approach to our workflow, it should always be with the expectation that we revisit things after the fact to ensure our work is solid. Once the core is complete, revisit and customize. When the next round of non-essential features are complete, revisit and customize. Generally, this only requires front-end work and not a complete redevelopment of the back end code. So it’s typically limited to the positioning, color, size, or other aesthetic attributes of elements. Development wise, revisiting here simply means optimizing code to run for performance.

Tick, tock goes the cycle

Going with a “tick, tock” style cycle for revisiting our rapid design and development solutions is the best way to approach revisiting in my experience. While development is working on fleshing out the next batch of features, design can review the last batch to make sure everything holds up or vice versa. At any given time, either design or development is one cycle ahead of the other, and the other is reviewing. During this process, both teams work together not only to review, but also to push out the next batch as well.

Rapid design methodologies are hard

Development can usually get by with using existing libraries or open source solutions to flesh out product ideas. But when it comes to design, it’s much harder to cut things back or outsource them to existing solutions. Design by nature is more one-on-one than development and if you’re in a niche industry it’s going to be hard, if not impossible, to find similar use cases to base work on. Design is one of those areas where the more you cut out, the more quality you’re going to lose in the end. User experience and aesthetics play a very large role in how well a product “works”.

Wrapping things up

In the end, we should find ourselves with solid products that stand tall against competitors who engaged in the more traditional “slow” design and development processes. The goal isn’t to skip out on parts of R&D entirely, but to file them away to take care of later once we have more data about our users and how they use our product. Rapid prototyping can get you to a MVP and beyond in a fraction of the time it would take traditionally, but take care you don’t confuse it with cutting-corners.