The ability to quickly test ideas via functional prototypes, can boost your overall innovation performance. Read on to discover how to achieve this rapid prototyping readiness.
The readiness to capture and evaluate new ideas at pace, is a prerequisite for real innovation: having all those great ideas means nothing if you don’t have the proper framework to quickly test them, expose them to the right audience and get feedback. Yes, you can use static wire-frames and storyboards, but in most of the cases a functional, realistic prototype provides a far more solid basis for evaluation — and also the means for engineering insights on feasibility, architectural options and implementation strategies.
To achieve this fast-pace prototyping readiness, you need [a] the right development approach and [b] a repository of resources (standardized code libraries, components, UI elements, data models, APIs etc.) which are easily discoverable and usable as potential building blocks of new applications.
1. From an idea to a functional prototype
When receiving a request to prototype a new concept, always start by analyzing its validity: is the idea well-defined with a solid problem statement and defined outputs? If not, you should push back to the owner and ask for more information.
In an ideal scenario, you need an experienced multidisciplinary team — able to quickly understand the concept, decompose it to functional elements, identify similar projects that can be referenced and existing components that can be reused.
Re-usability is key here, since it can dramatically reduce the time to build your prototype, along with the underlying engineering and development costs. Thus, you should be able to easily discover relevant and potentially reusable components from your ‘prototyping repository’.
Understand the user, set the scope with clarity
The ultimate goal of a rapid prototyping project, is to build a realistic functional instance of the concept, in order to capture feedback and signals from real users; you need to think ‘as a user’ and summarize the scope with clarity — ideally as a short list of well-defined epic user stories.
Make decisions — Build, Reuse or Mock?
When in rapid prototyping mode, it doesn’t make sense to waste resources in building non-critical components and features — for example authentication mechanisms, a login UX or a new ‘visual language’ from scratch.
To drive the discussions on which components to build, you need a functional decomposition of the concept and a high-level, logical architecture. Having that, allows you to iterate over the set of components and query your ‘prototyping repository’ for reusable components encapsulating similar functionality.
From those components that need to be built — no similar components available for reusability in your repository — you must figure out which make sense to develop and which to mock. To do so you should look for the ones that are fundamental for the specific idea — the ones needed to be exposed to real users for feedback. If the purpose of the prototype primarily to test a certain technology or functionality (a proof of concept), the focus area is rather predefined — you can use a ’static data’ approach for everything else.
Make assumptions, move fast
You are aiming for a realistic experience, not for a production-ready system. Your objective is to prove certain technological aspects and capture feedback by exposing a realistic experience. Hence, you can make conventions to accelerate the process — for example, you can eliminate production-related constraints and switch to a lighter version of your software development rules and guidelines.
Quality can be redefined in the context of your prototype, with a bias for UX rather than optimized code or other technical aspects. In general, for a prototype, it should be OK to hard-code and use static data as needed in order to move faster. For instance, as soon as you define your object model, you could generate static JSON objects, to be consumed by your client apps via regular APIs calls; as you move on with your development and where it makes sense, you can take advantage of this abstraction layer and plug in real data connectors, dynamically instantiating your objects and serving them via the same APIs with the same JSON serialization — with no further changes.
Build, capture feedback, iterate
During a rapid prototyping project, it is critical to iterate fast: prepare your data, build a first version of the UI, integrate APIs, offer a basic end-to-end experience and present to stakeholders; process feedback, make sure the focus is right and iterate towards a realistic implementation of the original idea.
2. Setting your ‘prototyping factory’
The ‘prototyping factory’ is particularly useful when you need to streamline your prototyping efforts — for instance if you are operating an innovation lab. Nevertheless, any engineering team can benefit from the following recommendations and achieve a general readiness to rapidly prototype, on demand. Your prototyping factory should provide discoverability of and easy access to the following:
Standardized Data sets
A set of well-understood and documented data sets — real or artificial, internal or public — can accelerate your development process. Your data need to be [a] contextual to your business [b] ready for use — having aspects such as privacy and compliance covered [c] with the desired statistical and other properties to enable realistic user scenarios. In an ideal situation, data sets are summarized via ‘data demographics’ reports — key statistical aspects of the data providing instant understanding and clues on how to use it.
Data models and data processing components
Properly documented data models and object models can be particularly useful for rapid prototyping projects. This could also include data converters, mappers, generators, parsers, ETL pipelines, crawlers and other tools and utilities which could speed up data processing and integration tasks.
A catalogue of APIs
A list of easily discoverable, well-documented APIs, with instructions and ‘quick start guides’ can accelerate the development of your prototype. They could expose functionality across a number of areas which are expected to be common in software products — from authentication and telemetry to data access and even machine learning, content discovery and more. In some cases, APIs could expose real data while in others they could provide static data objects. External APIs could also be listed — to allow integration of 3rd party services.
Software components and Coding Templates
A catalogue of lower-level, software libraries, scripts and templates could significantly increase the pace of the development process. The components could refer to standard functionality or advanced scenarios such as the implementation of special algorithms, or an advanced data processing pipeline.
AI and ML models
In the era of Artificial Intelligence, any new application is expected to leverage a certain type of artificial intelligence or machine learning capability in order to best serve its purpose. And although building new AI/ML models could be challenging and time-consuming, integrating standardized models into your application is easy and straightforward even for non-data scientists. You only need the right collection of APIs or models, each with good enough documentation and guidance for integration.
User Interface libraries & templates
Having a great collection of UI elements and controls to draft your User Interfaces is of critical importance. You need a rich set of reusable, configurable UI elements and frameworks along with tools and platforms enabling sketching and wireframing. Depending on the case, special UI components such as data visualizers, dashboard patterns, interactive charts etc. could also prove to be very helpful.
DevOps, Automation, Monitoring
Releasing, hosting and managing your prototype throughout its lifecycle, should also be fast and efficient. This requires the right tools and processes to automate certain tasks, control access and manage the code repositories. If you are systematically producing prototypes, you need a repository for the prototypes themselves — to enable discoverability, analysis of usage patterns, feedback and a range of metadata.