3 ms·
I think this is largely a personnel & hiring problem. Stop hiring people who can't work in teams. It takes more than just Developers to ship good software. Stop
by madeofpalk 4y ago
I think this is largely a personnel & hiring problem. Stop hiring people who can't work in teams. It takes more than just Developers to ship good software. Stop hiring designers who cannot design software.
> do you also find that there's a lot of tension between developers and designers?
To be honest, no, not really. Only ever at one job have I experienced a problem with developers and designers working together. One designer (out of two or three) was very ego-driven and was focused on producing a piece of art to hang on a wall, while one developer (contract, out of five) just flat out didn't respect anyone else (developers, designers, or PMs) and it was "his way or the highway". There are ways to work around this (mostly around setting clear guidelines for process and expectations), but ultimately the problem is with those people. Let them go.
Good designers are those who recognise that you don't ship PSDs (or Figma designs, as it is now) and are aware of the iterative approach to developing software. Good developers are those that actually respect the design process and set aside time for it.
If you structure your project/team/company where developers and designers are separated, and designs are "chucked over the wall" you will forever be running into problems. The best teams will be cross functional and have design's included in every step of the process.
Design Systems can be a huge help here - when everyone (designers and developers) have a common vocabulary of how a product looks and acts. Get this mature enough and you can just design your product with wireframes.
- lcfcjs 4y ago
- miketery 4y agoWhile yes non team players on the design side or dev side can be an issue, just as much it could be project / product managers. I think the key to a well oiled machine is good direction from product, getting everyone bought in on the vision / roadmap (or at least understanding the priorities). From there working on the Information Architecture (I call it data design). Having the data design clearly defined alleviates many issues. It shows that there is clear definition and both sides can start working on their parts even though the final design blocks the final UI.