A Connected Workflow
Connecting with different teams and skills to enhance the project
To develop relevant products and enable valuable experiences that will get the company closer to its goals, product designers should not only connect with the users but also with the different teams in the company. If you spending almost all of your time working and taking only with designers colleagues, chances are you are losing opportunities to think and work holistically. Trust me on this one, I experienced both sides of this spectrum.
The Specialist Bias
During a long period of my career, I was working with big design teams. The design methodology was well defined and the timeframe of the project was quite long (comparing to companies with agile methodology ). We were able to work through each step of the design project, from concept research to several prototypes and user testing, a luxury for startups! It was mostly done inside doors, like scientists working together in a huge secret lab, in this case, the design building. Sometimes we would open this door for specific workshops with different stakeholders, but that’s it. We, as specialists, knew what we were doing, therefore we would be able to find the best design solution for any given project. Right?
As most things, not that simple. I came to realize later on my career as I worked with small startups or more agile oriented companies. There is no such thing as “the design of the project”, regardless of the project, if it’s a product or service. Why? Because everything, in the end, is part of the product, a systematic combination of elements or attributes. You can’t really separate like a heterogeneous mix the parts of the product, say like “this is the design and this is the engineering of the product”, they’re all together, entwined. Just ask the user. It’s the product experience as a whole, that’s it.
Most of the goals of the project I worked on was basically a product, feature or improvement that fulfiled the consumer and company needs. That seems quite simplistic but bear with me. Notice that I didn’t mention design solution in any part of this statement, I mentioned need. The mindset of separating into delivering boxes such as “design of the project” “engineering of the project” where all skilled specialist will care for their part only will also add their bias into the mix. Without a rich sharing of information and collaborative workflow to fulfil the requirement of the project. By bias, I’m referring to assuming something is true or right based on the narrow spectrum of experiences (or lack of them) one have. In the case of the specialist, this bias could be even more enhanced, as one could state that there should be no one else more skilled to propose and decide something than the specialist of the topic. Even though in many cases probably true, in other grey areas where one topic mixes with another (based on my experience they are very, very common), it’s not that simple.
Levels of Collaboration
So, what are the teams and skills we need to connect in projects? How much broad should be the connection? My first answer would be “as much as possible” but giving a second thought, probably a better answer would be “it depends”. On an agile environment (as I observed on my current and lastest career experiences) the squad already has different skillsets and knowledge, therefore in some level, this sharing and collaboration between different understandings of the requirement and the solution would happen naturally. No longer the designers working on a secret lab at closed doors. Also with a common, clear objective, everyone in the squad is on the same page when it comes to understanding the problem and the project needs.
I thought to myself when I was working in this environment, “that’s just great, here I can learn and share much more from this diversity than working only with the design team”! I was having a ball working on the other side of the spectrum. But as COVID-19 hit us and I become aware of a blind spot that became even more latent on remote work setup. Well, the squads are teams that work in a collaborative setup, therefore, connects parts of the project very well together, but turns out that in complex and broader projects, it requires the members to collaborate beyond the squads, sometimes, way beyond. Collaboration should be based on the connections opportunities we see and foresee in a project, for this, we should be able to be open-minded. To talk and collaborate with others. We need to be humble, to understand that we don’t know everything that is to know, don’t matter how experienced we are on a specific skill. As mentioned before, the “grey areas” of the project requires more than one skillset to achieve the best results. The blind spot happens in the squad workflow sometimes and we lose the opportunity to interact with different teams, to share more.
The Grey Areas
Projects are complex. At least in product companies, digital or not. It’s a hard and intricate puzzle. It requires creativity and cognitive skills to deliver its requirements, not only our experience gained experience. Dare to say, those requirements are in so many cases, evolving, therefore, not clear as water nor written on stone. Mostly, the objective is clear, but how to get there, not at all. To reach the end of the project, intricate decision-making for things that relates to several topics and attributes are needed. The combination of shades of knowledge and skills, the grey areas. For those decisions, is better to have important pieces of information to better understand the impact of decisions, for that, the more connection made, the better. Connections help build a more robust, complete and holistic picture that is required to make high-quality decisions on any given project.
A Connected Workflow
Connection is entwined with collaboration. In a classic waterfall model workflow, the project is divided into distinct phases, each, tackled by one specialist (or a group of specialists). Once is done and passed to the next phase and specialist. One example is the workflow mentioned at the beginning of the article, I, the designer would do the “design phase” of the project and pass it on to the engineer or developer on the “implementation phase”. The issue here is that passing of one phase to another doesn’t create the best connection possible between the contents of the project, leading to poor decision making and increasing the specialist bias. A connected workflow happens when the specialist boundaries are not defined, in different phases of the project different teams and skillsets come together to help create a wider picture of the project to make better decisions, regardless of the phase.
Easier say than done. Like mentioned before the agile method already incorporate this mindset as it understands that every product team member is accountable for the results of the product release. Thing is that, for some more complex and broader projects, many parts demands other squads or other teams. And this is when sometimes it gets complicated. The question should be, are we collaborating and making connections to ensure the proper decisions in all phases of the project? This calls for awareness and proactivity. Awareness to foresee a latent need for a connection in the project and proactivity to “step outside the squad”, to collaborate with other teams to ensure this connection is made, instead of waiting for the information to fall over our laps (normally, it doesn’t happen).
As a product designer, it was definitely efficient for the projects I was working on to collaborate with different teams such as content and branding. It was a huge learning and unexpectedly exciting. The sharing, creating and getting to know better more people in the company. On the projects, more connections were made and the quality of the deliver improved. As for me, I learned how to mitigate specialist bias, improve my explanation and sharing skills. Also, a motivation boost, driven by the excitement of two or more people with different skillets joined together to solve a challenging task.
