During my stint at Nephila - the biggest hedge fund for natural catastrophe bonds and reinsurance capital, I set up their UX practice to bring the underwriting process to the next level. Having worked for years in finance, I thought I had seen intricate user journeys and product sophistication, but working with actuaries and data/weather scientists added a new layer of understanding for complexity and design with data.
Below I’m summarizing key takeaways for designing complex functionality for professional/scientific users distilled from my work on the fund’s underwriting/binding platform, risk management, and portfolio optimisation systems.
This is always true, but even more so when you’re dealing with professional users and highly specialised knowledge. With a general audience, designers can make assumptions and try to put themselves in their user's shoes on the back of generic empathy. It's much trickier to put yourself in the shoes of an actuary if you aren't one. No game-changing ideas from me, but here's my recipe:
Training is the obvious route - there's an online tutorial for anything these days and the organisation will likely have internal documentation/tutorials too. Put on your geeky hat and spend a few days reading - you need to be up to speed with terminology and basic concepts before you meet users. Beyond the obvious sources:
Since you don't understand the users, building a precise Conceptual model is even more important than usual. In addition to the usual interviews/ethnography sessions, my best shot at this is normally with a card sorting exercise - you get users to define the main objects/entities in the system in their own words, you get a glimpse into the relationship between those objects and you surface any hierarchies.
Collaborative/participative design nicely rounds off any gaps in your conceptual model. I've seen this being used as an interaction design tool, effectively putting users in the designer’s seat. To me, instead, it is more valuable as a research method - discussions through the workshop surface how users think of the data, how they prioritise functionality, and what they want to achieve with it. The actual design output - How they want it achieved, I see as another useful insight into their conceptual model, but will approach critically for actual design direction.
When you're designing complex UI for specialised users, it's likely a boutique solution with a limited, involved user base. For some of my projects, the IT team has been bigger than the user base - normally you're automating processes that leverage a lot of business value and organisations increasingly realise their IT departments are driving performance rather their front office. You have a captive, knowledgeable audience motivated to learn and use your solution. This relaxes the need to design for obvious, affordable interactions. You can hide items in menus, you can come up with custom data visualisations that require explanation, you can save on labelling and wizards. Some of my solutions are onboarded after weeks of personal training. I think of this as the greatest creative freedom and a source of love for designing complex solutions - you can break away the chains of usability and harness creative strength towards efficient, powerful interactions rather than standard, intuitive affordances. It isn't an excuse to produce cryptic functionality - sophisticated users are just as frustrated and unforgiving with unintuitive UI and overreliance on training is dangerous. But it does open up possibilities for creative solutions that wouldn't necessarily be appropriate or feasible for the general audience.
You're dealing with power users, so empower them! Specialised, expert users have the knowledge and skills to solve problems and they love doing it - taking control away from them can be frustrating for users and counterproductive for business. One of the most important design decisions on a complex system will be around the right level of automation - do too little and you're missing valuable opportunities to simplify life and optimise performance, but do too much and you risk grinding a complex process to a halt with exceptions or required tweaks that are not easily serviceable. Instead of obfuscating the complexity, reveal it intuitively - map it out for users to tweak and handle manually.
My golden standard and point of reference is always Excel - this is the one tool every power user I have met loves and understands: it reveals every calculation and affords traceability behind each number. It's spaghetty code and usually a mess, but users love it: they can sift through the spaghetty and find the bad one. This is what I try and replicate in complex products - automate some bits but leave the process transparent and the user - firmly in control. Contrary to common logic, I find too much automation is rarely a winning strategy for complex products
Emotional design is all the rage these days and when it comes to power users, geeky is lovable. Power users are at their best when they are seen to be solving complex problems. A good design will make space for being a hero. Making things look easy takes away satisfaction, prestige, and on a more practical level - barriers to entry into the profession
Without bowing to politics, designers can acknowledge the geeky side of power users and work around that. Keyboard shortcuts that require cheatsheets, hidden sections behind tiny arrows, double click events, natural language prgorammatic input of data - in the context of relaxed usability requirements and solid upfront user training, all of these can contribute to the user experience in ways more satisfying than easier, more usable alternatives.
While conventional typographic wisdom calls for bold headings that stand out from content to facilitate scannability of a page, when you're designing for experts I would recommend exactly the opposite - deemphasized headings that do not steal attention away from the content.
The logic goes that your users are likely exposed to your system repeatedly through their work, so the first impression is less important than subsequent use. Scannability of a page is important for new visitors, but repeat users likely already know where things are. Often, expert users will recognise different pieces of content (prices of shares versus prices of bonds) with just a glance at their format/content, so headings are not even needed. This results in pages of flat hierarchies with a focus on the content rather than headings. You don't want a massive, obvious heading drawing the eye away from the useful content right under it day after day. It makes for a much less scannable view but one that still works well for users who know their ways.