Product development and design: Tips to improve collaboration between designers and developers

Product development and design

Today’s technology means it’s never been easier to foster a collaborative culture between multi-discipline teams. Yet, here’s the rub: while 75% of employers say teamwork and collaboration are important, 39% of employees believe people don’t collaborate enough in their organization. 

In today’s article, we’re going to talk about:

  • What impacts team collaboration during design and development of products 
  • The tips to make work between designers and developers more effective during software product design
  • Share two brands that you can draw inspiration from.

Let’s dive right in. 

Product development and design – key factors that influence team collaboration

There are two major areas that impact the way teams work with each other. These are: the numbers and variety of roles and the design team setup. Let’s take a look at them below.

Numbers and types of design team roles

Design teams are an incredibly diverse group. In some organizations, it may only be one person, or it could be a large group, with each person bringing their own skills to a collaborative project.

In the pursuit of greater collaboration, it’s more practical to think of members like medical professionals (it’s not that far a reach) or a marketing team (perhaps, an easier comparison) with writers, social media handlers, data analysts, SEO execs. 

Similarly, each person on the design team has a unique role and specialization, from usability research and UX design, all the way through to user interface, branding, and interaction design. Every role connects with internal and external projects differently. 

Team setup

Design team structures, which influence how designers and developers work together, come in four flavors. 

1. Centralized

A centralized structure is characterized by a single decision-maker and a central base. It’s the most traditional and recognizable method of team management. Separate teams of designers work on separate projects under design managers who report to the UX VP or director. Centralized teams offer simpler collaboration and a shared vision for projects, however, design processes are slower and teams are siloed. 

2. Embedded

Embedded teams, sometimes known as decentralized or distributed teams, are cross-functional, with members from different departments working together on a particular project. For example, a new website landing page might bring together a designer, a back-end developer, a copywriter, all overseen by a project manager. Embedded teams foster greater company-wide trust and collaboration, focusing on each team member’s specific expertise, although it’s a structure that’s not always efficient. 

3. Flexible

Flexible teams take a pinch of centralized and a dab of embedded to form a hybrid hierarchy. Designers act as part of a multi-discipline cross-functional team, working day-to-day under a team leader, while being managed by a design manager. A flexible team is focused on the design process and is generally better suited to adapt to changing objectives. But the structure often leads to confusion over the chain of command, making it unsuitable for larger organizations.

4. Contractual

Contractual teams are external designers hired as freelancers. This method is often used by businesses that don’t have the budget for a full-time in-house team, or an existing team that needs additional support on a specific project. 

5 tips to improve collaboration between design & development teams

Let’s now take a look at the tips that will help you improve the design and development of products and boost cooperation between your teams. 

1. Assess what your current team setup is and what it needs

Hierarchies and processes will vary across organizations, and it’s important to explore the type that best works for your teams. This will depend on a number of factors, including:

  • Company size
  • Size of design team
  • Design project type
  • Design project demands.

Alongside key stakeholders, examine your current setup. Consider where it’s working and where you can make improvements. Where possible obtain feedback from those ‘in the thick of it’, who will likely have valuable insights into the process. 

This is an important – and often overlooked – aspect of any organizational transformation: employees want to feel valued and heard. Gaining buy-in from those affected by any change is critical if it is to be successfully embraced across teams. 

For example, you may currently deploy an embedded design team, but it’s apparent that multiple members are repeating the same tasks as each other. That’s a costly and inefficient endeavor (and it’s not going to have a positive impact on employee morale, either). At that stage, it may be time to trial a more flexible approach, which champions speedy, design-focused collaboration.

Always have a clear, attainable objective before making any changes to team structure. 

2. Designers should know to whom they report to

Every team in every business needs a clear chain of command. It establishes expectations, increases efficiencies, and helps team members seeking support.

It’s one of the biggest problems for designers in a flexible team setup. Designers find themselves wondering whether to discuss matters with the project manager or their own design team lead. It’s the sort of problem that’s all-too-easily papered over with quick fixes and promises of ‘next time…’, without ever addressing the real problem. 

At heart, it’s a communication breakdown. One wide-ranging study ‘cited an average loss per company of $62.4 million per year because of inadequate communication to and between employees.’ And poor communication kills collaboration. Teams face an endless carousel of projects with no direction, no purpose, no ownership, and no shared vision in an environment where no one dares innovate. 

