Designing for Developers: Ulrika Andersson
Today, we have a special guest on the Developer Products newsletter.
Ulrika Andersson is a product designer with experience from companies like Postman, Spotify, and Linkedin. She’s joining us to share her perspective on designing for developers and her experience working in developer tools as a product designer.
Ulrika, can you share a bit about your background in product design and what you’re working on now?
Hiya! Right now, I work at Postman, an API collaboration platform. Postman is entirely devoted to the interaction of various APIs, so it's very much a developer tool and our main users are software engineers. In addition to engineers, we serve people who work alongside engineers, like product managers.
We also are increasingly serving people who want to perform software engineering tasks without it necessarily being their job: these folks are often students, data scientists, and sometimes marketers.
I have spent most of my career designing for enterprise users. When I got started in 2015, there was some kind of idea that enterprise was the boring design that did not have to be good since users had to use it for their jobs. I have not at all found that to be true in practice. Enterprise design is high stakes since users are usually subject matter experts who have very little patience with a poor experience once they pay you upfront for it. If you can offer a good experience, however, they will reward you with higher feature adoption, and that shows up in revenue numbers.
Choosing Developer Design
Designers often lean towards crafting experiences for consumers. What motivated you to pivot towards designing for developers specifically?
To me, designing for the nature of data and dynamic assets is the most fascinating part of design work. It is very elegant, abstract, and reminds me of some concepts from music and poetry, like the Burroughs cut-up technique.
I first became interested in platform topics when I was working in ad tech at LinkedIn. There, we had all these dynamic assets like audiences and tracking pixels that all seemed to be floating around between various enterprise apps. No one seemed to give much thought to them as a consistent entity that would be understood the same way by all LinkedIn apps that wanted to access them. As a result, we had a lot of duplicative efforts that tried to work around the inconsistencies. I thought the design team could provide a valuable service by standardizing these assets so we could present them as consistent entities to our users. I had a good first experience with this when I designed a standardized access path to our tracking pixel. We saw huge lifts in adoption over a short period of time.
Later on, I was placed on the team that was tasked with offering up the LinkedIn API products to third-party integrations. It was then that I really understood what an API is, and that dynamic assets could be designed into products and offered up for use by internal and external teams.
Differentiation in Design
In your experience, how does designing for developers differ or resemble designing for other professional user groups?
The difference is that the topics in developer tools are considered harder than other enterprise tasks, so design teams often struggle with a lack of subject matter expertise. For me, I’ve been able to develop a few rituals that have allowed me to generate user stories and UX requirements in a reliable way, but it took some time to do that.
The similarity I see to other enterprise apps is that the cool patterns developed for other creative tools like Figma, Canva, and ad tech apps actually work very well for developers. This tendency is picking up as developers are increasingly treated more like content creators who want to share their work publicly and have it easily discoverable.
Developer Tool Experience
Considering the plethora of tools available to developers today, how would you characterize this user’s overall experience? Could you highlight some notable positives as well as any challenges or areas for improvement?
On the bright side, I'm happy to see the business side of developer tools gaining momentum, with an increasing number of companies recognizing the importance of delivering robust developer experiences. The shift towards viewing developers as content creators is positive; it opens the door for us to adopt and adapt established design patterns to the developer realm, creating a sense of familiarity. I often find myself referencing Jakob's Law of the Internet User Experience to make this point.
A significant challenge unique to developer tools, as opposed to applications designed for other professionals, is their profound fragmentation. Conversations with users often reveal a common narrative: the need to hop from one application to another in search of the tools required to complete their tasks. This fragmentation presents a daunting challenge in trying to weave these experiences together without descending into chaos.
The solution lies in a comprehensive and meticulous overhaul of the information architecture, complemented by a navigation system that truly represents the service. This is a daunting task that many companies shy away from, daunted by the complexity and scale of the challenge.
Organizational Dynamics
When it comes to designing for developers, are there distinct organizational differences you've observed? For instance, do design teams adopt unique structures or rituals compared to those catering to different audiences?
I have noticed that design managers often struggle with managing teams that work on this topic. If a manager sees themselves as a kind of creative director, leading the actual design work, they will face an uphill battle in mastering all the subject matter expertise required to manage the team effectively. As a manager, you do not want to find yourself in a situation where individual contributors (IC) designers spend most of their time explaining subject matter topics to you, while you are expected to manage performance.
If, however, your design manager adopts a more enabling style, where they trust the designers to make the right decisions and primarily support their design process, they tend to have an easier time contributing value.
Partnerships in Design
Collaboration between designers, engineering, and product management leads is needed for product success. How does this collaborative dynamic differ, if at all, when focusing on developer-oriented products?
The PM (Product Management) aspect tends to be similar to other products, but the interaction with engineers is a bit different. They are building for their colleagues when they work on Dev tools and tend to be significantly more involved and opinionated in the design process. I really love this part because there is nothing more enjoyable than a super engaged engineer who wants to be part of the design process, attend research sessions, and collaborate on the design requirements.
I once worked on a platform feature, and the entire 11-person engineering team showed up to our user research sessions. I later learned that many of them were part of a startup that initially built that part of the platform, and they were sort of coming to see their "baby" grow up. It was so cool.
Thank you so much for taking the time to share your experience and insights as a product designer in the developer space.
You can find more about Ulrika and her work at https://rubrika.work
.