This is always a good question to ensure you understand the prototype creation steps. There are several steps to go through to ensure it’s effective and gives it the best chance of succeeding.
Step 1: Define the Scope
Step 2: Gather Research and Insights
Step 3: Concept Creation
Step 4: Creative Design
Step 5: Feedback
Step 6: Enhancement
Step 7: Completed development
That is an excellent question. It can depend a lot on the scope of the prototype. Prototypes can range from a mostly static website to a fully functioning cloud platform with serverless functions, docker containers, data processing platforms and similar. So, it can take much work to put a number on it.
At Concept To Cloud, though, we offer some fixed-price packages to ensure no hidden development costs. These allow us to build quickly and effectively, ensuring our customers get maximum value for their money
Traditionally, if we said low fidelity, medium fidelity and high fidelity, you’d think we’d be talking about physical products of websites. But the same applies to building cloud-based application prototypes as well. How much functionality do you require to make the prototype viable?
Low Fidelity
This is the lowest cost but also the absolute basics. It is a very rough application, a basic cloud deployment. Enough to show its viability and gather some feedback, but not much more.
Medium Fidelity
A medium-fidelity prototype attempts to balance cost, time and functionality. More user interactions are built out, and the cloud backend is more fleshed out and designed for scale and flexibility, but it still needs to be feature-complete. Design patterns, interfaces, and interactions might need more work.
High Fidelity
Finally, a high-fidelity mockup is designed to be close to the real thing. With a structured and scalable backend, most user interactions, website assets and the like are in place. When put in front of test users, they shouldn’t be able to tell this isn’t a fully functioning product. Of course, the trade-off here is that it costs the most. The feedback may mean there are decisions to be made about reworking it, so we’d only recommend a high-fidelity prototype if the customer is sure their structure and framework for the product aren’t likely to change massively after some end-user testing.
Wireframes
Unless you’re a UX expert, I wouldn’t recommend trying to design a fully functioning UI in Figma or wherever. Still, it certainly doesn’t hurt to attempt to mock one up. There are a variety of ways. Figma is great but more complex than it needs to be. Often, a sketch on a piece of paper with annotations around it is enough to get started and give you something to build towards. The same for the backend, paper, Google Draw, Draw.io or Lucid Charts are all great ways to sketch out what the backend data processing and storage layers might look like.
Web Framework
This will be an important consideration if your application has a web frontend. Again, it depends on whether you’re comfortable writing web applications because things can get ugly quickly! Even if you’re not a web developer, you’ve probably heard of React, so that sounds like a great place to start, right? I suggest you go for something easier to get going. We’ve had great success with Svelte for web development, but that’s still complex. If you’re used to programming in Python, there are even non-HTML-based frameworks to get you going. For example, if you’re building a dashboard for data output, using Plotly Dash to create and render charts on a page is a great starting point.
Programming Language
What language do you use? Often, the question is, what are you most comfortable using? It’s a prototype, so we can make life easy here. If you’re happy writing Javascript, consider a backend written using NodeJS. If you’re a Python developer, that’s cool; there are plenty of frameworks to build applications quickly and easily using Python. Of course, this also impacts the cloud level; if you’re using Lambda functions or similar, you can leverage these same languages there.
Choice of Cloud and Services
Which cloud service do you use? Well, do you already use one? Chances are for a prototype and build out to production if you’re happy with it, it’s okay. You might think twice if you’ve got some specific integration requirements, a service only provided by one provider, or some data locality issues or similar. In this case, find one that works for you. But all the mainstream providers are acceptable, along with some of the lesser-known, more local ones like Scaleway, with whom we enjoy working.
Everything as code
You may think this is overkill, but in the future, you will understand. Try to deploy your infrastructure using code, try to do your builds using code, and write your apps using co… oh! Anyway, you get the idea. The reason is that there may be a time between building the prototype and getting it to the point of MVP and on to production, and remembering how you configured your cloud services, ran the build to get the container built and so on is essential. It may take a little longer in the bootstrap process but try to use code for all your workflows, so when you come back, 6 or 12 months down the line, it all continues to work how you left it. You can also read and document the code very effectively.
Moving on from prototype to product does depend on several factors, the feedback from users being at the top of that list. If the feedback is positive, the changes required are small; further iterations will likely be necessary if the feedback is positive. Also, we’ve spoken earlier about the prototype’s fidelity; another aspect of turning it into a product will be how much was implemented in the prototype phase.
Usually, the next step on the roadmap will be a Minimum Viable Product(MVP); this will implement all the significant features required for launch and have a fully functional backend and deployment strategy. This will then go through another round of user testing, and assuming that feedback is positive, the product can be launched.
That depends on the complexity. Generally speaking, the period should be between 3 and 10 months, depending on the features and complexity required to get it to MVP state. This includes design, prototyping, feedback iterations, and then the MVP deployment.
Prototype to production involves determining the flaws in usability and scalability, deployment, build, testing, etc. You don’t want to crowbar your prototype into a live environment and then find yourself in a position where you need to upgrade but can’t. So, plan out what the development and release cycle looks like. Load test the backend, understand what load it can cope with vs. what you expect, and make changes if necessary.
Also, think about it from a security perspective. You’ve been testing with “friendly” users until now when the rest of the world can get access; how secure is your application from attack?
It’s not usually; the clue is in the name! But it might be close depending on your requirements. Generally, once you’ve built a prototype, you’d then iterate on it to reach the MVP stage, and from MVP, you might end with a finished product.
Just like the question about what makes a prototype, the same can be asked about how you get from a prototype which you’re happy with through to production.
Prototype
You’ve built a prototype; it’s up and running and accessible, and you feel ready for testing and feedback.
Feedback
Next, we’re onto the feedback stage. You want to give users access to a controlled environment, guide them through it, and ensure they understand what to expect and what not to expect. Get their feedback, first impressions, and understanding of how they found the prototype, what they found easy and challenging, and how they would do things differently. You don’t have to implement all the responses, but at least getting a feel for what the majority think is essential.
Iterate
Once you’ve got some feedback, we’re in a feedback – iteration loop. Improve your prototype, get feedback, iterate, and continue until you feel like the product is getting close to being viable.
MVP
Once you’re happy with the testing and feedback, stability and design, you’re then entering the MVP phase. This might be a release; it might be just a transition. But at this point, you’re looking for more feedback from a wider pool of users to ensure that the changes you’ve made are what they should be doing over a more extensive sample set. Get the feedback, and go through a few releases to ensure it’s working as you anticipate.
Scale/Load Testing
Before we reach production, we have a few more tasks. First, we must ensure the platform performs under the expected load and beyond. There are several services out there to simulate users; we can see how the platform performs; do we need to implement more cloud services to deal with auto-scaling? Does it serve the load fine, but are you overpaying for hardware that isn’t going to get used? There’s a balancing act there.
Security Audit
Finally, before you hit production, make sure the thing is secure. Get it audited by someone who understands security audits. Ensure your cloud services follow best practices, your APIs are secure and so on. If you can outsource security for your product, I recommend it; there are many platforms out there, perhaps hosted by your cloud provider, that eliminates the need to deal with your application security in most cases.
Production
Finally, get the release into production, ensure all the automation is working. The procedures are documented and protocols are in place to deal with user questions, bug reports, feedback, support, and so on.
Hopefully, it’s approaching the finished product, but only sometimes. A good prototype will give testers a feel for how the product will work, the interactions that will take place with the application and, on some level, the look and feel. But in reality, if the web interface is very complex, you may only end up with a wireframe UI, or perhaps even a CLI, whilst you gain feedback on the product’s viability before embarking on a build-out of the user interface.
