WHAT IS UX?
User Experience Design (UXD, or just plain UX) is about building user-centric products where interactions are intuitive, effective, and enjoyable. This definition can be broadened to include not just a company’s products, but any interaction a user has with a company or its services. UXD is not just a technical concern – we see elements of it in theaters, theme parks, and retail stores. Here at BlackRock, we are re-imagining user experience for everything – from our Aladdin platform to our outbound Client Reports.
UX VS UI
It is easy to confuse UX Design with User Interface (UI) design. In fact, in many corporations, UI Designers are tasked with UX responsibilities. To make it easy, remember – UX is how it works, UI is how it looks [1]. If you still don’t get it, take a look at this handy guide.
WHY IS (ENTERPRISE) FINTECH UX SO HARD?
You need domain expertise: To build the best possible product for a user, there is a lot we need to understand. It isn’t enough to hear what the user wants; we should understand what they need. To design a best-in-class experience, we must understand the business domain, the user, and their processes. It isn’t enough to be a technical expert; the person designing the product must be a domain expert, too. BlackRock takes this to heart – often, our developers understand our business processes better than our end users. It allows us to build seamless systems and make smart functional trade-offs.
We don’t always know our users: The people we sell our product to are not the same people using our product. This is not news. When we are selling our product externally, we are often working with a sales team, not the folks with their boots on the ground who will be living and breathing in our application. In the case of internal stakeholders, often we work with a manager or a representative, who isn’t always involved in the nitty-gritty details of day-to-day operations. It is hard to understand your users if you don’t know who they are, and have never worked closely with them.
Client implementations are bespoke: Every client implementation carries with it complexities as needs vary from client to client. Each implementation lives in a different ecosystem of third-party tools and homebrewed apps, often jerry-rigged together with questionable scripts and manual processes. Compound that with the fact that clients also have different department structures and disparate business processes, you can guarantee that every implementation will require application customization resulting in endless edge case considerations.
Users’ tech savviness varies: Large enterprise applications will always have users with varying degrees of technical understanding. Less technically-savvy users can sometimes be resistant to change. As a UX Designer, when building your application, you will soon learn that what may seem intuitive to savvy users will not be so intuitive to others.
You’ve got to be super-specific: We operate in in an industry where the detail matters. This is people’s money we are dealing with – so it is important that when a user sees a label or an attribute on the GUI2that it is extremely clear what it means. (Can you imagine making an investment decision based on gross rate of return thinking it was net rate of return? And, whether it’s in support of MIFID3, Dodd-Frank or any of a dozen other regulations, we end up overloading screens with attributes, disclaimers, warnings, and other various legal-ese.
COMPLACENCY IS COMMON
Sticky users: The cost to switch enterprise fintech applications can be high. Once we are integrated into a client’s ecosystem it is difficult for them to switch our applications for others – it’s not like they can just go to the app store and download a replacement if they don’t like ours. Such a sticky user base can lead to unintended consequences, such as complacency around providing a great user experience.
Measuring success can be difficult: It is often hard to know when you’ve truly been successful with a UX update. Different problems will require us to measure different KPIs4. In some cases, it could be conversion rates, or the amount of time someone spends performing a certain task. You could also try to measure it in terms of FTEs5 saved, or MAUs6. Choosing the right KPIs and being able to measure their success is critical to being able to understand the value prop of UX updates.
Quantifying the ROI can be even more difficult: Our development queue can be heavily weighted towards functionality enhancements rather than user experience enhancements. Features are concrete; UX less so. It is easier to calculate the ROI7 of adding functionality than it is to consider costs associated with the frustration, confusion, and user errors associated with poor product design. We are often ‘graded’ by the features we develop and not the experience we deliver.
We may not feel ownership of the UX: Corporations often have departments focused on making product decisions – they define the UX/UI and give us standards to which we adhere. In that kind of environment, it’s easy to be hands-off and leave UX decisions to others. When a standard doesn’t work for what we are trying to accomplish, we don’t always feel empowered to speak up.
Don’t rock the boat: If we decide to break the mould, do something exciting and different, and it does not pan out – well, that is a risk that needs to be managed! Introducing new design paradigms comes with its own set of challenges. To avoid rocking the boat we would need to get buy-in from managers, perform user trainings and over-communicate to stakeholders. Maintaining the status quo is usually easier and safer.
SO WHAT’S A DEVELOPER TO DO?
Some folks in the UX community think software developers make for poor UX designers – we are too logical, too consistent, and too unsympathetic, and user experience suffers as a result.
Let’s be honest – we want to build best-in-class software. We want the best possible product and experience for our clients; these people live and breathe in our applications. The tools we build for them has a significant impact on their productivity and happiness, and that means the decisions we make can be the difference between them whistling their way home and them grinding their teeth at night.
UX is about creating seamless and frictionless interactions for our clients. Enterprise UX matters, and our clients deserve a best-in-class application. User Experience Design isn’t limited to front-end applications, either – many of the same principles can and should be applied to server-side API development, as well. Once you’re bought in, get your team and manager bought in too.
Are you sold on UXD, yet? Great!
So, let’s get started…
REAL WORLD EXAMPLES & NEXT STEPS
PortfoliosView (PV), a powerful and advanced portfolio query tool, is one of Aladdin’s heavily used application. It encapsulates complex business logic to filter out in-active and un-permissioned portfolios, calculate column values, and allows users to save search requests. Given its large users base, many bug reports are filed for the application – upon analysis, they are often classified under the ubiquitous ‘user error’ category
We started small: We met with our PV support team, and learnt that they receive a large volume of repeat queries regarding the results returned by the application – ‘My colleague can view portfolio X in the results. Why can’t I?’, ‘I can’t find my portfolio from four years ago.’ and so on. We realized that our proactive approach to filtering data was confusing our users; we were not making it clear to our users what was happening under the hood.
So how did we address this? Simply by providing the users with specific information on the results page; for example, “We are hiding 13 test portfolios – click here to include them in the results”, “We are hiding 40 terminated portfolios – click here to include them in the results”, “You don’t have permission to view 14 portfolios” etc. This helped reduce support queries by 40%.
Your next step: Talk to your support team and find the five most often asked questions about your applications8. Work furiously to fix those problems – whether it’s by redesigning your interface, adding tooltips, or clarifying labels.
We became experts: We studied our users and their processes, memorized our data model, and became certain that we knew our application inside and out. We built out our user personas for PortfoliosView and documented user journeys. We conducted a super-simple usability test. We learned that users need to click through three separate tabs to access our most popular search filters. By consolidating our most frequently used filters on one screen, we enabled our users to be more efficient.
Your next step: Document at least two of your apps’ user personas, then find out what the most frequent user stories are for each of your personas and draw the journey. Be aware that the user experience isn’t always about the interactions with your app – a lot may happen offline or over email – be sure to capture the holistic picture. Be honest about how your users experience your application.
We added it to our SDLC9: When deciding release dates, we include time to document the user journey and conduct usability testing; that way the experience was not just an afterthought. Before a feature release, we perform at least one early usability test. We also implemented design review stand-ups, where developers and product managers huddle around a developer’s desk and give UI/UX feedback on upcoming feature releases.
Your next step: When deciding your MVP10, really think about how the value-add to your users. Set up a regular usability test with your stakeholders (these can be weekly or even monthly to start). Add usability testing to your SDLC. And make sure you keep your colleagues honest; let them know when something seems overly complicated or burdensome for users.
And… keep learning. Valuable information is easy to come by – usability testing, user journey maps, personas (user roles).
CREDITS
This post borrows heavily from concepts and themes in articles by Uday Gajendar, books by Steve Krug and posts by Jon Reed.
- https://envato.com/blog/getting-started-user-interface-design/
- GUI – Graphical User Interface
- MIFID – Markets in Financial Instruments Directive
- KPI – Key Performance Indicator
- FTE – Full Time Employee
- MAU – Monthly Active Users
- ROI – Return On Investment
- “Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition” by Steve Krug
- SDLC – Software Development Life Cycle
- MVP – Minimum Viable Product
Read more from the BlackRock Engineering Blog