If anything the last few years of ‘Web 2.0′ have taught us is that users appreciate simple sites even more than designers. This lesson even held true in the pre-web 2.0 era, tho it required somewhat of a cultural development shift to get there.
Google was the first really ’successful’ company to adopt the simple site approach. Yahoo was the big dog on the block with it’s dramatically complex presentations and homepage, exposing all of the information about the nuts and bolts of the machine along with the attempt to force feed users associated content at the search box and home page.
Intentional or not, Google figured out the one cardinal rule of web development. Users visit sites with a task in mind, and that task is often singular. No matter what the site or application, users don’t spend time exploring, unless your site keeps a tight narrow focus. Users who land on a site looking for information about racing will spend more time exploring your site if it has a focus on racing, less time exploring of racing is just one component of a multi-focus site. Search results have conditioned users to expect results to be single page only, with little related information if any.
Developers and designers have a great deal of trouble scaling back ideas to fit into this singular focus approach and filtering out the noise. Most of it has to do with the brainstorming at the beginning of the project. When an idea sparks, random thoughts are encouraged in brainstorms or while the idea is being developed. But before development begins, teams need to spend time performing a reality check, not only in regard to the scope of the development, but about what ideas are included.
The scope of the project to the first milestone is a great barometer of success. Ideas that keep development as tightly focused as the idea tend to produce better products and better code. Projects where developers are scattered, attempting to work on multiple facets of a system simultaneously are a good indicator that the project lacks focus. Attempting to narrow the scope during development is nearly impossible, and almost always results in missed deadlines and backwards development.
Successful projects focus on the idea most commonly found in development for social networks where releases focus on minor features and continuous integration and release. Plan schedules around minor features, not major ones. If a feature can’t be paired down to a series of minor releasable features, it should either be considered a separate project outside of the current scope, or be refactored before development begins. Even beyond this, each complete minor feature should be considered a full release. That might mean that you’re releasing new features each week, and honestly, that’s okay. Users adapt to incremental changes in a far more flexible way than large scale changes, particularly in the flow of your site.
Happy, focused developers tend to lend to happy, focused users and user experiences.
