Designer × Developer integration: why it is a problem and ways to improve it

The power of design isn't a mystery: designers translate needs — often unknown ones — into not only beautiful but, mainly, useful product specs! It isn’t always like that, but here at Guava the role of design in our context of developing digital products under an Agile process is established and valued. Our arrangement requires that product characteristics — its design — be understood in detail by the whole team so the solution can work in the expected way. Therefore an efficient integration among designers and developers is paramount.

However, I’ve always noticed some friction with this integration, plus we know there is always room for improvement. Then I started thinking about possible sources of those problems, and looked for ways to evolve the relationship between designer and developer.

I realized that these problems aren’t exclusive to our team or our process - after all, many companies report this as one of the most significant difficulties in the software development industry nowadays. There are also a lot of suggestions to help fix it. Why, then, write about this again? First of all, from my point of view, if it still is a problem, the discussion is worthwhile. Second, I observed that most of this friction is detected in a “design proving its value” environment. At Guava we are gladly past this moment. Design is a settled and serious deal, and despite all this we still have some difficulties with integration! I analyzed our scenario, read some articles, collected some insight within our team and compiled this text. I’ve tried to do it in a practical way, a way which could help our team and maybe someone else’s!

The context of the problem

Before diving into the subject itself, it’s important to remember that software projects are as diverse as they come, and so are the software business customers, processes, teams and their composition. We know solutions might not fit in every situation, so I do not intend this to be a prescriptive manual. I just want to introduce some ideas that are working in some contexts and that could eventually be adapted to others :)

The very concept of design can be fuzzy even for seasoned professionals in this arena. Trying to put it into objective words, in our scenario, the designers are responsible for understanding the problem (going through user and context research), conceiving a solution (dealing with flows and prototypes), translating this concept into interfaces (considering visual and interaction aspects: UI and UX) and for the implementation of those interfaces in the web environment (aka the browser). That’s a lot, granted! Furthermore, there is the key part of this whole text: the integration with developers so things can function the correct way - a responsibility shared between designers and developers.

On the developers’ side, after they understand the features reported by designers, they begin implementing the solution, considering non-functional requirements as well. A robust back-end along with a fluid front-end start coming to life.

One of Guava’s cornerstones is the Agile methodology of software development. We don’t adopt any specific framework; instead we blend some characteristics of a few of them and adapt our process according to the project and the client: “In an incremental and iterative way, we make sure that ‘a lot’ never means ‘too much’… We follow a direct approach, building and validating solutions in lockstep to make sure we’re always in the right direction”- more about our process on our site. In any situation, Agile principles are always there: highly collaborative, multi-functional and self-organizing teams, client/user participation and working software as a progress metric instead of documentation (once valued by the traditional Waterfall methodology). More about Agile in Agile Manifesto.

In this atmosphere, I realized all knowledge acquired by designers at exploration stages was not being broadcast/absorbed effectively to/by developers: many recurring questions were made to clients and some business rules were being wrongly implemented. What we really don’t want is reworking, especially based on internal errors, or to work as a disconnected team! Besides that, in an Agile world, we have to work with a high level of transparency, to have trust and commitment among team members. That’s why we are always looking for ways to improve the designer × developer integration.

So what about design in the Agile world?

Digital products are incredibly versatile, and customizable software brings this malleability, which results in incredible opportunities but also has an inherent complexity in its development. Agile methodologies have proven to be efficient in this context especially because of adaptive and iterative methods (divide and conquer!).

However, before its development, a product has to be conceived, and Agile enriches continuous learning instead of initial planning. At Guava, the product conception is one of the designers' main roles. Whereas Agile does not designate a phase for this creation — as opposed to traditional methodologies such as RUP — , it ends up being spread over iterations and split into specific functionalities being held each cycle. This partitioning may result in software that lacks cohesion from the users’ perspective.

In Jeff Patton’s book (User Story Mapping), Alan Cooper recalls Frankenstein’s story, in which the doctor “builds a creature from the disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity” and highlights the fact that we know this isn't possible (“[to] create life by sewing together random body parts”). However, he continues, this is what developers try to do all the time: “They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that developers are using their construction method as [a] design tool, but the two are not interchangeable.”

