Rapid Prototyping with Code
The reasons why I haven’t experienced FOMO with prototyping tools
There are so many prototyping tools around today, it’s become a somewhat daunting task to even pick one. Then, of course, you have to figure out how to use it and maintain what you’ve created. Following a few sketches perhaps, the humble browser has always been my goto place for prototyping. Using simple HTML, CSS and JavaScript. As a former Front-end Developer and now Creative Technologist, I’ve found it more than just a way to communicate and test an idea. I’ve also learnt a few key things about prototyping along the way.
High fidelity often isn’t required to get valuable insight
One thing most prototyping tools have in common (there are, of course, exceptions) is that they will often lead you down a road of creating visually stunning, interactive prototypes that usually follow the latest trendy design patterns. This is great for wowing stakeholders, investors and sometimes your peers but, when it comes to user testing, it mainly just acts as a distraction to the simple fact that “this is not real”. Dummy data, non-functional UI and often verbal instruction during testing can somewhat ruin the experience.
On some recent prototypes I worked on, capturing and relaying real data, in a format that made sense, was the real star of the show. Both our client’s colleagues and their customers were users. Whilst we applied many best practises in terms of UX and code, the apps were not what you might call beautiful. I was nervous that some pages were too bare bones, but to my surprise, no colleagues or customers commented on that. Instead, the focus was on the experience of performing a task that was not possible just a few weeks earlier. Real data in real time seemed to supersede everything.
Adding value > maintainability + scalability
Having previously spent years writing mainly production ready code, I quickly learnt that prototyping requires a totally different mindset. It’s very easy to choose which tools, packages, frameworks etc you are going to use — the ones you are most familiar with. Use the limited time you have to create a more meaningful experience for the user, not a personal playground to try out new tech.
It’s also important to resist the urge to over-engineer or refactor code unnecessarily. There’s definitely an art to this though. Code has to be somewhat maintainable in order to respond to changes from user feedback or new information. But overthinking things and fussing over architecture is likely going to distract you from solving real problems. Less thinking and more doing is generally the way to go.
Document your discoveries whilst making a prototype
The thing that surprised me most about writing code, rather than making a typical “clickable” prototype, is that you’ll find yourself immersed in the ecosystem which production developers may be working with in the future. Whilst it may not be true for every project, in my case I learnt a lot about health devices and their respective APIs, JavaScript graph/chart packages and video chat solutions. It can provide valuable insight into the feasibility of a project, especially if stepping into somewhat unknown territory. I’ve also noticed that too often Design/UX specialists care less about what data is available and how to deal with situations where things stray away from the best case scenario (error messages, initial states and loading states, for example). Also, it’s often assumed that accessibility is out of scope for prototyping. But in reality it’s never too early to at least start thinking about these things or perhaps test them with real users. The more you discover at the very start, the better.
In summary
Don’t be pressured into creating something that is high fidelity or trendy, especially if the goal is to validate a proposal with real users. They’ll forgive you if it’s rough around the edges but solves their problems - wonky but real is more profound than conceptual eye candy!
Avoid overthinking the nitty gritty of the code in your prototype. Make your code somewhat maintainable so you can respond quickly to sudden change requests and user feedback. But don’t over engineer things or refactor for the sake of it - your users won’t care and you can spend time adding real value instead.
If you’re aware that your project is likely to need 3rd party devices or APIs, then I’d go as far as to say that a code prototype is essential very early on. You’ll learn so much about the feasibility and viability of the proposal. If the proposition scales to a production project then your findings could really help steer things in the right direction.
There’s no doubt that prototyping tools are becoming better. For example, Framer X using React, is definitely something I’d like to try out. Also, Adobe XD seems to offer some interesting JSON import features. However, assuming I’m faced with similar prototyping projects in the future, I don’t think there’s enough on offer to convince me just yet.
Finally, in case you’re not from a development background and think coding isn’t for you, I’ll just leave this here.
