Can a user-centered design approach be integrated into an Agile Methodology?

There are many ‘agile’ development methods that have been leveraged throughout the years. It is a way to limit the traditional ‘waterfall’ approach to projects and work in an iterative approach to delivery. To put it simply it is a way to fit the software development life-cycle into a box while promoting teamwork, collaboration, and process adaptability.

Agile methods break tasks into small increments with minimal traditional planning. Iterations are short time frames (timeboxes) that typically last from two to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, development and testing.

The concept is that it minimizes overall risk and allows the project to adapt to changes quickly. That being said, a user-centered design approach is inherently an iterative development life-cycle. The difference is it focuses on the needs of a user to achieve their objective in the most-straightforward path possible. This focus eliminates many of the typical requirements that team sponsors dream up. By limiting the life-cycle to the user’s needs it enables a shorter timeframe for stages of the project. Working collaboratively with the end user through facilitated work sessions, wireframing and rapid prototyping it is feasible to eliminate much of the traditional project-heavy documentation and deliver a streamlined product. The difficulty isn’t in defining how to deliver within an Agile Framework, but rather making the organizational and mental changes required to break old habits and patterns.

How have you seen projects merge a user-centered design approach within an Agile Framework?

The Power of Less

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?