In almost any job I know of on earth. It helps a lot to somewhat know the work of the person directly in-front and behind any process queue. With diminishing rate of returns further down the chain.
So for a hypothetical fancy restaurant example.
Doorman > Waiter > Senior Chef (cook) > Junior Chef (prepare ingredients)
doorman/waiter benefits from knowing each other jobs, as it will help them coordinate the flow of human traffic (smoker section, VIP?) in and out of the restaurant to their appropriate tables.
Waiter/Senior Chef benefits from knowing each other jobs, as it will help them manage and communicate the demands of the consumers as the orders comes in (especially as ingredients starts running low)
Senior Chef / Junior Chef needs to know each other roles, as it will help in similar fashion ensure the flow of chopped fish/veg/meat/etc.
However for example, its really not needed for the junior chef to know the doorman job, as it will hardly improve each others performance. (in most cases, there will be exceptions)
So back the programming + design? Strictly speaking nope its not required, just like the restaurent example.
However with thousands of corporate and government website being built without a designer (due to budget constraints, and that its not meant to wow or sell to users, who instead must use the system, rather then choose to do so)
As you have experienced, while technically functional (if given a manual). It would have been so much more better, if the developer had some simple (not fancy) understanding of design.
So yea, it helps a lot =)
My goto for developers, is to point to material design guide, and ask they try to learn as much as they can from there.
Also one of the key points of "devops" is to bridge this chain, by letting each specialise individual educate across the team (eg. security, educating developers) to help improve the overall product. To help smoothen such flows
Anyway for dev here is the "typical chain"
UX
UI
API for UI
Data Services API
Database / Infra services (eg. network file servers)
In almost any job I know of on earth. It helps a lot to somewhat know the work of the person directly in-front and behind any process queue. With diminishing rate of returns further down the chain.
So for a hypothetical fancy restaurant example.
Doorman > Waiter > Senior Chef (cook) > Junior Chef (prepare ingredients)
doorman/waiter benefits from knowing each other jobs, as it will help them coordinate the flow of human traffic (smoker section, VIP?) in and out of the restaurant to their appropriate tables.
Waiter/Senior Chef benefits from knowing each other jobs, as it will help them manage and communicate the demands of the consumers as the orders comes in (especially as ingredients starts running low)
Senior Chef / Junior Chef needs to know each other roles, as it will help in similar fashion ensure the flow of chopped fish/veg/meat/etc.
However for example, its really not needed for the junior chef to know the doorman job, as it will hardly improve each others performance. (in most cases, there will be exceptions)
So back the programming + design? Strictly speaking nope its not required, just like the restaurent example.
However with thousands of corporate and government website being built without a designer (due to budget constraints, and that its not meant to wow or sell to users, who instead must use the system, rather then choose to do so)
As you have experienced, while technically functional (if given a manual). It would have been so much more better, if the developer had some simple (not fancy) understanding of design.
So yea, it helps a lot =)
My goto for developers, is to point to material design guide, and ask they try to learn as much as they can from there.
Also one of the key points of "devops" is to bridge this chain, by letting each specialise individual educate across the team (eg. security, educating developers) to help improve the overall product. To help smoothen such flows
Anyway for dev here is the "typical chain"
This a really great comment!