Foundational Teams for UX

Vineet Kumar at UXDX APAC. Video: https://youtu.be/WSuRQ7k-pO4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and what Postman is

[00:00:00] Hope you guys have had an awesome Thursday so far at UXDX and learned lots of new things. For me it's always been great to hear all the crazy different perspectives that I get from the people who are talking at this event. I want to be sharing some experiences from our journey in building the design org at Postman today, and how foundational teams sort of helped in that journey as well, and hopefully there's something you can take away from this talk.

[00:00:34] A quick introduction. I'm Vineet, I work as the director of UX at Postman. I've been fortunate enough to have joined at a very early stage in the company, so I've seen it grow from a team of 15 super motivated people to the 600-plus member unicorn it is today. It's been an absolutely wild ride, and I'm always up to discuss that journey with people, and learn and share. So feel free to catch me on Twitter or on LinkedIn and would love to share more perspectives.

[00:01:17] The agenda for today is mostly to take you through some of the pains and natural frictions that we encountered as we scaled both the design and product teams within Postman, look at some of the core principles for org design that we hold dear, and then look at how we applied it to actually create foundational teams for UX at Postman. I think there's a bit in here for everybody, and for every design team out there. Whether a foundation team is right for you or not is, I think, a relevant question, so hopefully at the end of the conversation there are some takeaways that are practically applicable for everyone.

[00:02:09] A quick primer on Postman itself. Postman is an API platform for building and using APIs. We're like the do-it-all of APIs, whether it is discovery or testing or actual deployment and publishing. The idea is that Postman simplifies each step of this API life cycle and streamlines collaboration, so you can create better APIs faster and collaboratively.

[00:02:43] We're building towards this vision of an API-first world, which consists of a world of 100 million connected builders. An interesting fact today is that only about one percent of computer users today actually develop software. We want to try and democratize that, make this accessible to more personas, more use cases. We want to help everyone to build software that fulfills their needs and empowers them to be a more active participant in modern society. Our extremely talented lead visual designer, Shruti, she's done an amazing job representing all of this into a graphic novel. You can find that on firstworld.com[?], so feel free to check that out.

[00:03:37] At the end of the day, everything we do at Postman boils down to the individual steps of this flywheel. Developers typically use Postman to run tests and master APIs. When they find intrinsic value in Postman in their own workflow, they sometimes advocate for Postman to be used at work. At some point these development teams use Postman to build and maintain internal APIs as a team. This encourages cross-functional development and collaboration via the Postman platform, encouraging then companies to create and share public APIs through Postman, because they know that their audience is there as well, which completes the flywheel, allowing developers to discover these APIs through Postman again.

Design as a market differentiator

[00:04:40] At the end of the day, people use Postman for a very simple reason: it empowers you to build better software. We try and visualize complicated abstractions and interfaces. Software development can be really, really hard, but it doesn't have to be. We want to try and provide context wherever possible, and intelligently enhance your experience working with APIs, so that at the end of the day you're building better software.

[00:05:08] Now, interestingly, we've always viewed design as a market differentiator in this space, and that's mostly because the future of software development is low code and no code. If we want to be able to democratize software development to more than just a traditional developer persona, we need to be able to use design to effectively represent abstractions which have been embedded in developers' minds in a way that it's understandable to everyone else.

[00:05:47] And for all practical purposes, what we've realized is, having a design team brings a completely fresh perspective into the software development process. At the end of the day, user delight is key to adoption and retention, and anything we can do to build delight in our customers' experiences is going to help them continue using Postman. I'm going to keep coming back to these points as we talk more about how the org is built on some of these core foundations.

How the org scaled from three generalists

[00:06:24] As I mentioned, it's been an absolutely wild ride so far. When I joined back in 2015, early 2016, the entire product team was organized in a very, very simple way. You had a set of people who are working on the web app, you have a set of people who are working on the desktop app, and no complications. Everyone threw ideas at each other, there was a lot of collaboration going on. The UX team was just three generalists, which meant that we were looking at end-to-end product design, including content, research, visual design, interaction design, etc.

