Lean Startup Approach
Adopting an iterative form of working means that ideas are tested early and either; refined and put into deployment, or are abandoned before any additional resource is wasted upon them.
By embracing this approach businesses can quickly get a product to market and make changes and additions as and when they are needed, addressing the features that users value most. This differs from more traditional approaches where a full list of objectives is drawn up and nothing goes live until every one of them has been met.
Ever increasing speed of change both in technology and the world around us has led this traditional approach to become outdated as often the product is redundant as soon as it is launched and if not, the rigid approach to development means that features often haven’t been road-tested enough to fulfill their objectives or have missed the mark entirely.
Getting a prototype, even with a limited feature set, into the hands of the end user early is the only real true test of whether what you have developed fits their needs.
It helps to zone-in on the features that benefit the user the most without spending time and resource developing elements that might have seemed important to start but in real-life scenarios have limited use. Therefore, as outlined throughout the questions here, our approach to building the new website would encompass a Lean Startup Approach.
Build, Measure, Learn
The fundamental principle behind the lean startup approach exactly matches the purpose of building a prototype.
Build
First you build, whether that’s a design or a development piece and you do this based on the data gathered from talking to you users. You build quickly, embracing code re-use, open source components, visualisation tools and anything else that gets you to a point where the user can experience the build first hand as quickly as possible. You build small, embracing the concept of MVP, testing ideas rather than the complete finalised product.
Once the list of ideas has been formulated we would start to build prototypes in the most applicable way possible, with a view to saving time and development. For many elements we could test early, without the need for coding by bringing together wireframes and design elements and loading these into In-Vision so the user can walk through them. When code is needed we can use plug-ins and pre built components to get working examples together quickly.
Measure
When the build is ready you test it, you try to break it, your users test it and try to break it, all while measuring everything. Using analytics to measure how your users use it and workshops to find out if the users considered it to be a success at meeting their objectives. Where possible you use devices such as eye tracking to give unbiased feedback, telling you what the user doesn’t.
Google Analytics, tracking tags and if possible eye tracking tools will then be put in place while users experiment with the builds. The analytics will show the navigation paths, dwell time and areas of confusion, while the eye tracking can be used to further enhance this data, showing which areas caught the users attention at first glance and measuring how long it took for the users eye to pick up each bit of information.
Workshops can then be performed to give the users a voice and tell us about the experience and what their thoughts are on the successfulness of the build.
Learn
Once the testing is over you use the data to draw up conclusions about what worked and what didn’t work. You look at how the build can be improved or whether it needs to be completely re-thought out and you use these learnings to form new ideas to go back to the build stage to iterate.
Using all this data we would then make improvements to builds that were close to being successful and if needed completely re-think others based on the users experience and what the data tells us. This would be taken back into a new build iteration. Ideas what worked well can be refined and pushed forward to form candidate releases.