UX designers and frontend developers in large enterprises often are not in the same team (which they should be, actually). Therefore the feedback loop can be long. Also, the goals may differ. UX designers are wrestling with the business realizing their dreams, visions and far-distanced road maps. Frontend developers on the other hand want to create features and components. Ideally sliced to be implemented within a small timeframe (say within a sprint of two weeks). And preferably develop everything only once. And it does not necessarily need to be perfect the first time. How can we overcome the large amount of overhead when trying to align on reoccurring web components (rest of the article referred as common components)?
Also published on linkedin.
We reinvent wheels
Within small organizations the overview of what’s there should not be that complicated. The amount of (frontend) repositories is limited. The number of developers is limited. The focus of what should be developed and/or designed is limited.
However, when the organization grows, more dreams need to be realized. More (business) features are longed for. More designs are required. More code needs to be developed. It’s hard to keep track of what has been developed so far by whom or by which team. The overview blurs. And therefore the risk increases that a UX designer redesigns already existing components:
- Another UX designer might have designed something similar (not necessarily recognizable as such)
- It’s not considered that certain functionality can be achieved by a tiny enhancement of an existing component
- Awareness that a component has been developed already is missing
The frontend developer might end up recreating the (more or less) same component:
- Not all components are put in a common component library
- No overview on what has been developed previously by other developers
- The integration of the component is hard because it has no well defined behavior
Not only this is timewise inefficient, the UX actually ends up worse with many almost similar (but not quite) inconsistent components.
Manual to common components
Using a common component library is for many reasons a good solution to overcome these problems. However, both UX and frontend developers need to know what’s in the library. Therefore a guide is required. This serves multiple purposes:
- It gives an overview what components are out there
- The user (whether it’s business, UX or developers) can see how a component looks like and what its features are
- With code snippets one can see how the component can be used/ integrated
- Adding in some analytics about the usage per component can help manage the lifecycle of components (enhance, split, or deprecate)
- UX and frontend can refer to a component in a non-ambiguous way
And especially the last bullet is key in letting UX and frontend work together smoothly.
Less design, more productive
The UX designer can look up what component should be used within the implementation. He or she can refer to it by its name or some id from the guide. For a frontend developer it’s immediately clear what component ought to be used.
Also UX doesn’t need to design or reuse the design of the component over and over again. The pixel perfect details can be abstracted away with the reference. This speeds up the design process. And designs that are a bit outdated on some components can still be used. As long as you refer to the component. Or you could even refer to a component from a wireframe. This renders a fully updated design less important.
Identifying where to invest
UX in large organizations often create designs for multiple feature teams. Also, UX often knows upfront which (new) components are going to be reused in future designs (since they design or come up with them themselves). Within a design they can be pointed out easily by the UX designer (during a refinement of a user story for example).
A common component usually has some additional requirements compared to components used for a single purpose (like documentation on its behaviour, how to integrate it, listing all scenarios it can be used in, etc.). The amount of time spend on creating a common component is like an investment: it pays back over time. So one can argue to just create a common component for everything. However, that puts a huge burden on maintenance of common components that aren’t actually shared. Because a common component is only truly reusable when its API is properly designed and its behavior predictable. Making changes to the common component need to be done in a backwards compatible manner and proper versioning must be applied.
The frontend developer should be decisive in what is going to be a common component. This is because a common component is still a technical thing. However, if there’s no input of UX, this requires:
- Guessing (by some gut feeling) whether a component is going to be reused in some later phase
- Refactor a non-common component as a common one when it’s being reused in another app; this however increases the risk of developing a component multiple times
- Discussing (all) the designs upfront with the UX designer anyway to identify some common components
By letting UX pointing out what components should be reused, the frontend developer only implements common components that really are going to be shared.
It might happen that the business is moving forward a feature, without the design being finalized or even started on yet. In that case a (potential) common component can still be referred to. As a UX designer, just put a sensible name or id within the half-done design or wireframe. This way the frontend developer can already create a component within the common component library. The functionality or look and feel might need some enhancement. But the component is reusable at other places already. And when updating, in a later stage, the common component library, the once placeholder-component is updated as well for free (as prerequisite that the component is backwards-compatible).
Using a guide for non-ambiguous references
When designing UX for multiple teams, or creating components that ought to be reusable throughout an entire application landscape, the amount of overhead can be tremendous. Using a guide so one can refer in a non-ambiguous way to reusable components takes away a lot of the overhead involved. This is especially true in a scaled agile organization. Here not always the same person works on designs or components. Also it helps making the designs more resilient and unequivocal when not immediately implemented.by