Large websites and the importance of a prototype
It’s been about a year since we started changing the way we approach projects. Introducing change to any long-standing process is difficult and takes commitment, a willingness to learn, and the ability to accept (and correct) mistakes. Focusing our efforts on creating prototypes for everything we do, and evolving those prototypes on a sprint-by-sprint basis, hasn’t been perfect. But by choosing progress over perfection we’re finally seeing results.
The research we perform helps inform what the prototype (and ultimately the product) should do from a task perspective. Research can include in-person sessions, analytics reviews, and benchmark usability testing.
Prototypes are usable, design-complete products intended to represent a predetermined user journey or series of tasks. We arrive at all versions of a prototype through wireframing and the direction set through research findings. On the web a prototype is a series of linked and interactive screens built in responsive front-end code. For mobile applications a prototype is a similar series of linked screens with interaction applied using a prototyping tool such as Marvel.
The websites and applications we build are large. Creating them through a process that results in a large body of unvalidated work prior to launch was becoming problematic. Too much to review and too many assumptions. Showing design in a static format when it’s never intended to be experienced that way is a little counter-productive.
Though largely reserved for products (which we build), the idea of arriving at a prototype quickly seemed to make sense for large, content-heavy websites too. Building on the tenants of Lean UX we stopped producing wasteful documentation and used outcomes, research, wireframes, prototypes, and usability testing (in that order) to let an early iteration of the project define what the project should be. We avoid showing clients static concepts in favour of functional prototypes with a proposed final interface applied. It’s something real, delivered much earlier than usual.
To keep our efforts (and the efforts of our clients) focused we release updated versions of the prototype prior to a development sprint. The prototype illustrates the functionality of the sprint and allows us to validate our assumptions prior to the build.
A prototype is great for validating assumptions through usability testing, giving clients and the entire project team a sense of direction very early on, allowing developers to work with markup and understand how an interface should work before building functionality, and putting emphasis on functioning mobile views prior to development.
Having performed usability testing with wireframes I’m pleased to not have to explain to test subjects the concept of a wireframe and then have them use it.
There isn’t much here. The biggest hurdle we’ve encountered is educating our clients on what a prototype is and why it’s important. For large websites, this approach requires a significant amount of front-end development resources at the beginning of each sprint. The benefit here is that there are far fewer ‘design clean-ups’ needed prior to launch.
So, there it is. Nothing revolutionary, but when practiced properly the idea of arriving at a prototype quickly, especially on projects like large websites, is showing a huge up-side.