2 ms·

> While these tools provide useful means of visual expression, they often lead to developers having to infer design vocabulary from the mockups themselves [emph

> While these tools provide useful means of visual expression, they often lead to developers having to infer design vocabulary from the mockups themselves [emphasis added] Unless your designers are a 3rd party, bring them over to the dev team. Throwing material over the wall is almost always going to lead to a bad time when there are not experts on both sides handing off from one to the other. The designers should be working with the developers to implement their vision. In essence, from the developer perspective, the designer is the customer (at least up to a point). Your developers having to "infer" suggests that they aren't in a position (either aren't aware of who to ask or explicitly barred from asking) to ask the designers for clarification, that's a communication barrier that will cause harm to the project. Barriers like this (silos in general) are a great way to isolate separate groups, but also greatly reduce the effectiveness of everyone.

mikaelaast 4y ago
> The designers should be working with the developers to implement their vision I agree with the importance of this. I guess my gripe is with the fact that at the end of the day, the burden of formalizing anything that gets put on the web is on the shoulders of developers, even in the case of expressing design language, as this usually isn’t discernibly structured until the developer starts typing out code.
- Jtsummers 4y ago
  > I guess my gripe is with the fact that at the end of the day, the burden of formalizing anything that gets put on the web is on the shoulders of developers Welcome to the world of system development. This has always been the case unless your customer is operating at a similar technical level and can formalize the requirements in your own language (or near enough). Your designers are able to formalize their requirements, but using a domain of discourse that your developers are unfamiliar with, and probably missing details your developers need because they, the designers, are unfamiliar with the domain of discourse your developers use. This always happens, no matter the field. Each group has their own domain language with its own notion and degree of formalization. As the developer, it falls on them to ensure their understanding is correct. The same would be said for non-software development efforts. An architect has the same problem with their customers, and a builder has the same problem with the architect. It is certainly frustrating, but that frustration has to be overcome. Unless your customer (designers in your case) are intransigent and refuse to communicate when asked for clarification or refinement of details or feedback on a partial implementation, then this is a surmountable problem.
  - mikaelaast 4y ago
    Acknowledging that formalization typically occurs in the development process, it's worth noting that it's often the developer who initiates and enforces it. However, it would be beneficial for designers to see formalization as an integral part of the design process itself, which could lead to more efficient collaboration between designers and developers, ultimately streamlining the entire development process.

mikaelaast 4y ago

> The designers should be working with the developers to implement their vision I agree with the importance of this. I guess my gripe is with the fact that at the end of the day, the burden of formalizing anything that gets put on the web is on the shoulders of developers, even in the case of expressing design language, as this usually isn’t discernibly structured until the developer starts typing out code.

Jtsummers 4y ago
> I guess my gripe is with the fact that at the end of the day, the burden of formalizing anything that gets put on the web is on the shoulders of developers Welcome to the world of system development. This has always been the case unless your customer is operating at a similar technical level and can formalize the requirements in your own language (or near enough). Your designers are able to formalize their requirements, but using a domain of discourse that your developers are unfamiliar with, and probably missing details your developers need because they, the designers, are unfamiliar with the domain of discourse your developers use. This always happens, no matter the field. Each group has their own domain language with its own notion and degree of formalization. As the developer, it falls on them to ensure their understanding is correct. The same would be said for non-software development efforts. An architect has the same problem with their customers, and a builder has the same problem with the architect. It is certainly frustrating, but that frustration has to be overcome. Unless your customer (designers in your case) are intransigent and refuse to communicate when asked for clarification or refinement of details or feedback on a partial implementation, then this is a surmountable problem.
- mikaelaast 4y ago
  Acknowledging that formalization typically occurs in the development process, it's worth noting that it's often the developer who initiates and enforces it. However, it would be beneficial for designers to see formalization as an integral part of the design process itself, which could lead to more efficient collaboration between designers and developers, ultimately streamlining the entire development process.