Interviews

How Goldman Sachs Marquee connects design innovation with financial services

4 min read
Rebecca Kerr  •  Mar 6, 2020
Link copied to clipboard

Design innovation and financial services might not seem like they belong together—one requires broad thinking, rapid testing, and outside-the box ideas, while the other comes with extensive regulations and a fast moving yet risk-averse user base. But Goldman Sachs is trying to challenge that perceived disparity, combining innovation and rigor into a new approach to product design with their future play Marquee. It’s a first-of-its-kind digital storefront for institutional investors, with approximately 50,000 monthly active users to date, and a GitHub repository open to the public. It opens the way for investors to manage transactions that were previously available only by a phone call.

Marquee designers have the unique opportunity to whitespace design, source inputs from actual traders on the trading floor, and test and iterate with users in a live space.

Designing a greenfield digital product like Marquee comes with its own challenges, but chief among them is building a team of designers capable of handling the fast pace and open-thinking mindset of a startup design culture, plus (arguably) one of the most sophisticated user bases on the planet—all in the context of a highly regulated financial institution.

We took an hour to talk with Bianka McGovern, vice president of Goldman Sach’s User Experience team, and Tyler Davidson, vice president and head of product design for Goldman Sachs Marquee, about how they find, hire, and activate a pioneering band of Marquee product designers.


InVision: What’s different about the problems designers are solving for Marquee at Goldman Sachs?

GS: Two things are interesting here. First is the complexity in which we’re working. Institutional finance is complex in and of itself, but when you’re fundamentally transforming the way major market players interact with your data, tools and trading systems—and also factoring in compliance and government regulations—the complexity gets deep. That’s an interesting place to solve problems.

It’s so complex it feels like you’re doing something impossible, like building a plane in midair.

The other interesting piece is that it’s unfamiliar territory. Usually in design you’re building products like newsfeeds and dashboards, products that have established patterns and components. Marquee is a digital product that’s enabling traders to analyze and ultimately execute transactions that previously could only be made by talking to someone on the phone. We are fundamentally rethinking processes that haven’t been addressed through design before. We’re empowering people to do new things. The impact you can make right now is huge.

The Marquee mobile app

InVision: Your team has grown quickly over the last year, from one to twenty. How do you hire the right designers for the problems you’re trying to solve on the Marquee team? 

GS: It hasn’t been easy. There’s a perception issue when you’re hiring at a financial institution. Designers don’t expect to find fast-paced, new product work when they see an opening at Goldman Sachs. But word is starting to get out about Marquee, especially given the recent press around open sourcing our Python toolkit for quantitative finance on GitHub.

We look for designers with a product mentality. This is the first time Goldman Sachs is building and selling a digital product to clients directly, so we need people who won’t be too precious when experimenting rapidly to find what works. Some companies talk about that developer-designer unicorn, but we’re looking for designers who can think like product managers. If you’re the type of person who likes solving complex problems, working close to product, and moving fast, you’ll fit in well.

The Marquee team scopes out a new user flow.

And when I say fast, I mean people ship every day here. We’re in a rapid experimentation phase, and there’s not a lot of overhead that prevents people from doing that.

There was a designer in her first week on the job who said, “I think we should try doing it this way,” and we said, “Okay, go talk to a developer.” She said, “What, just like that?”

But that really is how it goes. Those small, quick iterations make a big difference. When trading, mere seconds matter. If we can put out an experience that helps a trader do what they need to do faster, it can have an enormous business impact.

InVision: You’ve mentioned how new your product space is. Does that complicate things when you’re hiring designers?

GS: It can. Terms like “beautiful” and “well-designed” have yet to be defined in this space, and that’s uncomfortable for some people. We only know what ‘well-designed’ means after it’s out in the world.

At first glance, our interface is not what most designers are trained to think of as beautiful. But it’s what our users need. When you understand the complexity of the constraints you’re working in, not to mention the fact that you‘re changing platform functionality in a way that didn’t even exist two years ago, you start to see that it’s a different kind of beautiful.

One example: Designers are trained to use lots of white space and make things large enough to scan. But when the trader shows you her screen, she’s got Marquee sitting in a tiny window next to all the other trading products she has to use. She says, “It’s too big. You’re taking too much space. I want to reduce this, so it can fit in this little corner.” We can only know that if we stand behind her and watch for a while.

Traders prefer to see all the data they need in one screen, which presents challenges for the design team. (The screenshot shown is for illustrative purposes only.  It contains no actual Marquee content and no actual data from the SPX or NKY.)

InVision: Do folks have a hard time letting go of their old ideas of ‘beautiful’ at first?

GS: Sometimes. It gets better when they understand the sophistication of the problems and the impact of the solutions. But we don’t want those ideals to go away. We want designers who question everything–Is there a way to do this better, make it more beautiful?

More often than not, the most difficult part to grasp is the complexity.

InVision: How do you help designers jump into the complexity and get moving?

GS: We do a lot of listening. We create ecosystem maps. User journey mapping has been helping us see our way through the complexity together.

User journey mapping gives designers a handle on complex workflows.

Outside of that, we focus on making lots of prototypes, getting something out on the trading floor. You can watch a trader work all day, but you won’t know if you are solving the problem until you put a prototype in their hands. You have to get out of your seat and go talk to somebody as quickly as possible.

That part can be hard for new designers. Traders are an intimidating group. They don’t have time to waste, and they won’t slow down.

We sit one level above the trading floor. It’s loud and busy. Everywhere you look, you see giant monitors and people shouting above the fray. Each designer has to know the traders using the software. She has to be bold enough to walk down the stairs, march right up to one of them and say, “Got a second?” They might take a look and give feedback, or they might say, “No. Come back in an hour.” Despite the frenzy, traders are almost always willing to give feedback.

We’ve tried making it easier, having groups of users come in and look at designs with the team, but it’s not the same. The chaos of the moment is part of our users’ experience, and we have to be in it with them to know if a new idea works.

That definition of “good design”–we’re inventing it there on the trading floor. You’re tapping into an inkling of what it could be, and then iterating fast.

As UX teams, we have to be careful not to be too precious. We operate like an early stage startup. We have to be comfortable with MVPs. You’re not waiting to put up the most beautifully designed thing in the world before understanding if it’s actually useful. You’re hammering out enterprise tools that solve real problems.

0