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! 

Why You Should Switch to Code-Based Design

Why You Should Switch to Code Based Design

Since the very beginning of digital product design, the default way of designing user interfaces has been image-based.

Designers have been drawing different states of the mobile app or web designs using graphic design tools – GIMP, Fireworks, Sketch, or now Figma, Invision, Adobe XD (which you can in Adobe Creative Cloud) – and then the development teams have been writing code that would replicate what has been drawn.

Over the years this method has proved to have considerable limitations. What limitations are those and is there an alternative? Read on to find out.

Drive design process improvements, take care of operations, and boost collaboration with engineers with UXPin Merge. Request access to see if this design technology is for you. Discover UXPin Merge.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

The Problems with Image-Based Design

In the image-based design approach, designers produce a set of static artboards representing different states of the interface and forward them to software developers to code interactive interfaces on their basis. This brings about a lot of troubles for not only the UI design but also the whole product development process – let’s have a closer look at them.

  • Lack of interoperability: There is virtually no connection between designers’ and developers’ universes. Designers work outside of the constraints set up in code and therefore, unknowingly, create things that are very difficult and expensive to code. 
  • Lack of accuracy: As the image-based tools use completely different methods for rendering the result of the designers’ work, texts, gradients, and colors that have been carefully chosen look different in code when an engineer applies the same specs. Some details are missing and some ideas that looked great on a static image are simply impossible to recreate on an actual working product. The handoff then turns into a nightmare. 
  • Static designs: Image-based design only allows for building static artboards, so even simple behaviors (e.g. expanding a dropdown) quickly become unmanageable. Interactive components can’t be reused and there’s no way of setting states of elements, defining variables for content, or using conditional logic. There are prototyping tools out there that fake the interactions but none actually use the ultimate language that creates the clickable elements in real life – the code. 
  • Weak design-engineering collaboration: Even if you use a style guide or a design system, image-based design tools are completely separate from the engineering processes. They’re rather abstract and – unlike technologies used by developers – can’t be experienced by users as the final product. This lack of interactions or having very limited ones, and the inability to import components from code keeps engineers and designers disconnected and frustrated with one another. As a result, not only the handoff drift appears, but also the final user experience suffers.

The benefits of code-based design 

This alternative approach to product design allows designers to render their design intent directly in code… without even knowing how to code! Whenever they draw something, the tool creates relevant HTML, CSS or Javascript, and engages the browser, showing the result visually. This totally flips the entire software designing process, making it more efficient and beneficial for everyone involved. The benefits are as follows.

Code-Based Design Ensures High-Fidelity and Interactivity

Unlike image-based tools, the code-based approach provides 100% match between the intent of a designer and a code-able result. That’s because code-based tools use the same technology as those used in web development to render all of the design projects. As a result, designers can benefit from the full power of code without any coding expertise.

Code-based design tools allow for drawing objects that move, interact, and create complex patterns – on the highest level of interactivity. Before coding the final version, software developers can fully experience the product instead of just imagining how it should work.

There’s no redundant code, so the software works quickly and it’s easy to maintain it. And as the provided designs reflect the approved standards for software development, the final products created by a given company or a software house are consistent with one another. 

Code-Based Design Bridges Gap Between Design and Development 

The code-based design establishes a common language for both designers and software developers. Since everyone involved in the process uses the same technology, there are fewer misunderstandings between teams, especially on the handoff stage.

ou can even go a step further and use a technology such as Merge which allows you to take components that have already been coded by engineers and import them into your code-based design tool. It uses elements that can actually be coded – because those ready and interactive components come from developers.

This establishes a single source of truth for your entire software project – all the components and documentation are stored in a components library like Git (importing React components), npm or Storybook and designers and engineers are connected in one collaborative, creative process, preventing misunderstandings and frustrations from building up.

Also, it helps to avoid inconsistencies in the user interface, code, and documentation – which in the long run saves a lot of time and money by optimizing the design process.

Code-Based Design Provides Endless Possibilities 

Code-based design allows you to have richer prototyping options. And with the aforementioned Merge tool you can greatly extend them.

You can create your own components that can be reused all across interfaces of different products you work on. This saves your entire team a lot of time and effort on designing, coding, and testing particular elements – you only need to do it once. And this also means there are fewer bugs in your products.

Code-Based Design Allows for Powerful Interactions

Using code-based design allows you to create prototypes that look and behave exactly like the final product built by developers. Instead of linking artboards, code-based design tools use the most advanced interactions on the components level, allowing designers to create highly reusable interactive design systems.

Simply put: designers draw interfaces with text fields that can be clicked in, checkboxes that can be checked and unchecked, and so on. Goodbye, static artboards!

PayPal and Code-Based Design

Don’t just take our word for it – some of the top UX designers in the industry corroborate what we say. UX Design team at PayPal did a test of Merge, our new technology in our code-based design tool. Our solution has accelerated their work while giving them the power to easily create their own beautiful high fidelity prototypes consistent with their Developer Console standards.

