3 ms·
It's only a force multiplier if your Design team sticks to it to the letter, and also if you are able to upkeep the components and refactor them nicely and ofte
by lucasyvas 5y ago
It's only a force multiplier if your Design team sticks to it to the letter, and also if you are able to upkeep the components and refactor them nicely and often.
What you more often get are requests to redo one page with a newer design and go from there. Well, the overhead for that is now massive, because all the components need to be refactored to allow customizable style, or you need to build new replacement components for pages to opt into, then redo the pages with all these new components slotted into a new layout.
...and all they wanted was to change the borders, input field appearance, colors and try to make the existing table more responsive.
In other words, they are (probably?) hoping that the page has something like one giant data object / hook that is 100 percent separate from the UI, where you can just screw with the style sheet and the markup to try some things out quickly and call it a day.
In a component design you have to think carefully about what gets data from where, but this is something the non-tech folks at an org just don't give a shit about, and they expected you to just be able to tweak the page.
So, to me the optimal technical approach is page template first, maturing into component re-use second. And I would suggest you decide carefully what to make into components when nobody has formally asked you to do so, because:
1. The overhead of arguing about time required to refactor/rebuild components is absolutely real. The point of components is that you shouldn't build snowflakes, yet that is what is routinely wanted.
2. Scope of "simple" component changes potentially touch the whole app when you'd rather it - or morely need it to - NOT.
- MrJohz 5y agoThank you, that's a very interesting response, and also the complete opposite of my experience with this sort of thing! In my experience, the design team is often even more component-driven than the dev team, with more interest in things right down to things like design tokens to specify consistent line widths. Whereas developers also use components to encapsulate design, but mainly use it to encapsulate behaviour or local state - say, a drop-down that needs a particular search functionality, or a breadcrumb component that needs to update as the page history changes. But thanks for your perspective.
- lucasyvas 5y agoMaybe you are just working with better designers than I have! I find they all care about these things, but either their imagination or direction from above gets the best of them and it ruins the party. Then you are left with change requests that don't fit with the existing design system - a bunch Lego blocks with nobody that wants to play with them anymore. I would say - on good days - my experience matches yours. On the other days... you are basically being asked to rewrite entire pages to conduct experiments. At that point I have to ask - is the Design request unreasonable, or did we make the wrong decision and prematurely optimize for components instead of just sticking with a more malleable template?