Ask HN: How to address the anti-pattern of inferring design rules from mockups?
At work, we recently discussed the issues arising from UX/UI designers using visual tools like Figma or Sketch to create mockups that front-end developers have to manually reverse-engineer into HTML/CSS. While these tools provide useful means of visual expression, they often lead to developers having to infer design vocabulary from the mockups themselves, causing a loss of value and potential misinterpretations.
As a community, how can we bridge the gap between visual and text-based web design to preserve design reasoning and intent? Are there better ways to communicate design requirements without relying solely on visual mockups? How can we emphasize the importance of a clear connection between description and visual presentation in modern web design tools to avoid costly mistakes and improve accessibility?
10 comments
[ 3.2 ms ] story [ 35.9 ms ] threadThis new tool would require designers to think about the semantics and hierarchy of the content, forcing them to consider not just the visual presentation, but also the underlying structure that screen readers rely on. By doing so, designers would have to make their design intentions more explicit and less open to interpretation by front-end developers.
I shared this idea with my coworkers and the reception was lukewarm.
Figma has a lot of features like symbols, auto layout and design system support which can be used to introduce formality and structure.
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.
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.
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.