Iterative improvement in interface design
Push something out early. Let it runs for a week (or two). Analyze users reaction using a combination of internal and analytic data. Focus on a metric you are trying to improve (sign up conversion, user activity, time on site stats and etc). Work on an improved version based on the data. Let the new version runs for another full week or two. Repeat the process.
It is much easier to do iterative improvement in the early stage of a development cycle. When you already have an established size of userbase (ie. Facebook, Gmail), it’s much harder to iterate interface changes without throwing off some users especially when the new version delivers significant aesthetic and functional differences than the old one.
There are usually 2 solutions to this problem: bucket and parallel testing. Bucket testing involves showing a small portion of your userbase (randomly picked or based on specific/demographic data) the new interface. Parallel testing means running both versions of the interface to different type of users right from the start. The cons of bucket is that you only get a small sample of representative data from the test. Sometimes that is enough to justify certain design decisions. The cons of parallel is users confusion might arise. It’s not uncommon we get instances where user A try to explain to user B where and how to complete a task but parallel testing means that they might get different version of the same interface.
Some call iterative improvement an agile work flow. Others call it AB testing. Regardless of the term, interface design should not be a static process. Constant studying of user behavior helps evolve an interface to better meets its functional goal.
The early version of plurk’s post-register screen displayed a list of recommended plurkers. As shown above, we displayed a list of thumbnails, names and check boxes.
In an attempt to simplify the interface, we removed the names and enlarged the size of thumbnails. People judge by looks most of the time. Sad but true.
Turns out users want to know more about the people they are about to follow. Name might not be important, but age, location and gender are. So we included that in the final iteration.