The new web project starts and everyone is excited about what could be. The business stakeholders, the various project teams, the vendors, they all march to the same drum as the excitement builds. This is great. A common vision, teams that stand united and a plethora of possibilities at the forefront of everyone's minds. Then it happens. The timeline is long and budget is reasonable so all of these folks begin brainstorming on what can be built; however, they haven't investigated what needs to be built, nor do they understand for whom it is being built.
So let's pretend for a moment this team enters into the process of understanding their audience, conducts user research, identifies personas, etc. Now they know what needs to be built. Right? The teams begin working feverishly to identify requirements, functions, features and start prioritizing based on feasibility and usability. But, the problem remains...
Days go by, then weeks, then months and still, the teams are working on requirements, holding work sessions, creating models and attempting to solidify this new web offering. What seems to escape them is the need to 'keep it simple, stupid'. I know it's not the most tactful phrase used today, but it should be at the heart of the project. The concept of simplicity gets lost. After all, offering more is better. Add this feature here and that feature there and pretty soon your concept is clouded by a bloated list of features and functions that, most likely, won't be used by anyone.
The advice of the day is to stop building everything and start building what matters. Do you really need all the bells and whistles? It is more important to launch half the product and do it very well than trying to accomplish so much you half-ass your way through building the product. You can always add more later. Build what you can, launch what you can and watch how users engage. You can always add on after you see how your product is used.
Have you experienced projects that focus on feature-bloat?
No comments:
Post a Comment