Collaborative Design Process
A process for the design team to break the 'silos', which encourages collaboration and builds trust.
It's a tried and tested process for the design teams to break the 'silos'. This process encourages collaboration and builds trust.
In my 20+ years of design career, I have worked in various small and large companies. Companies where I was the first designer to the companies that we had 100+ designers. Companies where the design was tightly coupled with development to the companies where the design was independent.
I see most companies knowingly or unknowingly organising themselves to create silo thinking. Multiple departments, teams, and job titles represent this silo thinking. In these silos, most people think in their little boxes. In some companies, you’ll see hardly any communication between departments and teams. So the question I always ask is, does the company knows that there are silos in their organisation?
If I look more in-depth, I have seen silos in multiple departments or teams, but there are silos within the teams. Unfortunately, in some companies, design is one where few designers prefer working in silos, and there is hardly any sharing. There could be multiple reasons for this — organizational structure, team structures, and personality type.
For any company, the most dangerous situation is when people avoid sharing information."
In 2012 I joined a company, which was a global IT solutions and services company; it was ranked number 6 in India. The company hired me to set up design as a practice in that organization. And also, the plan was to offer design as an offering in the market. The company had multiple business units, departments and various teams within departments. I observed that people hardly know which team sits next to them and what they are working on.
When I joined, I met two designers who used to sit on other levels. They hardly knew each other, without knowing who was working on what. The company wanted me to build and lead the design team, but I said before hiring more designers, I needed a place where everyone could sit together. The response was that we could find a place, but designers needed to sit with their teams. Fair enough, but still, I said I want a place for the design team to sit together so that we all can bond.
Choosing the right team structure is a key to success
When I visited those two designers' teams and observed how they work and how cross-functional communication happens, I realised that the current team structure is ‘Embedded’. It has its advantages and disadvantages. It was looking at the future. When team size is substantial, what’s the proper structure for my team because striating right is much better than fixing problems in between?
There are three types of team structures, and every arrangement has its pros and cons.
Centralised
It’s an agency model which works in a shared studio. This option was out because there is hardly any collaboration with a cross-functional team.
Embedded
Another name for this structure is EPD (Engineering. Product, and Design). Cross-functional collaboration is the foundation of this structure, but the problem is designers belong to a team, and after some time, designers feel they are“stranded on an island”. They feel isolated. In EPD it’s critical to include UX roles in the advanced planes of the project. Most of product companies follow this.
Hybrid ✓
It’s a hybrid of centralised and Embedded models. In this design, the manager positions designers in a project based on multiple factors and designers report to a design manager. The designer stays in a project as long as the team needs them, and once the design is done, they come back to the design team.
I decided to follow a hybrid team structure because:
The company wasn’t just into products, Services were a significant revenue generator for them, and the team needed to work accordingly.
Twice the focus on UX: In a hybrid model, there is UX oversight from both a design manager and a product-team lead; consequently, two managers may take charge of an individual UX professional’s success and, thus, of UX in general.
The high probability for genuine connection: Because UX professionals partner long-term with a particular product team, other product-team members will likely view UX staff as a genuine part of their team, involving them in critical conversations, meetings, and activities.
Improved versatility: A hybrid team is less stringent than a strictly centralized or decentralized one and can, therefore, be easily adapted to meet evolving organizational pressures or short-term, immediate needs.
Design is a team sport.”
Which few companies fail to understand, and somewhere designers also fail to communicate and show the value. Because of structures and commercials, putting a group of designers on a project becomes hard unless you follow the studio model where you sell studio hours. In most cases, only 1–3 designers work on a project. I have seen that in most of the services and a few product companies. It also boils down to how mature and much more important a company is to design.
Considering the structure and personality types, the biggest challenge was how to make design delivery a team sport. How do I ensure that the entire team believes in whatever design solution we provide? How do I make sure design becomes a team sport?
After some time, we had an excellent team of designers, but the challenge was connection and trust. Designers who were on the project were working in silos with their teams. Most of the projects had only one designer. Other designers had hardly any clue about what other designers were working on, their design solution, and their struggles. Whenever we decided to meet, show and discuss our work, people ended up missing those meetings. They made excuses, and sometimes, there was a pushback. Few were active in gathering and sharing, but few were hesitant.
Identifying team’s dysfunctions
Whenever I am building a team or driving a design team, I always try to align my team with “Lencioni’s 5 Dysfunctions of a Team” and see where we, as a design fit.
I started with these five questions about my team:
Do my team members openly and readily disclose their opinions?
Are my team meetings compelling and productive?
Does my team come to decisions quickly and avoid getting bogged down by consensus?
Do my team members confront one another about their shortcomings?
Do my team members sacrifice their interests for the good of the team?
Since the team was relatively new, the answers for all five questions were mixed and it was important for me that all should be yes.
There are different personality types in every team — it’s a mix of extroverts and introverts.
To me, it doesn’t matter as long as you respect other team members, trust them, look to your friends for help, learn and share, share emotions, have an open and growth mindset, and sometimes get drunk together. You need to have a level of trust in your team members so that if something goes wrong, you know your friends are standing right behind you to back you up.
It required a necessary mindset to change the people in the team. I decided to put a communication channel in place, build a bond in the group first, and then develop a process. We decided to continue our meetings and post-meeting we started sharing what we did, discussed, learned so that people who couldn’t make it knows what did they missed (self-realization). We all started going out for drinks more often, which we named DD (drink & discuss) sessions. The idea was to drink, consider what’s happening, discuss our feelings. I started exploring during those meets the reasons why people miss, what’s stopping them, their pains. It turned out that few designers weren’t sure how other designers would react to their solution/designs. What perception will they build? That day I realized that “sometimes its easy to sell designs to non-designers compare to designers.” DD sessions did their magic, and the team started to show what the team should be.
After a few DD sessions, we decided to come up with a few sets of principles and rules within the team. e.g. design reviews, honesty, being open, talking, sharing, turning for everyone, transparency, etc. If you don’t have any work to talk/show that’s okay, talk about something else.
Design reviews were a significant step, but those happen once you reach some sound stage. Challenge was as a team how do we make sure that we’ll all take part in the solution? Especially when a designer is about to start thinking about the solution/design direction. How can every designer participate and add value to the solution/s? Putting everyone in discovery workshops wasn’t possible because of team size, cost, etc. It needed to be an offline process.
I started to think about how to solve this. I sketched the journey of a designer in a typical project. What stages do they go through in a project? In parallel, I draw a journey with touchpoints with the design team. At what stage, they can come and add value/inputs. I needed to keep in mind how will it affect project timelines because I was about to ask for their time. It came out as a process, and I named it the “Collaborative design process”. When I presented to the group, they weren’t sure initially because of time, workload, what if things change, etc. something which we all go through before any change. After 2 DD discussions, we decided let’s give it a shot and see how it goes. We’ll improvise on the fly if needed. All we needed was a commitment to participate, which everyone did.
Collaborative design process
The inception/discovery workshop is when we explore the problem and start thinking about the solution at a high level. Post-discovery is when we start thinking about what kind of solution we want to provide and the design direction. In this process, that’s where the group comes and brainstorms together. It works very well if everyone commits and manages time.
Few observations which team had after following this process:
Less stress
Designers used to feel a little less worried about the solution/project because they had more brains to discuss. The group used to cover and examine every bit of the feature in detail and sometimes come up with design variations which used to help the project designer in the long run.
Transparency
Everyone knows what’s happening in the project, foresee issues, and what’s next.
Talk business
Some designers talk and understand the market, and few lack this skill. This process helped a lot because discussions used to be about finding the balance between design and business. Over time, we saw that designers who lacked business language started to pick up this skill.
Helping hand
People on the bench/beach or with some bandwidth became very proactive in offering help. Sometimes they were excited about the problem that we were trying to solve.
We had a situation where a designer was asked to work on a mobile solution (app), and this was her first time. The group proactively offer to educate her to come up with the designs.
Timely delivery
A few times designers delayed deliverables because they wanted to make sure that their design group went through first. It sometimes happens when you might be asked to design/deliver something quickly. In those cases, we used our communication channels to share designs and, if needed call for a meet depending on the level of complexity. We had situations where the team helped the designer to meet the timeline and deliver.
So far, I have tried this in two companies where I was heading the design team, and the results were very positive. It has become a process in those teams, and they are still following it. It was not meant to be restrictive—to provide a structure where the structure was needed. More often than not, process-setting was collaborative, and we implemented many systems that the team appreciated—even enjoyed.