Shifting to a centralized or embedded team type may be more desirable here. Both offer recognizable command hierarchies, improving communication either within a single team (centralized) or driving collaboration across departments (embedded). 

3. Make sure designers don’t feel disregarded

Developers almost always outnumber designers. It doesn’t matter the size of the business or the type of work. If there’s only one designer on a team with multiple devs, there’s always the risk that a designer’s opinions are disregarded. In emotional terms, it’s an empathy deficit. 

Developers and designers approach projects from very different angles. They don’t see what the other is seeing, because they’re not looking for it in the first place, so they can’t understand it.

This should be addressed swiftly to boost morale and team cohesion. Encourage mutual respect by highlighting the roles, responsibilities, and authority of every team member. Also, make sure to clearly define their areas of expertise. It’ll make it easier for designers to have their say and advocate from a design expert perspective. 

4. Give designers access to the right tools

Technology has made collaboration quicker, faster, and easier than ever before – no matter where in the world your team is. But choosing the wrong technology or keeping outdated tools and obsolete systems can be a costly decision. Efficiency. Competitiveness. Innovation. All of these can be increased by making sure designers have access to not just the best tools but the right tools. 

UXPin Merge transforms how designers and developers work together. 

And it works by bringing teams into the same ecosphere, instead of reinventing the wheel (or overhauling every system and process in the organization, at least).

Featuring powerful Git and Storybook integrations, designers can either use the same React components or any components existing in Storybook. It lets designers use the same technology as developers to achieve full consistency with the final product. At the same time, designers can focus on what’s most important to them: be it a clean UI, perfect UX, or immersive interactions.

As an end-to-end collaboration tool, Merge facilitates smooth communication. Because the same system is used by your designers and devs, both will be working seamlessly together throughout the design process.

5. A framework for developer handoffs

The handoff process is one of the most important stages of the product development and design cycle. 

Among others, a good handoff will: 

  • Stop avoidable last-minute changes
  • Communicate clear next steps
  • Increase efficiencies and prevent delays
  • Plug information gaps
  • Gain internal buy-in from key stakeholders early on
  • Highlight what each team needs from the other.

Clarity and accessibility should take precedence to ensure a smooth transition as teams work simultaneously on development and design. 

Software product development – examples of effective cross-team collaboration

Here are a couple of brands that you can draw inspiration from when it comes to software product design. 

Segment

Segment, a leading customer data platform, focuses its software product development process on two stages: discovery and delivery

The discovery phase, driven by product managers and designers, explores whether an idea makes sense. It questions a product’s usability and value to the customer, whether it’s even feasible, and at what cost. 

During this stage, user feedback, data analytics, competitive analysis, and experiments are all deployed. For Segment, discovery ‘drives a shared understanding of the problems customers are facing — without any indication (yet) of how exactly they might be solved.’ 

The delivery phase occurs after a successful ‘discovery’ has been made and handed over to a mixed team of designers and engineers. At this stage, the focus is on how exactly the product works. This may involve creating and documenting interactive prototypes that meet the software design descriptions, showing devs how a product should look, feel, and behave. The team will also review and agree on the final designs. 

Airbnb

Online vacation home company Airbnb was among the first to start thinking of code as a software product design tool. 

Recognizing a collaboration gap at the company, Alex Schleifer, former CDO, said, ‘we’re investing in code as a design tool. Moving closer to working with assets that don’t only include layout and design, but also logic and data. This helps bridge the gap between engineers and designers, thus reducing the need for design specs or redlines and the steps between vision and reality.’ 

The Air/shots tool is one example. Starting life as an off-hand comment – according to design technologist Luke Carter, ‘Schleifer mentioned in passing that it would be cool if we had some sort of tool where designers could see all of the different views of our app. This was exactly the type of project I felt could affect several departments within Airbnb.’ 

Carter’s hunch was right. 

Not only was the product development and design initiative useful to software developers, but the entire company. Engineers found they could use Air/shots to run experimental flows before launch; the tool made it easier for the localization department to improve translations. 

Summary

Organizations today understand the power of collaboration to boost productivity and efficiency and build a workplace culture to be proud of. However, attaining that goal can feel somehow just out of reach. It’s all too expensive and too complicated. 

It’s true, successful projects like Airbnb’s Air/shot take time. And few organizations have the resources to spare creating design teams to research innovative ideas and build collaborative tools – but everyone can use powerful, accessible tools like UXPin Merge