This narrative only reinforces our design importance assumption. However, it also makes us think: if we submit the designers to the Agile world, won’t we pervert their creative process and lose product conception as a whole (resulting in another Frankenstein project)? Or should we incorporate some design aspects — sometimes not such agile things, like documentation and planning — in order to make better products for users? In other words, should we make our Agile more design-oriented or should we make our design more Agile-oriented?

Like most things in life, we think the secret lies in equilibrium. Is it hard to find the threshold? Yes! Is this already fine line context dependent? Yes! Are we gonna miss this balance in some projects and overdo the planning? Yes! Are we gonna miss this balance in some other projects and lack the holistic vision? Also yes… However, let’s try to find this balance and cultivate the designer × developer integration to make sure the needed and sufficient information is held and transmitted in the most practical way!

Converging

In spite of different perspectives, Agile developers and designers are both extremely iterative, applying gradual adjustments and refinements; mainly because they recognize they won’t get it right first time: designers with versions of prototypes, user testing and adjustments; and developers with unit and feature testing and refactoring. Moreover, collaboration and empowering people to do their best are also valued in these two worlds. In a more philosophical view, both bring ideas into life.

On other matters they supplement each other: designers are responsible for conception and developers are responsible for implementation. However, for this complementation to be perfectly docked, designers and developers should be aligned and, at this moment, some divergences may arise…

Diverging

The problem approach discrepancy

I think this might be the most significant difference between designers and developers. Software development is, usually, a way to solve a problem through a system; frequently this problem is holistically seen by designers, while developers tend to see and solve a specific part of the problem at a time. Many times this distinction is the root of communication problems, for example: for a designer — glimpsing the product as a whole — information about a part may be complete and with some obvious rules of interference behind it; while for a developer, focusing on that specific part, the information is incomplete and obvious connections aren't so obvious!

Distinct schools

Designers are shaped to diverge their thoughts, to experiment, to ideate; while developers are shaped to converge, to implement a practical solution, with all variables under control! Many times putting these schools of thought together might bring some discomfort: to the developer inserted in a designer context with its ambiguities and to the designer that tries to solve the problem in an agile and more direct way.

The work in progress discrepancy

Developers, in general, feel comfortable exposing their work in progress, whatever the status of the work (even if it’s not structured or remotely complete); they prefer to keep delivering parts as soon as possible and are used to pair programming. Designers, on the other hand, are inclined to share the work only when it has a fully developed concept in it, not exposing it midway! It’s understandable: showing a non-optimal piece isn't part of the average designer mindset. However, with this discrepancy some issues might arise. At Guava we try to nurture an environment where designers are more comfortable with sharing their work, and demonstrate it, even if it’s not ready — especially to spare the loss of time. We do criticize — a lot! — but professionally.

Research timeframe

At which moment must user research be done: before, during or after? Generally, developers make their tests after (the deployment, for example); while designers want to research before thinking about the solution to better understand users and market characteristics; and they want to research during, and after as well. Certainly, the more you study, the more chances the digital product you are researching for is going to meet its demand. However, a huge amount of research in the beginning, might make it unfeasible for developers to act for a while and this might interfere with the agile approach and motivation of having some working software as soon as possible. The heart of the matter is doing enough research to ensure that the decisions for the project can be made but that it doesn’t waste precious time!

Deliverables?

Design processes of digital products, generally, result in a set of deliverables: research, research analysis, brand usage manual, information architecture, flowcharts, prototypes and mockups. Designers belong to a deliverable market. A lot of those artifacts, however, are made before development has even started. In its turn, Agile development advocates: working software over comprehensive documentation. Within this scenario, it’s hard, and sometimes frowned upon, to keep all those design artifacts. Once more, it’s important to understand which deliverables are really bringing value to the client, and ultimately, to the project. Our experience suggests that the value the client sees in deliverables is directly related to its degree of corporatism and the importance to the project itself is directly related to its complexity. We try to head the client towards the second approach; in the end, the project is what really matters to them, and deliverables end up being also used internally on projects with complex business rules (especially to promote designer and developer integration!). It’s important to highlight, however, that direct communication, or a paper sketch, replaces in many cases, a formal artifact.

