Especially in the UX industry, new fields of expertise often arise. Fields in which employees with different skills are necessary and can play to their strengths as an interface to other fields. We are talking about “hybrids”, people who can do two or possibly even several things or are at least interested in several. Designers who can program, authors who can design, analysts who can program.

One might think, which company would like to have such indecisive coworkers or even promote them? Quickly, they are labeled as “they can do anything, but nothing really good”. However, the benefits cannot be denied: hybrids are great at interfaces between departments or in small project teams, where everyone has to take on multiple tasks. At the same time, however, hybrids might be seen as nagging, when they reveal “weaknesses and problems” in every area which can be incredibly annoying.

For example, while the concept designers still deal with user needs, personas, and scenarios while the development team isn’t participating in the project yet, a designer with a coding background might already be thinking about how the whole thing can ultimately be implemented and is already putting obstacles into the concept designers way. “How is it used with a keyboard?”, “I’ll be difficult to implement these animations”, “The grid control does not work in other contexts, we have to think more modularly” etc.

A developer with a design background could hold of a designer during the development process. While the designer devises individual color semantics for states and individual areas, the Code Design Hybrid tries to solve all design problems with SCSS Mixins. At the same time, he tries to explain to the designer why too much individuality makes the maintainability of the code more difficult, instead of finding a good solution to implement the design as pixel perfect as possible.

Boon and Bane

Hybrids can tend to want to have a say in everything. And since it’s easier to find problems than to solve them, they also tend to “make” problems for all departments.

From business point of view at least, hybrids who not only see problems everywhere, but are able to solve them, are very appreciated. After all, even if they are not “specialists” and might need more time to solve profound problems, they can solve smaller problems directly and support the communication and procedure between the individual departments. Especially when it comes to topics of specification, such as documentation, style guides, UI kits or entire design systems. A designer who can empathize with developers will find it easier to understand the developer’s more easily.

The Everyday Life of a Hybrid

From a developer’s point of view, we always try to implement designs as pixel-perfect as possible. At the same time, however, we also don’t want to limit designers creatively (at least in the initial stages of a project). This often results in meaningful use of e.g. spaces, font sizes, colors, etc. within a screen, but within a CSS framework (such as Bootstrap) problems may arise. While the designer can always choose margins and sizes “freely”, in Bootstrap it makes more sense to work with the given classes. While an attentive developer would probably create their own classes to use Bootstrap to represent the design as pixel-perfect as possible, a developer with design background may “derive” the design consistently within the conditions of the framework. Even if here and there everything is not 100% pixel-perfect, it should stay consistent. Ultimately, maintainable and quickly produced code is just as important as good design.

As a designer with a little coding background, I notice inconsistencies in my own designs probably faster than others. Tools like Sketch or Figma help me to work as “modular” as possible. With symbols and styles, flexible and reusable “components” can be created, which significantly speeds up the workflow and makes the design more consistent.

Even wireframes do not have to specify a layout or precise components. As long as the interactions are understandable, a designer with a good understanding of user experience and standards will most likely achieve a good and creative result, even without using particularly detailed wireframes as a basis.

Applying framework standards also requires a degree of developer-affinity. If I for example, know at the beginning of the project in which framework the front-end is being developed, I as a designer have a direct documentation of the available UI components. I do not have to come up with “everything” myself but can refer to the standards of the framework. Is the calendar widget scrolling or paging through the months? Is the standard grid filter placed inside the table header or outside? Are columns shown / hidden through a dedicated menu or via left click?

Of course, this does not mean, that there cannot be any customization, and everything is just “standard”, but many design decisions are unfortunately not important enough to justify a bunch of custom controls or high development costs as a result.

Being a coding designer, writing documentation for front-end developers (pattern guides, style guides, UI kits, etc.) comes easy. Especially in the hot phases of a project where we need to deliver as quickly as possible, developers don’t really need a very “sophisticated” button documentation. Phrases such as “Buttons are used to trigger actions” or “The buttons provide a clickable UI functionality with arbitrary content.” Are not effective at this point. Front-end developers usually know what basic UI controls like buttons and dropdowns do and what they are used for. The “implicit” rules and behavior of controls is far more important in that stage as their functional description. For example, the distinction between links (navigation) and buttons (action) or which version of Navbar to use in what context.

Conclusion

The world needs hybrids! UI development is a very specialiced field in itself, so having a few people who do not specialize even more may help a lot.

Of course, the world still needs experts. Hardly any developer will be interested in building a core competency in typography and user interviews, but developers with a certain amount of user sympathy will help immensely.

We (designers) always think of users, but we like to forget that we not only work for the end users who later sees the product, but that in between there is a complete department that has to program these designs first. So, I plead that designers also consider developers as a relevant user group and not only demand from them to realize their design vision with their magical code.