Anatomy of a Design team

There are many ways in which a design team can be structured. Many a times this is also influenced by the organizational structure of product companies.

At Housing.com over 4 years, we had team sizes that varied from 10 to 40 at different times. In 2015/16 when the company scaled to its peak while building a wide array of products, the team size ranged in 30–40.

In 2017/18 when the company was more focused in solving the core real estate problem the team size was around 10. During these times I tried to structure the team in a way that was most efficient and productive for the organization and the designers. In our efforts to do so, we brainstormed and executed different team models.

Design company is where designers are distributed in sections within design and and from each section there are members in a business unit.

The Design sections could be:
User Research— Their work was in the field conducting research and interviews and testing out prototypes with users.
User Experience— They would have all the data and insight to work with and would knock out the wireframes and interactions and interfaces.
Visual Design — From where the wireframes would end, the visual design would begin. Typography, Visual language, platform specifics, and illustrations was their forte.

Here the designers had specialized roles, and there were three segments within the design team. Each of these segments within design had it’s own lead. In the org overall, every business unit had people from product, design, marketing, and business teams. Org level units had their own design lead who worked with (as an example) 1 person from User Research, 1 from UX and 1 from Visual Design.

This would become a classic waterfall model where designers would stick to their project, their role and have relatively little say beyond their own domain.

What are the best practices here?
This is a setup that is more hierarchical. For the junior designers it becomes very important to have the right people leading them and as a Design leader it is vital to understand the inclinations of designers towards a managerial or an Individual contributor role.

Pods are smaller units that work independently with members from all departments. An example of a pod is :
2 Designers
6 Developers and
1 Product Manager.

Each pod unit is led by a PM. When an organization has different units that function largely independent of each other and departments (Design, Tech, Product, etc.) that do no necessarily exist independently, this is what we get. They chase their own metrics and solve a set of problems that mostly do not have an overlap with other pods.

As soon as this kind of a structure is laid out, the one / two / three designers in a particular pod are responsible for the end to end design of experiences the pod is building. An example of a pod could be User Acquisition , Supply Products, Communication, etc. This setup many a times may result in designers working on top of experiences that are built by designers in other pods and these are challenging scenarios to keep a team happy and efficient.

What are the best practices here?
As the pods are heavily involved in their own problem statements, it is key to get the team together on a frequent basis so that everyone is aware about what’s happening on the product as a whole. Many a times one change on a home-screen may affect other funnels.

Having a “what’s on” design board that is updated everyday by each pod gives the relevant people a chance to chip in incase they feel this may affect something else. This board may ofcourse be physical / digital but I’d prefer to have this a physical thing. Who doesn’t love tangible design ;)

Lean Team is a single layer of design team that plans it’s sprints across multiple problem statements together.

When the design teams are much smaller and some skills are unique to only some designers, sharing of resources becomes important. A designer could be very good at motion and another design could be a very strong illustrator and visual design guy.

In this setup, it makes sense to have the team work across different projects as a single unit, with one designer responsible for one project but everyone contributing. While the effort was estimated upfront, we looked wether or not as a unit can we work on a certain number of problem statements in a given time.

What are the best practices here?
The sprint planning discussions here are key. One designer may need to evaluate multiple projects they would work on and only collectively can the promise of a sprint be fulfilled.

Cohorts are defined groups of product units where each one of them attacks a certain problem (much like a pod) + a core layer of design that works across the units : Central Design. This layer also works across marketing, branding, communication, research, prototyping and testing and has it’s own problem statements to chase.

Let’s face it, pods work great for an organization even if it means extra effort on the communication front for the designers. What gets limiting here is that a certain designer may get involved deeply with a project and it may then lead to a very static set of roles and responsibilities. For someone who always works on a supply project, the learning becomes limiting.

With cohorts, for a span of 6–8 sprints the designers are aligned to product units and then there is shuffling. This in my experience has worked brilliantly. Why?

Thank you!

How do you feel about being a part of different structures? Do you have any insights into how different structures have brought out the best in you or the contrary? I would love to hear your thoughts in the comments.

Related posts:

Religion is a well thought of idea that consist of ideals that help people and communities everywhere. But, it is something that has been around for thousands of years with seemingly little change or…

Please note that this is my personal opinion and should not be regarded as investment, financial or legal advice. I am a CPA that worked at PwC and E&Y. I was first introduced to blockchain…