Need to build a functional prototype? We’ve all been there, struck with a great idea for a software product, but no clear direction to start the development process. How does your idea for a new product help solve real problems? How do you define the desired product throughout the solution discovery process? What are the project requirements and objectives? As a technical staff augmentation and custom software development company with expertise in providing answers to these questions to companies of all sizes, we’re here to provide some guidance.
Assessing Product Opportunities
Before starting a functional prototype project, it’s necessary to assess product opportunities. This assessment is needed to answer the following fundamental questions:
- What problem will the product solve?
- Who is this product for?
- How big is the potential market size?
- How will you measure success?
- What competitive products are already on the market?
- What differentiates us from competitors?
- Why the product should be created now?
- What is the proposed strategy for going to the market with this product?
- What factors are critical for success?
After answering these questions, it will be possible to decide whether or not it’s worth starting product development or building a functional prototype.
Defining the Product
You’ve decided to move on product development, now what? It’s time to define what will the product look like. First of all, we recommend validating your idea with potential customers using a functional prototype. After that, you can start with product discovery.
Product Principles
Define the importance of your product — a set of values that should be shared across all the team members. These are the core principles that should always be kept in mind. Several examples:
- Our product for talent acquisition aims to completely replace disparate workflows and multiple external services used by HRs to fulfill their tasks. So we need to identify what is required by HRs and implement it leaving no gaps.
- Our photo sharing site’s main value is to quickly share the most important moments of your life with a single click. So let’s figure out how to streamline that process.
- Buying goods on our site should be protected by powerful security measures. Every piece of functionality should be carefully checked for possible attacks.
- Our predictive analytics software should always identify possible bad input data before proceeding with calculations. In every place where we start the calculations, there should be extensive validation of input data with meaningful error messages.
- The content of our entertainment site should mostly be driven by personal preferences of the users. Users will need extensive voting/rating system for every content item, and we should take into account their content views, calculate statistics, widgets, etc.
Learn About Your Customers
Before finalizing product ideas, it’s always a good idea to validate them with real users. Using focus groups are well defined in books and articles. However, in our experience, there are a few drawbacks. The main drawback is that users usually don’t know what they want until they see something live.
The other approach — early adopters — proved to be very useful for us. We make sure that we solve real problems for real users by building products with their interests in mind. This could lead to loyal customers, with the opportunity to refer them to promote your product. A common pitfall of this, however, would be making your product only for a limited set of customers — so be wary of this.
Product Specifications
Now that you have clear vision of your product, it’s time to create specifications that can be handled by a development team. We suggest not investing too much time creating heavyweight product requirement documents. It can be waste of time for several reasons:
- They will require a very long time to create.
- Too few people will read them.
- Too much effort to keep them up to date.
Instead we propose…
- Creating easily updated and shared documentation covering the behavior of the new product.
- Paying attention to UI/UX. Oftentimes, visual representation tells more than several pages of text.
- Putting the documentation into some collaborative tool (for example, wiki). It will be easy to answer questions there and track the history of changes.
- Creating a backlog of high-level user feedback that, on initial stage, will only serve for release planning. Users would refer to the documentation. During the construction phase, they will contain more details on requirements and acceptance criteria.
- Prioritize user feedback and define what will go into Minimum Viable Product (MVP).
- Investing in a prototype.
Usually people think of functional prototypes as fake UI that demonstrates wireframes, user experience, and conveys information on how a user is supposed to interact with the product. There are many quick prototyping tools on the market. These tools allow for quick sketches of wireframes and sometimes simulate page transitions so that when a user clicks a button, it makes the transition.
Additional tips…
- After confirming UX ideas, we transition to applying the design. Usually, this is done by converting it to HTML, and adding styles and artwork.
- Then we make the prototype reactive.
Build a Functional Prototype
The idea of reactive prototypes is to create an engaging user interface and user experience (UI/UX) for your web product that will be as close to a real product as possible. Essentially, it will have all the pages, their transitions, and the dynamic-rich interface elements. This will be a completely finished UI without any back-end functionality. It will have the final styling, all the visual effects, and client side logic for accepting and validating inputs.
Usually we even save entered data on pages to demonstrate users’ interaction with the future application. This is the first construction phase of project and it serves as inputs for following phases.
There’s a very important difference of functional prototypes. “Regular” prototypes are throw away artifacts. They only serve for requirement discussions and as a supplementary for user feedback. Reactive prototype is a functionality that will be extended by adding real logic on server side.
There are many benefits to making functional prototypes:
- Making UI is faster compared to business logic on back-end — thus, any rework will be faster.
- By completing a reactive prototype, you will have UI that will be tested (to a certain extent) and demonstrated to stakeholders. It will be probably reworked, but at the end of the day, you will have UI that is at least validated by your stakeholders.
- Working on UI will help to define detail API interface requirements for back-end developers making the prototype, and will facilitate achieving clean and simple architecture with clear separation of concerns between components.
- Usually, front-end developers do UI and back-end is done by business logic developers. This means that each part of application will be implemented by the people who are best suited for it.
- In case of software development outsourcing, it will help you to minimize “round trips” with your vendor on later stages of product implementation. Of course, the vendor needs to adopt this idea.
Important note: UI efforts don’t stop after the reactive prototype phase. There’s still some feedback, bugs, testing, refactoring, and other inputs leading to changes in UI code. However, user interactions will not be considerably changed because we have already passed this stage. Why? Because most changes were already made during the reactive prototype phase. It may sound waterfall-ish, but it’s not. In fact, your first phase consisted of multiple iterations and was finished with UI that was demonstrated to and approved by stakeholders after elaboration of their feedback.
Again, there’s no illusion that UI is fixed after the first stage. Even without mentioning bug fixes and refactoring, when real business logic is gradually implemented, it will probably be needed to have some rework of the UI. On the other hand, the most painful UI rework has already occurred, and it was faster and simpler because it only required UI changes.
Reactive Prototype Tools
In order to build a functional prototype, front-end developers can use modern JavaScript frameworks and libraries that are used nowadays to build rich UI applications. Single Page Application approach also has its benefits.
At Sphere Software, we believe that there’s no ideal tool for every application. Depending on client needs, we use the following front end libraries: jQuery, Angular.js, Polymer, Ember.js, Backbone.js. Client-side functionality usually has “stubs” for API requests that mock API calls. Most changes made are stored in local models. This allows for showing information as if it’s retrieved from server API. Sometimes developers feel that it’s easier for them to make mock web service API on back-end. It’s fine to do this, but keep an understanding that web service layer will be completely rewritten after the reactive prototype is approved.
Don’t forget about automated tests for UI. We employ unit tests (like Jasmine) and functional tests which use browser (like Capybara). Follow best development practices that require separation of HTML and JavaScript code. It will help you to have full test coverage of all dynamic functionality in the application.
Prototype Validation
Before starting the costly implementation process, it always makes sense to validate your ideas. There are several kinds of validation:
- Technical validation will decide whether or not it’s possible to build this product in a given time period with your funding. Can your ideas be implemented from technical perspective? Sometimes, spending time on this preliminary research can help to avoid costly mistakes in future.
- UX check. Check your prototype with real users and get their feedback. Is it convenient? Are they excited about the future product? This way you can uncover gaps in your specification.
- Check if potential users are really ready to buy your product for the planned price. Sometimes this can lead you to think about different product editions or the minimum price your company can afford.
Conclusion
We’ve provided advice on how to come up with good product specifications that would be the starting point for your new exciting product. Give it a try, and invest time in evaluating product opportunities, defining what’s really important for your future users, and building a functional prototype. These steps can help your company minimize risks on early stages of product development. Don’t forget that your specification is a live documentation and it will be evolving over time with your product.
Want to learn more about functional prototyping and MVPs, join us at TechDebates and let us hear your thoughts.
