User Experience in the Development Lifecycle

Why is a user experience team important when developers have been creating usable systems for years? The key to that sentence is your definition of “usable”. Yes, developers do a great job at creating a solid code foundation which is scaleable, and reusable. They also create systems which at some level allow users to complete one or more tasks. However their focus is, as it should be, on the behind-the-scene’s creation instead of getting to know the user base. For example the user’s technical level, and how they can efficiently interact with the presentation layer of the system to easily complete tasks. Sure, they can create a system to be used, but how friendly is it really?

There are many ways to grade the usability of a product and many reasons it is important, not only to the users, but the business as well. For example reducing cost, reducing support and development times, improving user satisfaction, increasing sales and brand recognition, just to name a few. I could go on and on, but that’s another article. So how does this user experience team fit in our current SDLC?


Currently the most popular SDLC (Software Development Life Cycle) technique is the Waterfall Method. With this method a specific set of defined phases are carried out sequentially by separate teams in a linear process. Because this process is linear these project usually last many months, if not years. The projects are done in their entirety, and released as a full version.

While each company defines their waterfall a bit differently, the typical waterfall consists of 6 stages:  Planning, Requirements, Design, Development, QA, Release. User Experience is brought into the waterfall each step of the way.

User research and experience with past user tests are brought into the planning phases to help ensure that the goals of the business align with the needs of the users. Then as analysts document and define what the system should do, interaction designers create prototypes for the presentation layer to show how the system should do it. These requirements and prototypes are tested and refined before being presented to the stakeholder for approval. Then, any changes are iterated and re-presented before the next phase can begin. Once the requirements and prototypes have been agreed upon and approved, a hand off package is provided to the developers which specifies what is to be built.

The development team then begins creating the actual application, which includes periodic check-up meetings with the analyst and interaction designers to ensure the product is on track. Once development is completed, the code is tested by a Quality Assurance (QA) team. At this time the user experience team will also run tests to ensure that the end result matches up with prototyped solution. Once QA is passed, and the stakeholders approve the final product then documentation is created and the product is rolled out, and a new project cycle begins. It is important to note, that each company has a sort of twist on their waterfall cycle, and the example above is not an exact science, but more a general sample.


A newer SDLC flavor is Agile Development. This is a much faster take on the waterfall cycle that mashes up all of the phases into many small iterative chunks or sprints. These sprints are worked on by small teams which are compiled by a sampling of the larger waterfall teams. Each team is made up of it’s own analysts, developers and testers who all have access to stakeholders.  This helps to provide a highly iterative and fast pace cycle for creating small chunks of code, which are then added to a larger release.

Here user experience must be integrated much differently, as the amount of time and detail previously dedicated to each phase of a waterfall cycle can no longer fit into these short sprints. Instead user experience analysts must divide into two groups, one for the micro and one for the macro.

The first group, the macro group, has a separate focus which is independent of the typical scrum teams. This unique team focuses their sprints on the big picture of what is to be produced, improving the user experience from a holistic overview of the system. They continually test the system as a whole to ensure consistency and standards across each of the scum teams and alignment with the users needs. Some tasks may include things like creating and maintaining pattern libraries, user testing product releases, heuristic reviews, and usability standards.

The second group is integrated much more closely into the development side of the scrum teams. This group is mostly made up of the interaction designers who can work with the stakeholders to create quick prototypes within the sprints, and provide guidance on task flows and site structure as each of the little chunks of code are created. These individuals are a more generalized specialist, and are often specific members of one or more scrum teams so that they can dedicate their time to the user experience of each sprint. They work quickly and use many brainstorming techniques, paper prototypes, sticky notes, and whiteboards. Both teams must collaborate closely to ensure consistency and reliability with their input and the goals and needs of the users.

Regardless of type of development your company uses, the important thing to remember is that user experience is a part of it. There are many ways to integrate user’s needs and goals into the system, some of which are better than others, but the point is that it happens. This can be a slow and tedious process, and requires practitioners with a passion. While good usability is invisible to the user, keeping track of changes and user satisfaction over time, while research is done and recommendations are implemented, can definitely demonstrate the ROI that good user experience provides. Start with quick wins, then over time the need for a team and integration into the SDLC will speak for itself.