Each one in a different world

We are used to people segmentation by functions and roles; besides, designers and developers run distinct practices, each of them is expected to live in their own world with their own peculiarities. However, an Agile context — and its self-organizing teams — requires people to understand each other's activities, so they complement themselves. Modestly, at Guava, we do have amazing professionals in our specialties, but we have to go beyond this — and we are continually trying to — with developers understanding the reasons of design activities and designers comprehending development routines. Moreover, we encourage concept explanations: when choices are substantiated it’s much easier to get others buying into the idea. It’s easier to get people to agree with what is indeed better for the project, to do an unbiased cost-benefit analysis. For example, a developer can understand the motivations behind a fancy interaction and the designer can comprehend the complexity it might add to the development; together they can weigh the pros and cons and adapt according to client needs and prioritization. Discussion is always there, but, with good integration among designers and developers, they tend to achieve a common ground.

After all these sources of divergence, how do we try to optimize designer × developer integration here at Guava?

Possible Solutions

Designers working ahead

It seems a paradox in an Agile development environment, and some even treat it as an anti-pattern, and halfway towards the Waterfall development methodology! It might even be some of that. However, in our context, designers working a little ahead of developers has proved to be a good solution.

Generally, at the beginning of the project, we have a design-exclusive iteration: client and user research, flows, conception. At the second iteration, when developers are structuring the application, defining its architecture and technologies, designers are diving into UX and UI processes about functionalities to be implemented by developers on the next iteration.

That’s the solution we found to give some time and breathing room for designers to do research into the system as a whole. After this first cycle, UX and UI keep moving forward (along with new specific investigations) at least one iteration ahead of the developers, who can implement functionalities with interfaces, validated prototypes and user stories already in hand!

Despite this functionality discrepancy within a single iteration, if a developer needs clarification in the spec she is working on, the designer retroacts to share her understanding of that feature. Besides that, many adjustments are necessary during back and front-end integration (if you work with software, you know how it goes!). That way, designers, actually, walk on simultaneous threads of distinct functionalities: looking ahead and being in the present.

It is important to highlight that we do not indicate a lot of interfaces to be ready before their development (which is what happens when designers are way ahead): as the development advances, the understanding of the system evolves, the comprehension of its flows is deepened, and adjustments are always necessary! Also, we do not want to re-work, to trash everything out. That said, designers might be ahead, but not too far !

Sharing the vision

This solution is related to problem approach discrepancy. Instead of seeing it as a harmful element to communication in designer × developer integration, we should try to use it as a strength.

Agile development favors incremental building; naturally, the team starts to focus on short-term solutions, and their fragments, and the global vision of the product ends up being lost in the sea of iterations. To take advantage of the holistic view the designers usually have, at the beginning of the iteration, designers present the feature(s) to be implemented. This presentation brings functionality details, but also its position in the whole system: its goals, the context of use and relations with other features.

These discussions have been fundamental in inducing insights about relations and interferences among systems parts. Many business rules are also brought to the surface, and the knowledge is flattened, which is essential in Agile and its non-meticulously described functionalities.

Communication

Client communication is imperative in our context; usually, we tell them: there are moments you’ll feel part of the team, sometimes it will be annoying, and it’s time-consuming, but we have to have you by our side! It’s needed because in the iterative approach we explore throughout the project and we have to validate soon (in a fast way) and always (in an easy and continuous way), to discover systems requirements and prioritize them.

Communication among team members, however, is more than imperative! We like to keep communication available for everyone, any member can join most of the meetings, and digital means of communication are broadly accessible. Of course, some subjects are not to everyone’s interest, or we know it will promote a discussion before a consensus. For those cases we try to use private means (we don’t want to flood shared vehicles, people would start to ignore essential messages), and, when there is a common denominator, we expose conclusions and motivations. It’s important to give a summary, so decisions are not only accepted but comprehended.

