In technical teams it is common to see a diversity of tools; many companies allow their employees to choose the hardware and software within quite reasonable parameters. In design teams this is unthinkable. Close your eyes and visualize a design team: they are clones, all with the same tools, tied to software and hardware licenses, whose cost and integration with third parties often prevent any change to other tools.
Do you agree? Read @natacha’s full article. Natacha is designer at the Taiga team, Penpot’s sister product, and she wrote this post about diversity and accessibility that is so much worth the read!
It doesn’t stop with software and hardware licenses. I remember working with designers that outright demanded the employer to provide the largest monitors to them. Because if you have to design (with break points, fix widths etc) for large screens, your screen has to be even larger.
The challenge is: how do you procure a license in private to learn the tool so you can get a job (at which the employer buys another license for enterprise tier)?
The other entry barrier I notice is the knowledge gap. There are design schools that teach you many, many lessons. I’ve only catched up through books as a self-taught learner, because I want to understand the language and mental model of my peers. There is so much to take into account: empathy maps, information architecture, vertical rhythm, colour contrast. The list goes on.
Lastly my experience with designers is that it’s hard for them to take critic. In the development world, critic helps to improve the work. In the design world I feel like they would take it personally more often than not. That’s partly thanks to their education. They get judged by the results they produce individually.
I’m aware, that I touched on several topics here. Each could become a thread on its own. Please don’t consider it whataboutism. I have so many things to say, that’s all.
The tech and the design community are very different in their values and concerns around the use of tools. From the perspective of the open source community and many developers, the article holds true. However, many professional designers could easily say: “Accessible?! Seems you need years of practice to create something useful [that is more than some bash-script] While it also takes years to be a great designer, you do not need to learn some abstract programming languages, math and development principles”: What accessability means, is much dependend on the community that discusses the issue.
Critique also helps to improve in the design world, particularly when designers criticize each other’s work. This is similar to critique among devs. Designs, in contrast to code architecture or the way one writes a method, also gets criticized by many non-designers. And this critique is often hard to put into action. It can feel like an issue written by a person who has never written a issue. Yet the critique is given by people who have some power over a designer’s work. A part of the defensiveness might come from that.
Another factor is that critique in software development, particularly open source projects is often harsh , and people get used to it – or leave the profession. So what is okay for a developer might be too harsh for a designer, much like Germans tend to be more blunt with their feedback than people in the US.
