last tended
One of the world’s largest commercial banks was facing climbing rates of dissatisfaction with their commercial banking experience.
The proposed solution was simple enough-- streamline the customer experience by uniting the separate product silos and online platforms with the creation of a one-stop-shop commercial banking portal.
No, you’re right, that’s not simple at all. Things never are as simple as the brief you’re given in the 30-minute kickoff call. But here I am, 1 ½ years later, finally ready to talk about it.
[Quick pit stop: this is not a case study. If you're interested in more specifics on the process and roles I held please reach out directly.]
This 16 month engagement spanning the entire product development cycle led to two thoughts just rattling about my mind for the better half of the past year:
The solution ≠ the product ≠ the product strategy ≠ the product roadmap
AND
UX research is table stakes in defining each of the above
You may have noticed at the beginning of this piece that the brief outlined a solution that explicitly calls for the creation of a portal. In my entry-level glory there were no questions here. This is what we were hired to do… Driven by our expertise in user experience we'll provide a human-centered design for a portal, along with a plan for delivery and implementation.
There's nothing wrong with the creation of this portal, in fact it was well overdue, but this product was only a part of the solution for their customer dissatisfaction. Beginning by defining the solution at a product level resulted in a loss of focus on the true problem area that we were working to solve. What is truly driving the dissatisfaction? How are businesses managing their financials today? How is that changing? Using a systems thinking approach to define the solution would’ve allowed us account for all of the peripheral stakeholders and factors that would come in to play. It would’ve allowed us to anticipate necessary adjustments in areas like organizational change management, product mix strategy, and even business design.
For this banking portal, one of the many requirements was digitizing the entirely paper-based loan application process. When survey responses tell you clients are dissatisfied with a lack of digital experiences the easy response is to make it so they can do more online. What if the real difficulty isn’t that they can’t complete the tasks online but that it takes 25 steps to submit 10 pieces of information and 8 weeks to get approval?
If we had truly understood the overall problem space and framed the solution as more than just the client facing portal screens, we would have seen earlier on that that there would be implications on the broader data management systems and that employee roles would need to be changed, created, and even destroyed.
In the same vein of not maintaining a broad enough perspective for your solution, it's vital to understand when and where to get into the granular details of what features will be delivered.
The product and your roadmap are not the same as your product strategy. The product is the current proposed approach to achieve your product strategy vision and the roadmap is the action plan for how you will get there. Both are meant to be responsive and adjust as information is uncovered and needs change. Melissa Perri defines product strategy as “a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers." What stands out to me is the importance of establishing alignment on desirable outcomes for both the business and your customers. The best approach to achieve those outcomes may change but as long as we have a guiding strategy our product and roadmap can adjust accordingly.
Moving further into our delivery it became apparent we lacked a clearly defined strategy. There was a vague vision, a one-stop-shop banking portal, but no defined objectives. What were we looking to achieve? What were the goals and target outcomes? What was our positioning among competitors? What was our positioning among our client’s other existing commercial banking products? Each team set off to deliver a laundry list of features without a unifying strategy or open dialogue.
Our MVP quickly backslide into a bloated feature factory that was consistently missing deadlines and delivery dates. We found necessary pivots could not be made due to the accumulating product debt and because that strategy alignment was never established between the senior stakeholders.
It is so easy to get lost in the complexities of defining problem spaces, solutions, and strategies. Even still I am questioning the accuracy of the lexicon I've used above to define how I'm interpreting these concepts and hierarchies. With all else the same, this has reinforced my belief that UX research should be leveraged as an activity that more broadly spans business and product strategy. Each of the definitions I referenced above begin or end with some form of UX research being used to better frame how what you’re creating fits into the broader system, define how you might intervene, or even measure your outcomes.
Often within consulting, I see those less familiar with UX research define it as usability testing, as an evaluative activity of existing design, or as interviewing to define personas and workflows. While these are some of the most common functions they are not comprehensive whatsoever in what UX research can be used for. Today, it is almost always brought in as an activity after the product and roadmap are outlined and even more so after the problem space and solution are defined.
In a dream world some form UX research would be formally incorporated in all phases of the scoping, selling, and delivery of a project to help understand the whos, whats, whys, and hows of the initially perceived challenges to ensure the right problems are being addressed by the right solutions, strategies, and products.
For an IT consulting business structure, a change like that is not small nor quick. You need to standardize and package the offering with a price tag, you need evidence to demonstrate the value and impact of these activities, and you need to be able to sell that to a client for a profit.
With each reflection comes takeaways. There’s something to learn from every experience and below I’ll cover some next steps, tips, or rules of thumb I plan to apply in my day to day work.
For now, I know to begin every engagement with some core questions regardless of how simple or silly they may seem. Often, we think we know the answers to these but when it comes to articulating it’s a little bit harder.
1. Why are we looking to do this? What problem does this solve?
2. Is there any available information or data on this problem that can place it into context?
3. What are the target objectives and outcomes?
Moving forward, I plan to begin every phase of work or meeting with a nod to the responses that arise from these questions. Often in our engagements the work is more than delivery. A part of our responsibility is teaching clients about what we do and why things like design, research, and product management are important. Reframing every meeting or session will only reinforce the learnings and help to narrow focus on what really matters. [This applies more broadly with always beginning meetings with an agenda and objectives/outcomes for the session!]
For the long-term I’d to identify better ways to include UX research in all the work we do, even if its not always a formally defined offering. I can begin to outline some quick start guides of research activities that I use during engagements to better frame what I’m working on. A more standardized approach can help teams uncover some of the necessary information to do things like define the problem area and solution space, outline a product strategy, and prioritize a product roadmap.