The right champion pays dividends
Written by Mark Van Driel
Over the last few years, I have witnessed many organizations invest in understanding their business, users, and customers prior to building their digital products. They start at the highest level, in what we call the innovation phase, drafting a concept from identified user needs. This concept verifies the value of the digital product, the engineering team then drives the entire product design from a user-centered approach. The typical outcome is a digital product that achieves its goals.
During this same period, I have also seen organizations rely on key people in their organization to determine the needs of their business, users, and customers. These people, whom I refer to as champions, determine the capabilities of the digital product and fit the product to their view of what users need. The result of this approach typically is a product that falls short of its goals, while further challenging the relationship between the business and information technology teams.
There are two primary reasons why the champion approach is used so often in software development – organizations do not want to bother users, or they think they do not have enough money to pay for formal design. Let’s explore why these reasons are flawed.
“I do not want to bother my users or customers”
It is surprising how often organizations use this argument to bolster the champion-based approach. The obvious problem with this excuse is that unless you understand what they need, it is difficult to build the right digital product for them. Not involving the users until the product has been programmed will most often miss the actual needs of the users. The product team then modifies the inadequate user interface in an iterative fashion until it is good enough for the users. Getting “good enough” instead of “just right” results in the users being bothered more than if they were involved from the very beginning. This constant misrepresentation of needs can also erode the businesses’ confidence in the information technology product teams.
“It costs too much to pursue a user-centric approach”
The reality of this statement is that people often fail to consider that someone will have to design it anyway. Won’t a designer be more efficient at design than an engineer or business analyst? What about the extra iterations of user interface modifications during the engineering phase, won’t that cost additional money too? The answer to both questions is yes. Additional efficiencies can be driven by design if you build a design system to be leveraged across the product, saving time and investment.
All of this brings me back to the beginning. The champions in our business are important and often serve as the experts inside our organizations. But just remember if you are taking a champion-driven approach to designing your product, the real champions are the users and customers. Build it for them, with their input, and it will pay dividends.