[00:07:10] Moving forward three years, the product team evolved to a point where we had squads that could specialize in certain problem spaces. This would mean that the UX team could lead design for those individual squads. Specialists like research and content would work across all these squads, and this is when we actually hired our first UX researchers and content writers.

[00:07:43] If you look at Postman today, our squads have consolidated into even larger units, collating use cases and building around certain common personas. The design function has kept pace, with embedded specialists in product teams as well as certain core foundation teams. I'm just going to take a small break here, just give me a second.

[00:08:16] Sorry for that. Where was I? Today the design team in Postman consists of not only UX generalists, as well as embedded research and content people, but we also have our own engineering team that helps build out some foundational experiences. I'll talk more about the dynamic between these different teams when I go into detail into our team structure.

The friction points we hit

[00:08:48] Along this journey there were some very obvious friction points that we experienced, which have for all practical purposes defined our decisions around building the organization.

[00:09:03] The first and foremost was a lack of domain ownership. There were areas of the product that multiple teams had vested interests in, which very, very often saw a lack of ownership. With a user who isn't necessarily aware of these team boundaries, it was hard for independent teams to contribute to the same user experience, and what this typically resulted in was a fragmented UX.

[00:09:36] We also saw varying maturities in the product teams themselves. There were certain products that were at a very early zero to one stage, and there were products that had been out there for a couple of years with a well validated, working solution. Within the teams that were building these products themselves, you would have skill gaps between different designers and developers and engineers. Some would have historical context on how some of these abstractions were built from the ground up, so they could more effectively iterate on top of them, whereas people who were joining new into the organization had to have a more rigorous onboarding to be at the same level as everyone else. So it became a foundational problem that we needed to make sure that there is knowledge being distributed evenly across all these teams.

[00:10:31] I think a follow-up to this is the high cost of onboarding. Because onboarding needed to be curated and up to date to ensure everyone could contribute to the design process, we had to spend a lot of effort and diversify our onboarding and specialize it for the specific teams that people are joining into. On the other hand, there was also a supremely high cost of not onboarding, which is just generally slower turnaround times in terms of shipping your first feature. All of this was super critical in deciding how we build our foundational teams.

[00:11:10] To talk about a few more examples that might help clarify this a bit more: this is a screenshot of the settings page in Postman. If you look at it, there were a whole lot of different teams that had a vested interest. Every time a team wanted to introduce a configuration they would just say, okay, I'm going to go put it in settings. But no one is thinking necessarily about the settings experience as a whole, and how users might discover new configurations when they come on to this integrated settings screen. So it was really a case of too many cooks, but no one to lead the show.

[00:11:52] At the end of the day, we also had a lot of centralized teams that ended up working in silos. They were typically operating at a level apart from the actual product, so very often they would lack the context that the product teams themselves could provide. Every time a centralized team actually needed to create end user impact, they would absolutely have to collaborate with the product team, and that just created a lot of unwanted dependencies, sometimes even misaligned priorities, and hence very little value being created, at least in the eyes of top level leadership.

Three org design philosophies

[00:12:37] Recognizing all these friction points, before I go into the kind of solutions that we explored for these problems, I want to quickly go through certain wide org design philosophies that have stuck for pretty much everyone in Postman.

[00:12:58] The first is this very interesting inverse Conway maneuver. The first time I heard it, it was pretty much a mind-blown situation. The second is about treating your function as the product itself, or maybe even your organization as the product. And the third is building alignment through feedback loops.

[00:13:22] Melvin Conway in 1967 drafted Conway's law, which stated that organizations who design systems are often constrained to produce designs which are pretty much replicas of the communication structures of these organizations. This seems pretty obvious when you think about it. Systems inherit the culture and certain traits of the team that built it, and the effectiveness of the team at the end of the day is dependent on the communication structures within the organization. So it seems almost obvious that there would be some mimicry going on in terms of the org and the communication structure.

[00:14:11] Thoughtworks sort of flipped this around, and they recommended evolving your team and organizational structure to promote your desired architecture. So it's not necessarily how the problem spaces are defined today in your product that should define how your teams are organized, but it's what you want to build towards that you need to be using as your frame of reference. Ideally your technology architecture will display isomorphism with your business architecture.

