What is a UI prototype and what’s it for?
A UI prototype is a careful mixture of the following:
- a place for developing product concepts with high-fidelity, interactive UI
- a showcase to gather feedback on new products and features
- a transition zone for UI assets and code handed off for deployment
The UI prototype should include high-fidelity UI design delivered with light-weight engineering, extreme agility, extensibility and some codified process. It’s purpose is to bootstrap concepts in the medium intended for delivery. Through trial-and-error, we root out the bad and refine the best ideas. Then, we prep them for handoff to production deployment. While many UI ideas may be iterated and chosen for deployment, others get evaluated but never deployed, thus preserving expensive production personnel and resources exclusively for what the company decides is worth the investment.
Customer Success tool
The UI prototype gets produced much faster than a production deployment. On the heels of roadmap planning, a shorter turnaround for product/feature evaluation can help the Customer Success team further evaluate and optionally engage customers with semi-functional designs. These can be pitched as sneak-peeks at trade shows and in scripted demonstrations.
Engineering transition zone
To develop the UI prototype, the Product Designer works closely with small number of Front-end Developers. The prototype framework provides a transition zone for efficient hand-off of production-ready UI patterns, assets, scripts and components in order to accelerate deployment velocity.
Branches
There ultimately should be two UI prototype branches — one for early concepts and another that is stable and unchanging for an agreed upon interval with the Customer Success team. These intervals do not sync with production deployment sprints, but rather can be scheduled to support conferences and priorities on the CS calendar.
It’s easy to set up repos and branches, so to phase this, we are first working toward an initial prototype area — in particular — to define its technology and structure. A few different possibilities for the prototype framework include:
- a static branch of the production react.js environment. This should be structured to support an MVC boundary, so a skilled designer can quickly extend HTML/CSS views while rapidly stubbing models/controllers for basic routing
- a custom skinned Meteor environment with CRUD capabilities
- a static jekyll build that a designer can bootstrap and manage (to a point) himself
Caveat — Signoff and Internal Agreement
Because a high-fidelity, partially-developed design looks real, it can be confused for finished software — but it isn’t. All internal stakeholders should be aware of and agree to any prototype that will be shared publicly. Great care should be taken to manage information and deployment expectations before sharing a UI prototype.
