Why would a visual designer ever read a web framework tutorial?
Tear down the silos. Figure out what your coworkers on the other side of the wall do for better teamwork and less headache.
Maslow once made the observation “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Here Maslow takes the classical observation about hammers a bit further and points out a specific temptation to just give up and say “I am aware that a hammer is not the right tool for this, but I will use the hammer anyway and hope it works.”
Now I want to rephrase this problem into a flat-hierarchy/high-autonomy/self-organising furniture manufacturing pipeline. Let’s say the carpentry station has a bunch of hammer geniuses, they wield the hammer like no one else does and somehow can successfully attach wooden planks together according to the specifications by hammering screws into them. But now the surface of the wood around the screw is ruined and upholstery people have a tougher time doing their job because the cloth they use snags on the splintered wood.
Now the obvious improvement is to make sure that upstream actors better understand the needs of the upholstery station. Carpenters could very realistically spend time working with upholsterers to get a better and tacit feel for what they need. Or people who write specifications for carpenters could explicitly specify that the surface around the wooden joints should be smooth.
Maybe you don’t need a silo
The old-fashioned scientific management thinking has a solution for this general problem. The summary version goes like the following: Management sends an expert to observe the upholstery people as they work. This expert is supposed to successfully deduce that their issues are caused by hammered screws. The expert is not even strictly expected to talk to upholsterers. They are simply not supposed to know about other organisational silos anyway. If the expert correctly deduces the cause of the problem they go and check on the carpentry people to cross-reference findings. They then look up some information in reference books and hand a report to the management. Management is then expected to correctly interpret the report and convert it to a list of actionable orders for the production line.
Scientific management figured out where the problem lies. The basic assumption, that feedback should be collected and then processed into actionable plans is correct. Yet in practice such harsh top-down approaches inherent to scientific management fail due to various communication problems inherent to organisational silos. Empathy can’t be mediated by a technical expert.
While keeping in mind that Agile only applies to smaller task forces, Agile suggests we do away with the extra steps by tearing down the silos and letting workers talk directly to each other. In our example carpenters must be receptive to complaints from upholstery people. If they truly know and understand only hammers, how are they supposed to process the complaints of snagged and ripped clothing? This level of over-specialisation produces people who can’t understand feedback that comes from other perspectives.
People with an agile mindset read others’ manuals.
Let’s connect this example back to software development. Depending on the business case, a visual designer can be a station on the workflow like the carpenters, or a specifier whose outputs are de facto GUI blueprints. Either way they are likely to be upstream deliverers to developers, and directly affect their quality of work.
It is a bad idea to give a bunch of screenshots to a team of code writers and tell them to get cracking. Database people work with unchangeable data structures. The visual design has to keep in mind that these data structures are basically raw material to shape the user experience. Their transformation in front end or middleware is not free. When given an existing database and a bunch of screenshots, code writers will find a path of least resistance between the two and stick with it to the end.
Avoiding bad filler material in a product requires unified design, a bottom-up integration of different disciplines into a unified design requires a unified language. Sometimes such languages can be found and used off the shelf. More often than not, practitioners of the disciplines have to sit together and actually do teamwork on projects to locally develop a common language through trial and error.
As individuals each of us can expedite this processes by doing work to meet everyone else halfway and investing some time into adjacent fields of knowledge. This is why people with an agile mindset are valuable for agile teamwork; they have already done a lot of work to meet other people at some hypothetical midpoint.
Written by Alp Bilgin and originally published by trendig technology services. trendig — get your best ideas with us!
