There are some voices today who say you should skip prototyping and just start building. Particularly with frameworks such as Bootstrap, coding up responsive layouts is quicker than it was before these libraries were available. While I’ll avoid saying ‘always’ or ‘never’, I will say the vast majority of the time, it pays to use a rapid prototyping tool instead of just starting to code. Here are my main reasons:
1) Coding is always slower. I don’t care how fast of a coder you are, using ProtoShare’s drag and drop interface with a bunch of pre-built templates is much faster than slinging code. I’ve written a decent number of Bootstrap layouts, and while they are pretty reasonable to create, it still takes time to tweak your columns, adjust your content and get everything working the way you want it.
2) Coding locks you in, fast. When you invest time building and testing a coded prototype, it gets harder and harder to step back and take a brand new approach. Radical changes mean starting from scratch. Even if coding were only a small fraction harder than using ProtoShare, over many iterations, the weight of that effort builds up, and you end up defending the existing code over solving other user experiences issues.
3) It’s way easier than you think to break responsive frameworks. Once you’re in Bootstrap tweaking, overriding styles, adding and stripping out various functionality, it’s pretty easy to mangle the different breakpoints. When you do, you’ll spend time fixing the issues at every conceivable breakpoint.
4) Coding freezes out your non-coding partners. When the prototyping process is open to more than just developers, you empower your UX’ers, designers and other stakeholders to really get involved in the process.
5) If you’re using ProtoShare, you can lend your technical expertise to non-coders. Educating all of your stakeholders about what’s easy, what’s hard and what’s possible on a project allows them to make better decisions about what solutions to settle on. It’s a great opportunity to raise the level of your team, and it’s faster and more productive than trying to teach them to code.
6) You’re going to throw away 90% of the code you write anyway. If the extra effort of coding meant you pushed the final coded prototype right to production, it would be hard to argue that the extra effort wouldn’t be worth it. But you won’t. First of all, you’re iterating, so you will consciously dump much of your work. Secondly, you’re trying to build and iterate fast, which leads to (justifiably) cutting corners. Realistically, you’ll either need a major clean-up effort when you’re done, or you’ll just re-implement the solution from scratch.
I’m not saying that you should never ‘prototype’ in code. We do it all the time. But we do it after we’ve ideated, collaborated, prototyped, tested, iterated, reviewed and reworked. Then we code, test and iterate some more. The purpose of prototyping isn’t to completely eliminate any rework or iteration in the build phase, its to minimize it. By using ProtoShare, and iterating and collaborating early, you’ll eliminate hours, days or weeks of effort spent carefully crafting the wrong solution.