Merge makes it easy to nurture true collaboration between teams, simplifying workflows and communication without curbing creativity. Take it for a test drive, and see for yourself! 

Designing for a Dev Environment in 9 Steps | UXPin

design for dev guide

Agile is the most common methodology for software product development today. And, it makes sense.

In the waterfall days, designers and developers followed requirements that were hundreds of pages long. Products were fully designed, and then fully developed. When the product was eventually released, there was no time to go back and fix what didn’t work well.

Personally, I thought the waterfall days were really hard. We rarely held meetings in the same room with the developers, so it forced me to interrupt them at their desks – and that, was a daunting task. I get it; they’re busy and they didn’t want to be bothered by a web designer, and we really had no common ground for communication.

Design was evolving so fast in this space, it was more about brand and not yet about the users’ experience. Still, it was clear that I had to work with developers directly, and I had to be creative in finding ways for them to want to interact with me.

Here’s the kicker: In the end, it was chocolate that was the common language for us. If I approached anyone with chocolate, that person would take the time to work with me and even teach me a little JavaScript.

I was first introduced to Agile in 2009. My first stand up had 40 people in it – and stand up was never ever 15 minutes. However – the process got the right people talking together every day. Over time, we learned to make our teams smaller and our sprints shorter.

Agile challenges us to create small slices of a product that is usable. Our sprints are typically two or three weeks long. During the sprints, the team can focus on problems and fix them quickly – and often, this includes design and UX issues. Missing icons, UI elements and UX that doesn’t work as designed are issues that pop up in-sprint, and need immediate attention. Each sprint, we share these pieces of working code with our users to get their feedback. This allows us time to pivot and redesign as necessary, improving our products in an iterative way.

Large features, however, can take the design team weeks and sometimes months to research, design, review, test, adjust the designs, retest and review with product and development before sprint planning.

Where does that leave designers?

How do we think about a feature far in advance and leave enough time to complete the design process? How do we pivot and jump into a sprint and solve problems mid-sprint that might need user testing?

Let’s start by taking a look at the full process of designing a user experience.

l. Discovery

  • Have a high-level overview meeting with the Product Manager to determine what the new feature and the business need are. Identify the stakeholders – including the Development Lead and QA resources.
  • Host a brainstorming session: A one-hour meeting with UX to brainstorm and get ideas from all team members. This will also ensure all UX team members have a clear understanding of the feature.
  • Define how many screens are affected and the number of mocks to be delivered.
  • Define personas, use cases and scenarios.
  • Decide the one UX person to “own” the project from beginning to end. The full UX teams should sketch and help find a solution.

2. Sketching

  • With markers and paper, sketch up high-level solutions.
  • Review sketches with the Product Manager and Development Lead.

3. User interviews

  • Start gathering feedback from the users. They can be actual users or internal team members. Face-to-face interviews are recommended.

4. Low fidelity mockups

  • Review feedback and create low fidelity mockups.
  • Create a simple prototype using the low fidelity mockups and test with internal stakeholders. This will help solve any usability issues prior to spending time creating high fidelity mockups.

5. User testing

  • Using the new prototype, create 4-5 tasks for the user to complete within the prototype. User testing should include as many users as possible.
  • Make design changes based on user feedback. Changes might require more user testing and more design changes.

6. High fidelity mockups

  • Create high fidelity mocks to reflect the final design.
  • All elements should adhere to the UI style kit and brand standards.

7. Full team review

  • Review the solution with stakeholders to make sure everyone agrees on what will be implemented.

8. Finalization

  • Once the design has passed the team review, update user stories with mocks, the prototype link and design specifications.

9. UX sign off

  • UX should review product changes in an end-to-end testing environment and sign off prior to release.

Not all of these steps are necessary for each UX project or task. Assign a “UX Project Size” and the corresponding steps to create a guideline for your team. This way, your team members adhere to the same process and the steps provide clear actions.

project size estimation

Other resources that help the workflow:

Agile board for designers – Create an agile board for your team with columns for:

  • Backlog – UX backlog of items you want to work on.
  • To Do – Items lined up for designers to take with the user story/design task ID and the designer’s initials.
  • Doing – User stories/design tasks that designers are actively working on now.
  • Done – User stories/design tasks that designers are completed this week.
  • Dev Backlog – User stories/design tasks that designers have completed but are not in development, so you can keep track of the UX queue of items developers can grab in their grooming meetings.

