4 ms·
I swear most of these are quoted elsewhere as good practices and used very well in certain scenarios. I agree with the article to the extent that blindly adding
by karamanolev 4y ago
I swear most of these are quoted elsewhere as good practices and used very well in certain scenarios. I agree with the article to the extent that blindly adding process has costs and if you don't reap the benefits, it's a net negative.
When all of these benefit massively is when there's large information/knowledge asymmetry, but the right questions and review usually doesn't get to the right person. E.g. junior devs architecting things poorly and then wasting time to implement a bad idea. Devs pretending to be designers and coding a UI that's just bad without consulting the designer when they should have.
Does just telling them "you devs to consult the designer more" work? I haven't seen it work. With the right steps to review design, architecture and so you could easily save more time later than you invest upfront.
- hbrn 4y ago> Does just telling them "you devs to consult the designer more" work? I haven't seen it work. Not immediately, but it does. The problem with process gates is that they don't fix the problem, they just hide it. Even worse, they treat problem as unfixable by nature. If your juniors are architecting, something is wrong with your structure. Juniors should typically execute somebody else's designs. If your devs don't have a good sense of UX, they should not have the power to make the decision to ship the product where UX is crucial. OTOH if they ship internal dashboards for one user (or for themselves), they don't need a designer approval.