Incorporating User Centered Design

User centered design (UCD) has been a common buzzword over the past few years. Properly embraced, UCD can be extremely beneficial to software teams looking to deliver useful products for their end users.

At its core, the concept is straightforward: every aspect of the end user is taken into account and incorporated into the design and/or user experience. User involvement from up front discovery on through implementation is the primary focus.

Simple, right?

Why it Matters

Unfortunately, the one thing that most often gets lost when working on a product is the user that will use it the most. It is very easy to get caught up in the implementation: Does it do X well?, Did we follow every step of the process?, and Were we able to solve that quirky behavior that we couldn't reliably reproduce that one time?

Answering Yes to all of those questions is great, but that wonderful feeling of "checking all the boxes" is empty if the product goes live and the users end up with something that wasn't what they expected. It's too difficult to use? Why is it doing it this way...? Oh, we never do that.****

Comments like that are especially true if the product is developed in a vacuum, with little up front design or regular demonstrations of working software with the people that will be actually using it. If the only time anyone has seen anything of the product is at inception (requirements, some mock ups, whiteboard sessions, etc.) and when it's "ready" for some hands on user acceptance testing, then you're already fighting an uphill battle.

Once the product becomes tangible -- when users are able to see something working -- they can begin to visualize how they will end up using it. Detailed discussions, notes, requirements, and mock ups only go so far, but tangible, working software makes everything real.

When the product becomes real, that's when you can begin to have solid discussions on not only what it needs to do, but also how the user needs to work with it in order to achieve their objective.

Incorporating Users into the Process

The first step, as with anything else, is commitment. All different types of products aside, if there isn't a firm commitment from the project team, leadership, and the users to building a useful product, then the odds are immediately stacked against you. From planning on through release, everyone involved in the development process should be acutely aware of the product's objective, how it should be used, who will be using it, and how to measure its usefulness.

Identifying and including the real end users is key. Typically, a business lead or analyst that represents the needs of the user is included in these discussions, but they are often not going to be the every day user. It's essential to get as close to that every day user as possible in order to get a valuable perspective as how to the product may be used once it's in the wild. In a corporate environment, this may require allocating time up front (because hey, they still have a job to do, right?) or setting aside small periods of time over the course of development for feedback sessions.

It is also vital that the project team commits to understanding the context in which the product will be used from a user's perspective. This may include going outside of the product's immediate focus (e.g. a means to produce widgets) and expanding to a broader scope of the user's day-to-day or critical job functions (e.g. 95% of the time before producing a widget, a phone call is taken and records are searched in system A). A user's experience is more than just their interaction with the product or feature under development, but is inclusive of the activities before and after its usage.

Demonstration of actual software is the next critical point in keeping with user centered design. Small, frequent releases (or iterations) have the advantage of offering up consistent, working software in the hopes that if (when) things change and the team needs to pivot, it can happen quickly. As the product evolves over the course of development, consistent feedback from the user community allows the project team to know that they are continuing to build the right product. The longer between releases or milestones, the higher the risk of "breaking" changes: We can do that, but we'll have to rework a lot of what we've already done.

For each iteration, the user should be involved in conversations related to the product's design or intended use. Whether these conversations are slanted towards the what or the interface design of the how, their input is important. (Do be careful in not devolving into the design by committee spiral. Focus on the intent, requirements, and user experience of the product. Remember: the goal is effective collaboration.)

Once the product has been tested and is ready to release, it's time to sit back and relax, right?

Almost.

Measuring

You've spent a lot of time committing to incorporating user centered design into whatever process you have. The project team knows they did a great job adhering to the user's needs, scope creep was kept in check, and the business sponsors got exactly what was asked for, designed, and implemented (including any changes/pivots along the way).

Now your product or feature is out in the wild. How do you know if it had any impact? Did we actually increase the number of widgets we anticipated or save a percentage of widgets that was expected? Did our design scale to handle the daily workload? Or, perhaps most important, is the product or feature even being used (or being used as intended)?

Regardless of the product, feature, or business context, it's important to have a means of identifying the impact the project had after its release. A set of measurements can provide the metrics to answer the above questions and provide valuable feedback to the project team as they embark on future enhancements.

There are a number of different things that you can measure and it all depends on your product, feature, or business context. Here are a few examples:

• Number of users that have signed up for the product by hour, by distribution channel.
• Number of clicks on a given page.
• Measuring idle time in an A/B testing scenario sliced by user population.
• Revenue increase week over week compared to previous week or week revenue before the new implementation.

Incorporating user centered design into your process will help you remember the end user when you're in the thick of development. A commitment from all those involved helps to cement it as a staple of your development that will enable project teams to consistently deliver higher quality software.

And happy users.