Weekly critique – At the end of each week, hold internal critique session for your design team. Close laptops, and create a safe environment to give and receive feedback.

Finally, take time to get to know your developers and get their feedback early and often. This helps to make a successful working relationship, and a well-designed product. If you need an ice-breaker, bring some chocolate. As important as a consistent design workflow is, the experience is what really makes design and agile a great combination.

 

This article was originally published on Medium.

Join the world's best designers who use UXPin.

Sign up for a free trial.

A Developer’s Tale: of Design Education and Interactive SEALs

No one said enterprise-level design was easy. But few realize how much of a difference good collaboration and communication can make — especially between designers and developers. While sometimes they seem to live in different worlds, their common goals put them firmly on the same team.

We talked with web developer Chad Wooten of GDC Marketing and Ideation about working with designers in an enterprise environment. With more than 20 years of experience in web development, systems administration, and graphic design, Chad approaches projects with careful attention to both technical development and creative execution.

Because of his hybrid background in front-end and back-end development, he has wide-ranging and valuable insight in regards to UI/UX testing, responsive design, and digital best practices.

How is developing for enterprise customers different than smaller companies?

There are more layers for approval so you have to be very conscientious about timelines. Testing takes longer in some circumstances because of an overzealous IT guy.

What information is often missed at the beginning of a project with a major client? What do you wish you’d known later in the development cycle?

In my experience, the little things get overlooked. The client loves the design on paper and they don’t think about hover states or the interactivity. It is also hard to communicate the subtle differences in UX/UI on a mobile device for responsive sites. Like the lack of hover states, etc …

What miscommunications have you encountered when working with a design team?

Because I work in a traditional advertising agency, most of the designers I work with are used to print design or broadcast. This leads to missing interactive function in the design. Animations are hard to convey on a print out. Sometimes little changes in the visual design are huge changes in the code and sometimes the opposite is true. Communicating the differences can be a challenge and may lead to designer shell shock if you are an aggressive developer.

I have a background in IT so I am used to many questions that I consider to be trivial but the user is truely clueless. You can either get annoyed by this or you can embrace their curiosity and use it as a teaching opportunity. The same holds true with development. Questions that seem simple to the developer may be completely Greek to a designer.

“You can either get annoyed by this or you can embrace their curiosity and use it as a teaching opportunity.”

One time I developed a site that needed a “simple” webform. They just wanted to collect a user’s information with four basic questions: name, phone, email and zip code. By their answers, specifically the zipcode, they would receive information that was geographically based.

The simple change they requested was stated, “Can we have them fill in their zip code first and, based on this information, have a form that routes to a specific person?” Uh, yes, that can be done, but it is more complex than a “simple” webform.

How early do you think developers should get involved in the design process?

Developers should be involved from the brainstorming on and there should be regular check-ins to ensure the designers or the client aren’t encouraging scope creep.

What advice would you give developers about making design decisions? How about clients or managers?

Keep the budget in mind and know how long it will take to achieve the client’s goals. Don’t be afraid to give your opinion on the design but remember the designer and the client are in charge if the design. Like it or not, we are in a service industry and we are here to develop, not to design.

What should developers know about design?

This is a tough question. Developers should have an open mind about design. I think they should have a basic concept of good design. They should be able to spot good composition, know about the “rule of threes” and understand the concept of negative space.

On the other hand, designers should know basic programming concepts. On the favorite team I was ever on, we liked to think of ourselves as interactive SEALs. We all had our specialty, but we knew enough about each other’s jobs that we could do it if that person was missing in action. That is an effective team model.

What do you find rewarding about working in an enterprise environment?

The larger and more recognizable the brand, the better your resume will look. The code isn’t always more challenging but there is almost always more of it, haha. I thrive on working under pressure and large clients love last-minute changes.

And, above all, when your friends and family say, “I just went on so-and-so’s website and it was so easy to use” and you say, “I developed that @&#! site!” Well … yeah, that’s awesome.

If you were in charge of an enterprise-level project, what would you like to change?

I would have an initial meeting with the client that involved everyone on the team. I would make sure there was complete agreement on the intent and scope of the project before it started on all sides. I would make sure there were regular team check-ins to ensure the project was on track and within scope.

I would also make sure that once the mobile and desktop design was complete, the developer and designer hashed out all of the interactive elements before client approval. Finally, I would make sure to hold regular developer/designer check-ins during the programming to ensure creative integrity.

How do you work with team members in different disciplines? Have your say in our community.