Over the course of the last ten-plus years of my career in custom application development consulting, I’ve played various roles in approximately 400 individual projects with different scopes, goals and technologies. In every case, the team that followed a process and clearly communicated showed the highest indication of success. This has been true whether I was acting as a software developer, project manager, or working with clients during the sales process to determine their goals and budget. A team with a plan—one that communicates and quickly reaches agreement about the goals of a project—will achieve a positive outcome. The software development community recognized the same indicators of success, which gave birth to a number of software development methodologies that are widely known as Agile Software Development.

block quoteMainSpring formally adopted Agile in 2011, and we’ve continued to adapt our processes by monitoring the outcomes of our projects and analyzing what went well and what could have gone better. Time and again we’ve discovered that, while we were consistently achieving the goals of the project, as well as a positive outcome, the projects in which we invested more time incorporating tenets of User Centered Design in the planning phase were much more successful.

User Centered Design

User Centered Design (UCD) is a process framework in which the needs and limitations of users are considered the primary driver of system requirements. While this may seem like an obvious decision to make, when you reflect upon how people actually “shop” for custom software development, it is easy to see that the idea behind UCD can be lost in the process of getting an estimate on functionality and the budget required to achieve it.

At MainSpring, we recognize UCD’s criticality in meeting all our clients’ needs. Therefore, we have implemented light-weight UCD practices into the Planning and Discovery phase of our Agile Process.

User Persona chartUser personas

Using UCD within an Agile Process begins with the concept of a User Persona. The user persona is a brief description that the project team can refer back to in order to clarify these common conceptions:

  1. What the user is doing
  2. The goals and motivations when using the tool
  3. The user’s pain points with the current process or tool
  4. A basic understanding of the user’s technical aptitude
  5. When the user will access the system

MainSpring user personas are limited to a single page profile, which helps the project team clearly understand who they are building software for.

User stories

User stories are the next step in our Planning and Discovery phase and they are unique to each user persona. A user story includes a brief description of the action that the user persona needs the system to perform, along with the successful acceptance criteria for that action and the software features that define the scope and budget of the project. An example of a user story is:

“As an application development manager, I need to view a report showing the stats of all of our active software development projects. The acceptance criteria for this would be: seeing budgeted hours vs. actual hours, progress vs budgeted hours, adherence to schedule, and a chart depicting these metrics over the lifetime of the project. This should be automatically emailed every Monday at 9 a.m.”

Defining the interactions between the client and the software within the Agile process allows the development and client teams to communicate effectively. During each stage of evaluation, we can refer back to the user story to see if client goals are met based on the understanding of the user persona.

Expect more

Our MainSpring development team has found that following this process improves every step of our Agile process—everything from requirements gathering to development, internal testing, and even user review and acceptance testing. Even though the user story may change over time, having a clear conception of the persona makes the change easier for everyone to understand and agree upon.

It is important to acknowledge that custom software isn’t always the answer. But, when your development team follows a process that invests time into defining the users of a tool, as well as the specifics of how the users interact with that tool, it leads to the creation of a successful system that delivers the real value of customer software: the right results for the right people.