Working Across in #DesignAndTech
Designer Dim Sum conversation led by Joana Koiller and Moses Ting
An online seminar led by design leaders, Joana Koiller and Moses Ting, led to a variety of viewpoints being shared in the Designer Dim Sum Network Seminar organized by Jackie Xu with John Maeda.
Joanna Koiller JK/ Many companies (including One Kings Lane, where I worked, and LinkedIn where @mosesting used to work) adopt the cross-functional pod model. This model in some ways decentralizes the design team in favor of embedding individual designers within each pod. Here are a few discussion points:
- Collaborative process in the cross-functional team: what are some best practices for working with PMs and engineers? What’s the balance between keeping the team nimble and collaborative, while also defining areas of ownership and responsibility?
- How to maintain a cohesive design language, team and culture in a decentralized system?
- What are some environmental and cultural factors that help making this model successful and effective?
Moses Ting MT/ During my experience at LinkedIn, I was asked whether I wanted to sit with my designers or with my product team (product, marketing, and eng). The way I decided was based on how often I would communicate with each set of people.
WHERE YOU CHOOSE TO SIT (AND WHEN)
MT/ I stayed with my product counterparts because I would communicate with them on an hourly basis. Whereas when it comes to fellow designers, I would probably talk to them at most once a day since we’re all working on different projects/products.
Matthew Beebe MB/ While designing WebOS at Palm, the design team sat together — relatively isolated from our engineering and product colleagues.
MB/ I barely questioned this arrangement as it was very familiar to me to be sitting around other designers just like I always did as a design consultant. At some point I started to really feel this isolation as a negative … I felt I needed to be mostly away from my desk to be with the engineers I was working with.
MB/ So for the first bit (when we were really starting from scratch) it felt like the right thing to be sitting with the other designers. We had a fat bandwidth of communication which helped us develop a consistent and coherent set of basic patterns for the platform. I had a roughly weekly cadence of reviews with the engineering teams I was working with.
MB/ Later in the process we were working on details of each specific app that shipped with WebOS. I needed that fat bandwidth with my engineering colleagues and I spent most of my time squatting in their cubes. I would still communicate with my design colleagues but a weekly cadence seemed about right.
MB/ So I ended up feeling like there were times when I was better off sitting with other designers and times when I was better off sitting with engineers.
Diogenes Brito DB/ Well, you’re right it’s best to sit with whomever you need to communicate with most often, so I too would choose to sit with my product team. However, a direct line to the rest of the designers is also crucial, so I wouldn’t want to be too far from them, or not have a separate place where just the design team (featuring relevant guests) could come together to work together. At Slack, our design team is distributed between San Francisco and Vancouver, Canada, so we talk a lot in … Slack. We have channels for our project team (#proj-X), but also for the design team (#team-design), and a #ui channel that can bring both groups together when needed. So that’s our virtual space.
DB/ Our company has been expanding so quickly that we move around every few weeks, and throughout all the moves I’ve found it’s best to sit near the web developer executing the design, and as close as possible to your “braintrust” (to steal Ed Catmull’s concept), people on any team with any function who know how to give good feedback and are good to bounce ideas off of.
DB/ I’m intrigued by office setups, such as Valve’s, which strive to represent physically the dynamic, changing nature of product teams and collaboration groups.
JK/ When I was at One Kings Lane we experimented with both models: designers sitting together as a group, and embedded within the pod. I’m currently experimenting with a merger of the two models (similar to the desk on wheels approach). Depending on the stage of the project, I’ll be next to the lead PM, or pairing up with another designer to brainstorm, sitting next to the engineer during the implementation stages and sometimes even working remotely (from home or a cafe) if I need some heads-down time to focus.
JK/ It seems to me that the mission around which the cross-functional pods are structured is also very crucial. A challenge we’ve faced with this model is that a “virtual line” is drawn through the experience in order to define scope and areas of ownership for each team. This sometimes creates issues in designing a holistic experience. A concrete example: in redesigning the cart/checkout flow, the email confirmation for an order (which is part of the user flow) fell of the scope since emails were the purview of a different team (that had a different set of priorities.)
JK/ A designer friend at another tech company told me they have recently moved away from a “platform” approach and towards “user-centric” team missions, and that is working better for them.
WHETHER OPEN PLAN IS THE BEST PLAN
Marie Kacmarek MK/ One thing stands out to me right away: having to head out of the office for heads-down time. This is so common now with open offices. I’m not a big fan — as an introvert who shores up creative fuel with my head down. Yet I’m not shy and still love people and collaboration. But sheesh, a little privacy goes a long way! And noise canceling headphones, well, they hurt my head after some time. I feel like I’m in half a netherworld with them on. It’s the trust thing, I suppose. And hiring right. There’s a great article on the topic here:
MT/ Has anyone worked at IDEO? Weren’t they one of the pioneers of the movable desk (desks w/ wheels) arrangement?
MB/ I worked at IDEO during two space redesign projects. The constant question was how much space to dedicate to personal space and how much to shared project spaces.
MB/ I always preferred to sit in the project spaces and be surrounded by all the people and posits from that project. I hardly ever used my small personal workstation. So I liked the configurations with very little private space and many project rooms — that way it was very likely that every project could get a space.
MB/ There were others who had a strong preference for lots of personal privacy and storage space (people had years and years of prototyping that they couldn’t part with!). Some spend a lot of time on the phone and needed privacy for that. it was hard to come up with a plan that seemed equitable and also served everyone’s different needs.
MB/ There was a period when the desks had wheels but in my experience they hardly ever moved. People would configure their project spaces in ways that were specific to the project, but everybody had a “home base” that pretty much never moved (and in my case I hardly ever used it).
MK/ Sounds like their were lots of options even though the space was open. Copious project spaces/rooms/wheeled furniture and a little personal space reflect and respect the individuality of employees’ working styles and assignments (which we all know change on-the-fly). There are times when ozone-penetrating guffaws are a hoot, and other times, well, eardrums a-bleeding! I tend to move toward cross-disciplinary team setups too, especially in ideation (big team) and execution (sitting with an engineer). Then there’s that chasm in between, which in my case is typically more designerly, with dips in and out of engineering to see if the ideas are feasible, or could be made better, which they often are thanks to the left-brainiacs.
JK/ I feel the same — there is a stage in the process of developing a product idea and design in which heads-down time is essential. It’s when I want the opposite of collaborating — I need the quiet time to synthesize thoughts, inputs from others, what was learned from research and and requirements gathering. I think it is necessary for companies that go with an open floorplan or desks-on-wheels configuration to either allow employees to work remotely, or to have dedicated spaces for heads-down individual work.
JK/ These were some great discussions on how the environment influences collaboration — any thoughts on what helps drive a successful collaboration between designers and other cross-functional partners working in the pod system? (Specifically, designers & PMs and designers & engineers). Julie Zhuo wrote a set of articles on this topic a while back:
BLURRING THE EDGES OF ROLES
MT/ One of the best concepts I’ve come across is the notion of “Blurred Edges,” where the interface between designer/engineer or designer/pm is fuzzy. A concrete example might be for the designer to directly define styles and typography in XCode or Android Studio. Rather than the old fashioned method of creating visual specs where it has to be re-transcribed back into text form.
MT/ Or, operating at wireframes between PM and Designer and to help define the goals if a specific feature/page. Although much is asked and much is expected from a designer. We’re now expected to understand business metrics as well as understand the language of development. It’s oftentimes difficult to be able to jiggle everything that a designer needs to do to be effective. We’re all asked to be that magical unicorn in charge of copy, prototyping, visual design, marketing, branding, color theory, user interface, flows, interaction design, motion design, mobile design, responsive design, web design, accessibility considerations, user research, video production, iconography, typography, etc…
IT’S ABOUT WORKING (TOGETHER) WITH EACH OTHER (AND CONSTANTLY)
MT/ While working cross functionally, perhaps another way to phrase the question is: “How to leverage cross-functional members and enable them to operate with a designer’s mindset?”
MT/ What is the single most important thing that an individual designer can learn/do to delivery amazing products/experiences with their cross-functional partners? Number 6 and number 10 might be useful from @udanium’s medium article
MB/ Mine is: Get to know the people you are working with. How they like to work, what they are good at, what they like to do/don’t like to do. That’s the starting point for great working relationships. Use that understanding to figure out the right way to work with each team member.
Uday Gajendar UG/ Internal team empathy is crucial. Shows respect and builds trust, critical elements to healthy team dynamics. I urge folks to read “Car” by Mary Walton, about the birth of the Ford Taurus, that radical design way back in 1990s. The subtitle is “the drama of the American workplace” which is a big hint about what product development is really about!
MT/ So with design, part of our effectiveness comes from developing a relationship with our counterparts first?
UG/ I remember when I first started way back at Oracle, my mentor called me in for a quick check-in on my first few weeks. He said that what I’m after as a designer is influence, in order to effect change. Yes, that’s a wonderful ideal to strive for, and always aim high! But also grounded in realities of political and human complexity. Eames had a great quote about accepting constraints while ducking compromises. Or something like that…?
MT/
“I have never been forced to accept compromises but I have willingly accepted constraints.” — via Charles Eames
MT/ So perhaps what makes a designer effective is a genuine interest to get to know people. It’s through authentic relationships that we’re able to carry out a design vision alongside our product partners. Perhaps that’s why we all got into design in the first place.
MT/ But then I wonder what it’s like for designers in consultancies or agencies where opportunities to get to know product partners is less available…
JK/ On the subject of the designer being a diplomat, charmer, salesperson, etc: A design mentor once told me that I should use my “design superpowers” to influence the product strategy. We’re in the unique position in our ability to show, not tell. Instead of arguing the pros and cons of possible different directions, we can design our proposed solution to a problem, which can be a very powerful tool in aligning the different stakeholders and partners towards an unified vision.
Michael K. Owens MO/ As someone who started his career as a hybrid designer/developer at agencies, it was difficult to find connection with the work that I was making unless it was something I had an external connection to. You aren’t typically afforded the time to get to know the clients or their wishes and often don’t even get to learn how to effectively communicate with your teammates. Interestingly, though, as I matured as a designer and honed my craft more, I found slipping into new contexts became easier. Consulting in the latter half of my career didn’t suffer from the same “getting to know you” ramp time because I had learned how to empathize a lot more with products but more so people. I’ve always held a belief that one of the greatest advantages of hiring a seasoned designer is their ability to communicate. At every company, the hardest thing for teams of all kinds is communication and building the cooperative, collaborative relationships that result in good compromises, better execution, and a successful product team.
MT/ Your point on honing your emphathization (folks, I think we just made up a word!) skills is something we haven’t talked about yet. It reminds me of something Bruce Lee once said:
“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.” — via Bruce Lee
MT/ Also reminds me of the terminology of “Invisible Design.” Rather than thinking of the outcome as something that’s invisible to people’s lives, invisibility could refer to how a designer operates within any given team to achieve results.
JK/ The Crystal Goblet principle applied to Product Design.
John Maeda JM/ I’ve always wondered whether the process of posting and finalizing “the values” is more important than the actual final result — and that those who come after the fact, tend to only see those kinds of things as words on a page or a sign posted in the company cafeteria …
MT/ Though I doubt the effectiveness of their culture as applied to other organizations, it is interesting to note that it took them 12 years to actually “publish” their handbook: 1996 to 2012. We often think there are shortcuts to establishing a unique culture that works, but culture is something that is crafted over time.
THANK YOU TO JOANA AND MOSES!
FYI John Maeda and Jackie Xu are pleased to let you know that the#DesignInTech Report (launched in March 2015 at SXSW) is now available in English, Spanish, Chinese, and Japanese.
ADDITIONAL READINGS VIA @JOANAKOILLER
- On the cross-functional pod model: http://blog.idonethis.com/cells-pods-squads-structure/
- On collaborating with cross functional teams: https://medium.com/the-year-of-the-looking-glass/how-to-work-with-pms-3e852d5eccf5
- On defining the role of a product designer to cross-functional partners: https://medium.com/@ericeriksson/what-is-product-design-9709572cb3ff
- On intentional environmental changes to help ignite collaboration and creativity: http://dschool.stanford.edu/makespace/
