The Battle of End-Users and Engineers

By Tobi DeVito

Today, you’d be hard pressed to find a product shop that doesn’t pride itself on employing User-Centered Design (UCD) to create digital applications and websites. A tremendous amount of rigor is applied—not to mention time and money spent—to ensure sites and apps are built to meet the needs of users, as opposed to business needs or technology requirements. Hours are spent conducting heuristics and interviewing, surveying and observing end users to enable product teams to iteratively design and develop prototypes with the highest level of user satisfaction and adoption.

However, much too often, the commitment to UCD–envisioning, designing and building features with a user-first attitude—is adhered to in earnest juuuust up until the point of product release. At this time, all bets are off! Launch dates loom… Anxious stakeholders throw down the axe… QA gets squeezed by the day. And, inevitably, product teams quickly revert to traditional software development defect severity and prioritization rankingsrankings that are defined exclusively from a technical and business-driven perspective.

Redefining severity and priority

To ensure UCD is adhered to through all phases of product development—including defect ranking and resolution—product teams must begin to adopt broader definitions of severity and priority.

Let’s start by taking a look at the ISTQB (International Software Testing Qualifications Board) definitions for severity and priority, definitions that are strictly technical or functional in nature:

To ensure the user’s needs are present at all times, we must reach beyond just technical functionality and business needs. The following revised UCD-centered definitions keep teams focused on creating experiences that users will love through defect ranking and resolution to launch:

User Experience Requirements

Aligning on revised definitions for severity and prioritization is a necessary first step. But in order to keep the product team’s eye on the prize of delighting end users, teams must also gain alignment on what makes for the best ‘user experience.’ To address the full gamut of a user’s experience, a product must meet three distinct types of feature requirements:

Brand Requirements: How the user experiences the business’s brand in the application.

Brand requirements are critical to a visual expression that is easy, bug-free, and generates user satisfaction, adoption and repeat usage. While brand defects may not prohibit a user from working in the app, poor adherence to brand requirements often leads to inconsistent brand experiences across brand platforms. This causes consumer confusion and overall dissatisfaction, resulting in a decline of usage.

UX & Visual Design Requirements: How the user functions and behaves (visual and interactive design) in the application.

Visual and functional requirements are key to user success in an application. Like brand, UX and visual design defects might not stop a user from completing a task, but poor UX or challenging design will lead to higher abandonment rates as users become frustrated and confused.

Technical Requirements: How the user completes work (technical interaction) in the application.

Technical functionality remains critical to a good product development. If aspects don’t work, users will abandon it.  Therefore, technical defects that restrict the ability to use a feature continue to require attention.

Revising Ranking Criteria

When ranking defects, it is common for teams to conflate severity (impact) and priority (importance). However, criteria for these two are very different. The amount of impact a feature has on a user’s experience in the application is not the same as the importance of that feature to the user. Thus, the two criteria must be decoupled when evaluating defects, as both require rigor in assignment independent from the other.

Severity Criteria
The following chart details the existing traditional software (technology and business-driven only) vs. UCD-centered criteria for ranking the severity, or level of impact, of a defect:

By including all three types of requirements in the criteria for UCD-centered, teams (and let’s be real, it’s typically developers who apply these rankings. And, at times, with little input from the rest of the product team) are forced to reorient themselves to the user’s needs.

Thus, when ranking the severity of a bug, the question teams must ask themselves is no longer, “How much does this defect prohibit the feature from working?” Rather, it’s, “How does this defect prohibit the user’s experience–brand, UX & visual design, or technical–of this feature?” This broader definition may even require–gasp!–the designer or UX on the team to help rank severity. (I feel the heaps of garbage being thrown at me from here. I will give you reason to put those rotten tomatoes away in one minute!)

Priority Criteria
In additional to assessing the impact (“severity”) a defect has on a user’s experience, a team must also determine the level of importance (“priority”) of the defect. The following criteria enforces a commitment to UCD in prioritization rankings:

By positioning the user’s desirability of a defect as the highest priority–above the viability (the traditional criteria for priority) of the defect, the team continues to address the user’s needs first as they plow through defects…even up to the minute of a product launch.  

Severity/Priority Matrix
With the “severity” and “priority” criteria clearly defined and agreed upon, teams can begin to collectively align on a common understanding of how these two metrics work together.

Below is a sample matrix of how these two might work together:

The Rollout

And now, put down those tomatoes. While it is true, no user can actually use a product that is technologically nonfunctional, it does not matter how technologically advanced a product is if no one ever uses it. Making great products requires listening to user needs throughout the cycle of the project… Including defect resolution.

All this being said, anyone who has actually works on a product team to develop an app knows, these criteria, are just that, criteria. They are not hard-and-fast rules that teams must live and die on. But they do serve to guide and remind teams that they are building the product for users, not for technology. I have found even if teams I work with just consider that there is an alternative criteria, they are automatically reoriented. I even have one developer who now leads the charge, always being the first to ask the question, “Do users really want this feature?!”

We must continue to build products that people need, matching the right technology to meet those needs.


As Director, Technology and Product Management Tobi’s career has spanned a variety of disciplines and industries—from leading digital product teams for Fortune 100 clients and executing multi-million dollar media campaigns for leading e-comm retailers, to building CRM databases for national non-profits. At VSA, Tobi delivers bleeding-edge digital experiences for IBM, leveraging Watson and other IBM Cloud and cognitive technologies. Through her broad experience, Tobi has developed the critical skill of nurturing, motivating and empowering teams. In unifying internal and external stakeholders with clearly defined product vision, requirements and purpose, her teams have consistently delivered differentiated, user-centered products across varied platforms, services and tech stacks. Tobi is a Certified Scrum Product Owner and holds a Bachelor’s degree in Philosophy from University of Puget Sound and a Master’s degree in Public Administration from New York University.

Tobi can be contacted at