In a typical software development project, various parties take part in such as front project managers, front-end developers, back-end developers, and designers. All of them view it from different perspectives through the window of their professions. Building a harmonious collaboration between them can be challenging. It requires getting to know other’s concerns.
In the previous blog post, we talked about how this experience is for front-end developers. This time, we are going to try to understand the designers’ point of view.
Collaboration within a team
Designers collaborate with project managers and developers a lot. There occurs a lot of information flow back and forth between designers and all parties. Ideally, the main purpose of this is to make sure everybody understands the main objective that projects are to serve. But unfortunately, in real life, this obvious common objective can be covered with many challenges such as deadlines, committed milestones, i.e. time constraints, which may cause it to be unintentionally pushed aside.
It would be nice and easy to blame only customers about the constraints those disrupt the ideal image of the implementation of the project – You know, the one in which everybody is on the same page about what the project is about; so the verification between parties, changes and updates are minimized; so designers can comfortably put their full effort on creative work; developers, on the other hand, can code the perfect architecture that makes the ideal design that the designer just handed in; the project managers can just enjoy managing this harmonious piece played by their orchestra; while customers are calmly waiting to receive the output…
Unfortunately, most of the time, in reality, things happen differently.
Although in a very competent team, there can be many fluctuations on this process. First of all, we are all humans, so it is a bit unrealistic to expect an ideal interaction among everyone, every time. Indeed, a healthy interaction is the key to the success of the team. Principles of quality communication is easily understandable yet to apply it can be surprisingly hard, which requires experience that is gained only in time and with determination. Designers make of the group which is at the heart of this interaction, which makes it interesting to explore the challenges of it through designers’ eyes.
In an ideal project development process, whether it is performed in an agile way or as the waterfall model, depends mainly on how well the problem and the intended solution to it are defined, and how well everybody on the team is on the same page in acquiring it. To strive for this essential objective of acting towards a common goal within a common ground is, of course, every team member’s responsibility. And everybody does it in their unique way, underlined by their role on the team, their knowledge level, and their own perspective shaped by their own experiences. What is expected or what should be expected from certain team members depending on their role in the team is for sure an extremely important subject. But, as you can see, it would deserve a meticulous research and discussion sessions devoted only to it, before daring to write an article about it.
Within the limits of our resources both in time and proficiency, in this blog post, we limit our discussion to hopefully understand how designers anticipate a teamwork, by humbly gathering various ideas and insights gained from various resources.
Avoidance from Communication
Back to our topic, we can say that designers in a software development project are supposed to be in constant interaction with developers. As designers expect developers to sufficiently implement the design, developers expect designers to hand in a design handoff that is feasible enough to implement while sufficing the project requirements.
But here is the interesting part: While confident in their profession, both parties hold themselves back from questioning the other’s expectations and output. What I am saying is that, when designers deliver a design handoff to front-end developers, the latter group tends to accept it as the perfect design and believes that no matter how hard it can be, it is their duty to produce the code that perfectly delivers the design. They abstain from starting a discussion with designers about some aspects of the design output. For example, they find a peculiar design component that it would require a bunch of CSS classes specific to only that component. Similarly, designers may find themselves in a position where they blindly design according to the requirements, without questioning them. Both parties simply think that it would be rude to question other’s work. By not simply asking the other, they put themselves in a position where they find themselves struggle alone with the complexities, which they could have resolved together. This attitude causes them to spend lots of time and effort in vain.
To prevent that kind of undesirable situation, designers must remember that they are an active member of the team. They should feel free to contribute to all parts of the project architecture. Indeed, it is what makes them valuable for the team: Their viewpoint on every bit of the project architecture and the implementation process is irreplaceable. They should let themselves keep calm, step back and see what they are about to design. They should value their own feeling about it. If something feels wrong, they should know that it is very important to share their opinion with others. For example, they can demand a brief meeting with front-end developers and project managers to discuss it.