How BlackRock’s UX Design Lead builds bridges between engineering and design
Emm Pakdee built his career as a UX consultant for hire, with a background in engineering. Lately he goes by Vice President, UX Design Lead for BlackRock, the world’s largest asset manager, with $6.5 trillion in investments under management as of April 2019. Here, InVision’s Rebecca Kerr speaks with Pakdee about his background in engineering and design, and how he’s become a bridge builder between the disciplines.
Rebecca Kerr: How did you end up doing UX work for corporate brands?
Emm Pakdee: In the ’90s I built an ecommerce site for my music label. Then I started getting pulled into engineering projects by word of mouth. I ended up doing UX and UI engineering consulting for Major League Baseball in 2010. I took on government projects, and I worked with big digital agencies like SapientRazorfish and Accenture, solving process problems and running workshops in big banks.
I billed myself as a UX problem-solver. That means I’d come in, evaluate the situation, clean up the crap, give them a process, and then leave them to it. It’s an engineer mentality–How will this scale over time? How can I hand this off to the owners?
There was a pain point I ran into all the time as an engineer: Designers kept handing me these fantasy UI designs. They looked amazing, but there was no good way to implement them in a way that could scale. That became the pressing problem I wanted to solve next.
I decided to shift focus. Instead of being the person implementing the designs, I wanted to become the person delivering on the UX/product design side, in a way that would make sense for engineering and be scalable over time.
RK: How do you resolve that problem, the design fantasy vs. the engineering reality?
EP: I’d say the two biggest parts of the solution are the processes we’ve built around communication: first with our own engineers and stakeholders and second with our customers.
We’ve gotten really consistent about communicating priorities and processes to internal stakeholders in a way they can latch onto and participate in. With engineers, we’ve started spelling out every single interaction in the design.
[Read more: Why you should have a BFF in engineering]
We are also putting a lot of effort into building our Aladdin Design System to centralize the specifications, guidelines, and code around many of the common elements used across these designs. We want to make this as efficient as possible for our dev partners.
RK: Tell me more about that new communication process with engineering. What does it look like in the day-to-day?
EP: We use InVision to craft a prototype, ranging from lo-fi to hi-fi. Once we go through a series of user testing to validate the concept, we iterate, refine, and have a visual designer from our UX team craft a high-fidelity prototype in InVision.
We share that with the development team. They use InVision Inspect to grab all the CSS and visual design specs, dimensions, sizes, etc.
In the meantime, throughout the build we have a weekly sync with engineer leads (one front end, one solution-architect lead), visual designers, researchers, product managers and myself. We show them a prototype and say, “This is what we’re working on: Have questions?”
They might ask something like, “What happens when they deselect this item? What happens when users hover or click? Where are they supposed to go after this? What happens if there’s more than ten rows in this table?”
We can use comments to help explain this in InVision Prototype, but with the level of detail we want to share, it gets too huge. So we do that ourselves in Confluence. We document everything: “This is what the visual looks like; here it is in InVision Inspect. Here is the design system component where you can get the code. Here’s the intended behavior…”
RK: What’s your secret to convincing engineers to embrace UX principles?
EP: I show them videos of real user-testing sessions. We’ll have a movie day, with popcorn and everything, and watch. Usually it’s a batch of five internal and five external trader tests. We’re looking for trends and patterns.
The bonus to showing those videos is that it helps me convince the engineers of the direction we need to go. If they insist that we really need this new feature, we can show them the actual user footage and say, “Look, they don’t need it. It’s nice to have, but the users don’t think it’s necessary.”
It’s evidence. Engineers need the data. They need the evidence.