[00:14:43] Let's take this as an example. You're building an e-commerce site, and the application code, you've been thinking about how best to architect it so that modules are independent, every problem space is well defined. So you might have a marketplace module, a discovery module, a checkout module, a fulfillment module, etc. These are all good indicators that these are the product teams in themselves that you should be looking at building out within the team, to be able to help enable you in these workflows.

Treating the function as the product

[00:15:25] The second big philosophy that we hold on to is treating the function as the product. If I were to say that I want to take good design and sell it to everyone else in my organization, so that everyone realizes the value and everyone in turn pays some sort of tax for using that function or tool, I think there's three main questions that keep popping up every time you think about it as a product.

[00:15:56] Like, how do you build the best product? For this I go back to frameworks like the Jobs to be Done framework, which help you frame what people are looking for from the design function when they look at any UX team in an organization. Ideally the team should be ensuring that designers and developers in Postman can build out the best experiences for their users easily and effectively. The only time they look at design as a centralized organization is when they are looking for inputs at a centralized level on how to build these experiences.

[00:16:38] The second big question is, how do you grow the product? You've totally sold a few key stakeholders on the value of good design, but you now need to grow that adoption. You want to communicate that value continuously, and you want to make sure that you're building tools and resources that are easily adopted. The adoption of these tools should be your north star to measure how effective the UX practice is in your team.

[00:17:05] To some extent: is the product actually providing value? The team should be able to validate what they're building against end user outcomes, and in this case you have two sets of users. Your first is your key internal stakeholders, and the second is actual end users, who you can measure impact on organizational changes.

Feedback loops and the design system

[00:17:33] The third big thing is around providing feedback loops. Just for some context, I'm going to go back a few years now. The idea of a design system in Postman is pretty old. We've had some primitive version of a design system for almost four years or five years now, but it was primitive in the sense that it was mostly tooling that was restricted to, let's say, only designers, through a UI kit or a pattern library. It's only recently in the last two years or so that we've expanded on that and built out more offerings for different personas, so that developers, product managers, everyone can come into the design system and actually find value in there to build out experiences.

[00:18:23] Now, the tricky part here is that because the design system team was a centralized team, there was always this question of, okay, what do we build next? The first few months and years were pretty easy, in the sense that we were always trying to catch up with existing patterns that we were trying to systemize. But once you had a v1.0 out and you had a mature library of components, what do you build next? What we realized is, because of the way the design system operates centrally, we were always dependent on incoming feedback in order to be able to do anything around roadmap alignment and planning.

[00:19:12] A key part of what we tried to do in the foundational teams that we built out, that I'll tell you about, was create sister teams to centralized teams like design systems that can provide these feedback loops. Teams that operate in a way that an end result of the way they operate is feedback going directly back into the design system.

Surface delight and deep delight

[00:19:38] At this point I want to come back to a point I had made earlier about design as a key market differentiator. According to Maslow's list of needs, user delight can broadly be classified into surface delight and deep delight, and we use this as pretty much the cornerstone of how we want to build out the product design org.

[00:20:05] Surface delight is in intuitive interactions, in microcopy, in tactile transitions and thoughtful responsiveness. What we realize is this is the lowest common denominator of what can be abstracted out and shared with product teams in order to empower them to ship better experiences.

[00:20:28] Whereas deep delight truly took a better understanding of the jobs that your users are here for. It required building in close contact with our vocal community, and it required a mindset of validating more than UI[?]. This is something the product design teams were already really great at.

[00:20:48] Just based on this classification, the first division of the design team in Postman is based on these two pillars. We have a product design team which is focused on building deep delight, understanding problem spaces better, and these contribute directly to adoption and user retention across Postman products. Most of these folks are UX generalists, and we are trying to flesh out teams there by embedding researchers, UX writers, wherever it can provide value to the rest of the product design team.

