Ask HN: How to address the anti-pattern of inferring design rules from mockups? | Hacker News Reader

Ask HN: How to address the anti-pattern of inferring design rules from mockups?

7 pointsmikaelaast10 comments

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?

View on HN

> 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.

> 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.

> 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.

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.

OP here. I propose a concept to create a tool similar to Figma but focused on designing screen reader experiences. The goal is to encourage designers to formalize and structure their work in a way that would consider accessibility and user experience for those relying on screen readers.

This 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.

It got a lukewarm reception because it doesn’t take into account how design works and how it adds value. Designers are not engineers. Forcing them to formalize early in the process makes them less efficient and hinders their ability to explore widely.

Figma has a lot of features like symbols, auto layout and design system support which can be used to introduce formality and structure.

I feel like your second paragraph undermines the first one.

It doesn’t. Read more carefully.

Why would you not have a design system that represents all of the Figma components, so that there is a direct 1-to-1 mapping from a Figma component to a code component? That’s like 80% of the purpose of Figma, to use the components to align with the code.

While Figma can be a useful tool for aligning design with code, I think it's unrealistic to expect it to accommodate all the constraints of the web platform. Relying solely on a 1-to-1 mapping between Figma components and code components can be problematic and may not accurately reflect the complexities and nuances of web development.

Reply on news.ycombinator.com