Besides that, we have experienced duplicated questions to the client. To avoid that, before asking the client, ask team colleagues first! Another common situation is a team member racking her brains trying to understand something. We know it’s part of the learning process, and we stimulate that. However, when information is not clear enough, and the speed is more precious, ask the team and ask again until you understand.

At Guava we don’t have fixed workstations, we define our table according to the project we are allocated. The physical position has proven to be essential to direct, fast and efficient communication by reducing its noise. To quote one Agile principle standard: face-to-face conversation is the best form of communication.

Low and high fidelity prototypes as communication and validation elements

Even though designers conceive the first holistic view of the system at the end of the first iteration, generally the only all-system deliverable is the digital product flow (other intermediate artifacts, such as research analysis, are also generated). Throughout iterations, other important design artifacts of parts of the system are created: low and high fidelity prototypes.

For us, those prototypes are used not only for content, navigation and aesthetics validation with client/user, but also to explain features to team members. Actually, before showing them to the client, there are internal rounds of exhibitions so developers can understand and opine (about difficulties and adjustments). This is the moment of negotiation between designers and developers, both keeping in mind, surely, that the main goal is to meet the customer’s need and that a cost-benefit analysis must be carried out. Besides that, prototypes are also referenced by user stories.

User stories

User stories support designer × developer integration because they translate into words functionalities discovered by designers so developers can implement them. In Agile, extensive documentation is avoided; therefore the detail level is controversial: we have to control project scope, but we don’t want to overstate and lose much time! At Guava we are, actually, still looking for the great-level of functionality description and the responsibility for the stories. Although, it’s important to keep in mind that they (or an equivalent way to describe functionalities) are significant for designer × developer integration.

Collaboration

This solution makes every problem within either design or development (or any other kind related to the project) a team problem! For all responsibilities to be shared among every team members, knowledge about each other`s activities is necessary.

On one side, the collaboration aims to democratize the responsibility of the user experience through a co-design: designers will conduct design processes, however, developers should be included on creation processes. For a practical example, see the topic: All team in the immersion process.

On the other side, development issues might be persecuted by designers as well. For a practical example, see the topic: One more point for the unicorn designer.

All team in the immersion process

This solution promotes a better knowledge about design activities among developers: developers somehow act as researchers, diving into design processes, understanding and participating in product design choices for at least an iteration. This mix ends up generating new ideas and even better solutions. Moreover, this process has proven to be important for strengthening relationships and increasing team synergy, as we have different teams for each project.

Remember I said that we dedicate the first iteration exclusively to design? Increasingly we try to include developers in that step, making them act as designers! Every team developer participates in dynamics, researches and gets their hands dirty analyzing all collected data too! It helps designers to move faster (the amount of time is limited), allows developers to understand the product and, certainly, pays off along the project improving designer × developer integration.

Throughout the project, we also try to include, at least one developer on crucial design decisions, so their intuition contributes to the decision process.

One more point to the unicorn designer

At Guava, one of the design principles is: “the means of production also belong to designers”. In a broader spectrum it would mean the designer knows the material to make her product; in our set, it implies designer also develops! Here they implement web interfaces with HTML, CSS and, some cases, JavaScript. This solution promotes a better understanding about other developers` activities, besides other benefits that are reported on this post: The Myth of the Unicorn Designer’s Myth.

We know that there are differences among different technologies, but designers pursuing technologies for the creation of digital products raise in themselves a more realistic perspective about boundaries and barriers (that may or may not be overstepped!). Besides changing designers view since product conception, this reality makes them understand developer difficulties and act as a team trying to solve them.

Designer × Developer

In our software world, bringing the design team and development team together — and making them `A` team — has shown to be a challenge. Communication is an important part of this process, but it won’t solve everything. We need to be willing to understand each other's practices, put our abilities together in an effective way and we must look at our client/user needs as the ultimate goal! In the end, we have to keep in mind that the ‘×’ from ‘designer × developer’ must not signify antagonism; it must multiply one by the other, bringing greater results!

Share your experience as well, we would love to hear about it!

Thanks to Filipe W, Renata M and Tiago S who helped with text reviewing and illustrations; and thanks to all Guava team members for the insight, for teaching me so many things and for letting us try to improve our process.