[00:21:24] The second pillar, that focuses on surface delight patterns, is the UX foundation, and this is the loose amalgamation of all our foundational teams for UX today. These teams build the basic blocks of the Postman experience. They operate across product teams, so they're not just involved in building out these resources, they're also invested in how people are using these resources.

The three foundation teams

[00:21:54] To get right into the nitty gritties now, the UX foundation team in Postman today is composed of three huge problem spaces essentially. We have the design systems team, which is I think a much more well understood concept today. But one thing we did in a recent realignment was make sure that the entire focus of the design system team is on system adoption. At the end of the day the idea was that if we are actually building value, adoption would be the best indicator of that value. We provide tools and resources and guidelines for designers and developers and product managers and a variety of other personas in building out experiences, and we do it at a centralized level so that a pattern does not need to necessarily be repeated across products.

[00:22:51] The second big team is the application UX team, and I go back to the point about certain gaps in domain ownership that we were seeing. The idea of the application UX team was to take ownership of some of these global experiences that no single product team might be responsible for. These are genuinely properties that might not see a high velocity of iteration compared to another product team. The team would provide visibility into user retention at an application level. So very, very simple questions like, how complicated is my navigational architecture, etc. These are questions that we want to solve for the whole of Postman.

[00:23:44] We also want to be building emerging patterns that aren't ready for system-wide adoption. The way I see it, the application UX team is sort of like a testing bed for patterns before they become something that lives in the design system. So if we see a commonality between different product teams building out an experience, we try and put that into a pattern that can be communicated through the application UX team. And once it's been there for a while, it's been vetted, it's matured, at some point we hand it off to the design system team to make that process a bit more self-serve after that.

[00:24:24] The third, and I think in the long run probably one of the most important teams, is the UX maturity team. This stems from an idea we had long, long back, that we wanted to quantify the quality of experience our end users are having in Postman. The main job of this team is to expand the definition of the UX maturity model in Postman itself. They help product teams improve their overall UX. Similar to application UX, these guys are identifying emerging patterns and gaps in UX offerings, and are offering resources that can help mitigate UX issues.

[00:25:04] So again, going back to that feedback loop diagram, the UX maturity team might be the first responder whenever there's a UX issue. When they start seeing patterns, at some point application UX gets interested and decides, okay, this is a big enough problem for us to be worried about at an application level. And at some point it matures so that it's not even a question of an application level anymore, it should be part of our design language, and at that point it becomes a part of the design system itself.

Takeaways

[00:25:43] I think a few takeaways for everyone, to think about a bit more, in terms of how foundational teams can be effective for you. At the end of the day, it's not some radically new model. We've talked about hybrid models for a very long time. I think foundational teams sort of enable the best of both worlds in some sense. Centralized teams are great for consolidating UX practices, they enforce unified processes and quality, and it's meant for everyone, so designers and developers can contribute to that team at the end of the day.

[00:26:26] But embedded teams help with better context on problem spaces, and they're always much better for a faster rate of product development, because you don't have to worry about dependencies and waiting times for someone to actually get done with what they're doing in order for you to be able to do what you need to do.

[00:26:47] With foundation teams, they act as the centralized offering in any design function. So your product teams can maintain velocity without any external dependencies, because they have embedded designers working with them, but you also have foundation teams acting as the governance body of sorts for design across the organization.

[00:27:10] For design as an industry, there's also a lot to be learned from other peer verticals in organizations, like engineering, security, quality. All of these teams have had the same question in their minds, and a lot of them have built foundation teams way before it was common in design, at least in my experience, so there's probably a lot to learn from there.

[00:27:37] I think the most important bit should be that you shouldn't be replicating the what and the how of foundational teams from this presentation without understanding the why. I think it's super important to clarify the exact pain point that your team is experiencing while scaling, and then figure out a solution that best fits that. And you can take inspiration from something we've done, or other teams have been doing.

[00:28:10] I want to end this talk with a quick shameless plug here. We are actually hiring for a design manager to lead our UX foundation team. So if all of what I mentioned today excites you, I'd love for you to reach out to me on Twitter or LinkedIn, and maybe we can talk a bit more.