Lessons from Designing for Advanced Users
Complicated screens? It’s not hype anymore
Since the establishment of Societe Generale CIB’s in-house design team 5 years ago, we’ve been pushing our design craft for advanced users and design for some of the most complex applications imaginable.
This piece is part of a series exploring the use of design to rethink Corporate & Investment Banking services. Part 1 is here and part 2 here.
In the Business-to-Business or Business-to-Employee spaces, people often find themselves lumbered with existing tools that need serious design work. It is not easy to change people’s habits, even when you know it’s for the best.
Every Facebook or Linkedin redesign comes with the inevitable backlash from a portion of unhappy users. A UX designer for a mainstream British newspaper once told me that their team had received death threats after rolling out their new design!
However, do you remember when Snapchat shocked their users into rebellion with not one but two failed re-designs, losing 73% of their user sentiment score between January and April 2018? Or Digg, the once successful social platform that disrupted the news industry that got killed by its V4 redesign?
So how do you tell the difference between a “they’ll get used to it” situation and “we completely screwed up”?
There’s no magic formula — don’t be lazy on research
Let me tell you a failed experiment we made at the beginning of our design journey. We tried to improve a trading tool with a lot of clumsy forms and multiple columns by applying UX’s best practices for forms.
There are hundreds of articles online about how to create forms, each with their own “golden rules”. To name but a few:
“Forms should only ever be one column.”
“You must top align labels.”
“If there are fewer than six, show ALL selection options.”
Surely, as we were dealing with established best practices, we thought that our users would have no trouble getting used to the changes… right?
So we tried it. We redesigned these forms into a clean, single-column one-form-at-a-time interface. The result looked something like this:
Then we organised user testing and sat back, waiting for the thanks to pour in for our simpler, more modern solution. Instead, the immediate reaction we got was:
“We don’t want this. The user experience is horrible!”
Clearly, this wasn’t a case of “they’ll get used to it”. The backlash was too strong. The design never went into full development.
To understand why, let’s draw a parallel with the professionals who use Photoshop. This may be more familiar to some of the readers:
Would professional users of Photoshop want these character and paragraph sections to be redesigned bigger with form’s best practices? No; that would mean scrolling through options every time they want to apply a change.
Research allows us to explain why some of our interfaces are dense and need to stay that way.
The example above is an online trading platform that offers real-time pricing and execution 24 hours a day, 5 days a week for Foreign Exchange products.
- It’s used by Societe Generale’s clients and internal sales and traders.
- There’s a lot of stuff on the screen as users need to be able to monitor an average of 10 different currency pairs simultaneously.
- In the context of their daily activity, the last digits of the prices will change more frequently than the opening digits, so they are displayed in a bigger size for the user’s convenience.
At the end of the day, designing a form for people who are discovering a process (and need a lower cognitive load) is not the same as designing a form for a seasoned professional talking their business’s language and having to deal with a great amount of complexity.
Today, this story serves a great example to all our new team members when explaining why user context dictates how best practice is applied in design solutions.
Design with non-design tools — and give homework to others
In order to design at scale — and thanks to the changes design had on the people and the organization (see part 2 of this series) — we made the choice to delegate some design tasks to other members of our projects.
In order to do so, we had to adapt our tools and use applications that were accessible to and understandable by everyone in the company. The solution was the non-glamorous PowerPoint and Excel.
It might sound counter-intuitive to use Excel as part of the process of creating something to replace it, but it works. We use pen and paper for our quick prototypes, and post-it notes for card sorting. However, when it comes to complex forms — and we have a lot of them in our industry — Excel has proven to be the best tool for sorting and rearranging cluttered forms.
Over time, we’ve even developed our own form-sorting methodology. Matthieu Harreau the UX designer of the team that initially tested our methodology on his project, created this Marie Kondo meme that neatly expresses how passionate he is about forms:
This methodology was first used on SG Markets Developer, a service that allows developers to access Societe Generale’s BtoB APIs, used both externally and internally.
The initial version required over 100 inputs to register an API, mainly because we kept adding them gradually until the form had become unbearably long. To clean things up, we established the following table to track the filling percentage of each input and its re-categorization:
Then we handed it over to the product owner and developers to complete. It was their homework, if you will. We wouldn’t do it for them and we wouldn’t embark upon any design without getting this table completed first. As I’ve said before, we design with, not for.
Don’t be a commodity — take part in the strategy
Should designers learn to code? It’s a question we hear often, but I prefer another: Should designers learn business?
By understanding the business they’re in, designers add much more value to the discussion when setting up metrics. In the same way that no designer should expect to be paid for the number of screens they produced, or developer for the number of lines of code, not all services will necessarily need or want to maximize their number of users, or the time they spent on their apps.
For example, we are currently working on redesigning an application that allows traders to compute and publish the prices on the markets. Only a few people have the mandate to actually do that, so instead of tracking the number of users, we are measuring indicators like the decrease in time spent on the tool, which is a good indicator of improved operational efficiency.
And there’s more. When designers genuinely understand their business, the whole project lifecycle is impacted positively. I stumbled across this meme online, and it struck such a chord with me that I’ve used it in most of my presentations ever since, when talking about this point…
30 years ago, when you wanted information, you had no choice but to ask around, or head for a library and dive into the reference books. The imaginary Google Classic invites you to mail your query to the physical location of Google, and wait 30 days for a response from their knowledgeable team. It’s a business model that might very well have been viable three decades ago. Today, not so much.
It can be very tempting to redesign a tool without redesigning its process. Some may be tempted to jump straight into the interface redesign. It’s more visually exciting than back-end issues and easier to share in milestone presentations, coming with a certain “wow effect” for sponsors.
The “wow effect” temptation is dangerous. At Societe Generale CIB, the design team asks for architecture and API sources, and pushes API reusability and front-to-back decorrelation. It’s quite unusual perhaps, but to quote Peter Parker’s late Uncle Ben from Spider Man, “With great power comes great responsibility”, and it’s our responsibility to get things right!
I’m going to close this series of articles with a traditional iceberg drawing:
It’s a metaphor you probably recognise. User experience is just the visible tip of the iceberg. At the end of the day, what good is a great looking screen if you have to wait 3 minutes for it to load? Or if the action you perform only succeeds one time out of three? Or if the information is only right 80% of the time? It’s vital that we care about our APIs and data.
I hope you’ve found this series insightful and enlightening. Thanks for taking the time to read this far!
