Collaborative design process
A process for the design team to break the 'silos', which encourages collaboration and builds trust.
In my 15+ years of design career, I have worked in a variety of companies ranging from small to large ones. Companies where I was the first designer to the companies where we had almost 50 designers. Companies where the design was tightly coupled with development to the companies where the design was independent.
I see most of the companies knowingly or unknowingly are organizing themselves in such a way which creates a silo thinking. Multiple departments, teams, job titles are the representations of this silo thinking. In these silos, most people think in his/her little box. In some companies, you’ll see there is hardly any communication between departments and teams. The question I always ask is, does the company knows that there are silos in their organisation?
If I take a more in-depth a look, I have seen not only silos in multiple departments or teams, but there are silos with in the teams. Unfortunately, in some companies, the design is one of them where few designers prefer working in silos, and there is hardly any sharing. There could be multiple reasons for this — organizational structure, team structures to the personality type.
For any company, the most dangerous situation is when people avoid sharing information."
A few years back, I joined a company, which was a global IT solutions and services company, and it was ranked number 6 in India. The company hired me to set up design as practice in that organization. And also the plan was to offer design as an offering in the market. The company had multiple business units, department and various teams within departments. I observed that people hardly know which team is sitting next to them and on what they are working.
When I joined, I met two designers and both designers used to sit on some other levels. They hardly knew each other, no clue who is working on what. The company wanted me to build and lead the design team, but I said before we start hiring more designers, I need a place where everyone can sit together. The response was that we could find a place, but designers need 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 team 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 will be substantial, what’s the right 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 sometime designers feel they are“stranded on an island”. They feel isolated. In EPD it’s critical to include UX roles in advanced planes of the project. Most of the product companies follow this.
Hybrid ✓
It’s a hybrid of centralised and Embedded models. In this design, 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 choose Hybrid over the other two because my company wasn’t just into products, Services was a significant revenue generator for them and it was important that the team works accordingly.
I decided to follow hybrid team structure because:
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 for an individual UX professional’s success and, thus, for 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 be likely to 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, it becomes hard to put a group of designers on a project, unless you follow the studio model where you sell studio hours. In most of the cases, only 1–3 designers end up working on a project. That’s what I have seen in most of the services and a few product companies. It also boils down to how mature much importance a company gives to design.
Considering the structure and personality types, for me, the biggest challenge was how do I make design delivery a team sport. How do I make sure that whatever design solution we provide the entire team believes in that? 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 we’re working in silos with their team. Most of the projects had only one designer. Other designers had hardly any clue on what other designers are working, what solution they are designing and their struggles. Whenever we decided to meet, show and discuss our work, people end up missing those meetings, they made excuses and sometimes there was a push back. Few were very active in gathering and sharing, but few were a bit 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, you trust them, you look for your friends for help, you learn and share, you share emotions, you have an open and growth mindset, and sometimes you get drunk together. You need to have a level of trust in your team members 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 from the people in the team. I decided to put up a communication channel in place, build a bond in the group first, and then come up with 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, and 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, be open, talk, share, turn 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 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
Inception/discovery workshop is the time when we explore the problem and start thinking about the solution at a high-level. Post discovery is the time when we start thinking about what kind of solution we want to provide and what will be 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 we had as a team 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. Group used to cover and examine every bit of the feature in details and sometimes come up with design variations which used to help 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 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 who are on bench/beach or have some bandwidth became very proactive in offering help. Sometimes they were excited about the problem which 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. Group proactively offer to help her to come up with the designs.
Timely delivery
A few times designer’s delayed deliverables because they wanted to make sure that their design group goes through first. It sometimes happens where 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 the 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 became a process now in those teams, and they are still following. It was not meant to be restrictive—simply to provide a structure where the structure was needed. More often than not, process-setting was itself a collaborative process, and we implemented many systems that the team ended up appreciating. Even enjoying.