When compared with an image-based tool, the design quality was much better and there were fewer errors. Also, unlike the competing image-based software, the drop-downs, calendar buttons, and data table controls made using UXPin Merge were interactive. And the entire designing process took less than 1/6th of the time spent doing the same job using the competing software!

Try it Out!

As you can see, switching from image-based to code-based design is a no-brainer. It can only save your team time, effort – and frustrations. To unleash the power of merging the design and development workflows, request access to UXPin Merge.

Reflections on UXPin’s 8th Birthday

On November 11th, UXPin turned eight!

Time flies! In 2010 I was 24, working as a UX Manager at a thriving Polish eCommerce company and, after several unsuccessful attempts to start a tech business (the youthful energy!), I took a break from any serious side projects. However, I still wanted to channel my energy towards something productive; 9 to 5 was never really an option for me. Instead of pursuing dreams of a tech breakthrough, I decided to team up with two friends and enjoy exploring the problem that bothered us for years — design — engineering collaboration. Without any business goals in mind, we started to think about helping designers and engineers work better together. The problem was very close to our hearts, we just didn’t know what the solution could be.

Freed from the constraints of a firm idea, we considered multiple options. A workshop or conference? A book? Some sort of software? Physical product? We casted a wide net.

After couple of months of creative explorations, we settled on the idea of… a paper prototyping notepad.

We believed that if designers and engineers could use the same tool, they could find the common ground for collaboration. Paper seemed to be the solid foundation for what we wanted to accomplish. After all, everyone is familiar with paper and can use it for creative purposes. The only issue? Not everyone can draw. Somebody who isn’t comfortable sketching will likely be terrified of sketching in front of others. We decided to eliminate this fear by providing designers and engineers with a set of predefined, generic user interface elements printed on sticky notes. Instead of drawing interfaces you could simply pin (yes! This is why we’re called UXPin!) elements to paper. Anyone can do it!

Early visualization of the first UXPin product. November 2010.

Fast forward a couple of months of prototyping and testing our tool, searching for the right manufacturer and waiting for the production to finish — on November 10th (one day ahead of schedule!) we were ready to launch UXPin!

Well… almost ready.

The one thing that we were missing was our… website. Ridiculous, taking into account that, in this entire project, building a website was the one thing that we felt really comfortable doing. We had no experience building physical products, but building a website? We certainly knew how to do that. And perhaps that’s why we left it at the very bottom of our list of tasks. To launch on 11th, we had to fix this mistake… and fast.

On November 10th we pulled a true all–nighter. We started designing and coding after our full–time jobs and finished at 4am. The first version of uxpin.com was the most impromptu thing that we’ve ever created. Once the website was ready, we had to wait until sunrise to take pictures of our notepads. After all, people had to see the product! I remember moving my desk as close to the window as possible to catch the first beams of sun. We were exhausted.

The original UXPin Website. November 11th 2010.

After all this hard work, our approach to the launch was as simplistic as it was anticlimactic. We announced UXPin on Twitter.

Our marketing was unbeatable 😎 . First tweet about UXPin.

We got our first order 2 minutes later. Another followed 5 minutes later… 48 hours in and we were completely sold out, deprived of sleep (massive adrenaline rush!) and unsure what actually happened (and how!). Over 400 notepads sold in 48 hours in dozens of countries. UXPin became the talk of the design town.

First UXPin pictures. Definitely worth waiting for the sun!

Some months later, All Things Digital — A Wall Street Journal tech publication, published an article about UXPin (likely the first “startup” from Poland covered by WSJ). A year later, we had turned our notepad into a SaaS application and raised our first round of funding. Soon, awards for the best startup in Central and Eastern Europe and even MIT 30 under 30 statuses followed. There was a rapid growth in number of designers and engineers using UXPin all over the world. This led to the decision to move part our business to Silicon Valley and learn to take this unexpected success even further. After months of fundraising we became one of the first Polish companies to raise capital in Silicon Valley and established our second office in Mountain View.

The legend of the web — Chris Messina was an early adopter.

Much growth, many changes, successes and failures later… here we are today. Almost everything is different. Design is more important than ever and UXPin is among the leaders in the design tools market. Thousands of companies, including world leaders of tech, automotive, finance and entertainment, rely on our platform.

One thing did not change, however: we’re still on the mission to merge design and engineering into one, unified, product development process.The task that emerged from our passions in 2010 pushes us to innovate still, 8 years later. We’re chasing the ideal software production process and that may never change. Perfection is impossible to reach, but always worth fighting for. That’s why our mission is so broad and ambitious — to push us beyond the limits of our abilities and discourage ever slowing down.

One thing did not change, however: we’re still on the mission to merge design and engineering into one, unified, product development process.

These past 8 years were nothing short of amazing. We met and teamed up with some exceptional folks (our first engineers are still with us!) and stormed through both joy and pain — always getting stronger. The experience of maturing together with your team, product and market is something that I’m going to be forever grateful for. Thank you!


Our exceptional team is always at your service! This article was originally published on Medium here.

Join the world's best designers who use UXPin.

Sign up for a free trial.