(or: should designers write React code?)
This is some extended writing that got kickstarted by watching Brad Frost’s talk about Design Systems at the recent CSS Day 2019. If you are interested the video is online.
Before the conference I had heard a podcast episode where Brad was talking about design vs. dev and design systems with Dan Mall recently and I was like: Brad Frost certainly has veeeeery similar ideas about design systems as I have.
And then the presentation came and for the most part I was just nodding and I as like: yep, yep, that’s what we are doing in our projects. Brad uses his Pattern Lab, we use Bedrock. The deliverable to clients is a set of HTML/CSS templates and documentation of the components and patterns used. The underlying ideas are similar.
Now at some point Brad talked about how it might be interesting to keep the design system in basic HTML (as opposed to doing it directly in a framework like React) because, well, it can be a bit more stable, since HTML and CSS do not change every few years like Javascript frameworks do.
I am not sure I agree. On a surface level I tend to agree because I am not a JS developer and that part of the system, the HTML/CSS, is exactly what I can manage. But isn’t this a choice that is just limited by “our own skillset”? I.e. Brad Frost has wrote a blog post on his struggle to learn React.
I am in the same boat. I simply have never had the time (nor interest I guess) to learn React properly. I am simply not a JS developer and learning React is pretty much learning all the latest JS techniques.
My work is design, I live in a design application, sometimes in code, but never in deep application code. I don’t need to “make a route”, I just create a new template. If I want to insert a library, I don’t need go through a lot of magic mumbo jumbo, I just use a script tag.
Now, I’ve been doing a lot of thinking over the past two years. The thinking always comes down to the same: whether we should maybe start thinking of moving our design systems deliverable to something like React or Vue when delivering them to our clients – instead of basic HTML and CSS.
Do we deliver basic HTML and CSS because:
- we don’t specifically have the React/Vue skills
- because it is leaner – less work to make our “design point”
- because we don’t want to bother with the JS flavor of the day? (our clients can literally use any programming language)
And if we deliver a big HTML/CSS kit, how much translation work is there for the devs to make it a real working UI framework/design system?
If we would do a React deliverable, would the dev parties we work with even like that? The people I have interviewed about our deliverable are seemingly perfectly happy with what we gave them. I’ve heard things like “A great base to continue from. ” – “I have never seen such an extensive deliverable” “now we have much less work than we anticipated” “we have little CSS skills in the team so this was a godsend” and later on “we’ve used your design system to create 3 more apps without the involvement of a designer. Awesome.”
A lot of questions to unpack and I’m not sure.
All I know is that I am a UI designer who is not fluent in React or Vue at all, but my HTML/CSS skills are there and they are up to date. And this counts for the rest of our team as well.
So should we React? I dunno. I would welcome some opinions on this from designers who did venture a bit deeper into React/Vue than I did.
Anyway. I can go on and on about the design systems topic, as it has been a big topic at work for the past 2 years. I might just have to split this off into a separate blog post.
1 Comment
This is a very interesting topic that I have been thinking about a lot. I think, as unsexy as it might sound, that for this type of design/front-end work there’s a middle ground that sometimes gets overlooked.
Depending on the client I tend to stick to two main ways of delivering front-end prototypes:
Sometimes a static HTML/CSS/JS prototype is more than sufficient and the most time-efficient way to deliver a decent and framework-agnostic result (Bedrock, Fractal, Jekyll, Hugo are all great tools). I find this to be especially the case for clients that are still in the process of defining their tech stack or for those who prefer a more classical tech stack (where CSS-in-JS, CSS modules, client-side rendering are not something to consider). As long as you stick to a set of clear principles (whether it be BEM, ITCSS or something else), I find this way of working scalable and defendable. Nothing wrong with that.
Other times, there’s the need for something more flexible and dynamic. React might seem the obvious solution and from a technical point of view it’s great. But in practice I meet front-end developers that are great at writing modern JavaScript, but at the same time have very little knowledge of modern CSS and semantic HTML. That’s why I have been looking for a way to hand over interactive designs in a way that’s appealing to the implementing JS developers but at the same time allows me to do what I do best (write scalable HTML and frustration-free CSS). I compared multiple frameworks (React, Vue, Ember, Svelte) and found Vue.js to be the best fit for me.
It’s extremely powerful (and allows me to create very complex prototypes) but also sticks closely to web standards. Setting up a Vue project in a good way might require some technical knowledge, but adjusting markup and styling is a matter of editing HTML and CSS. Want to use JSX or render functions? Sure thing, but you can get around without them just as easy. Want to scope your CSS code to the component? Sure thing, but you can also just write SCSS code and use BEM class naming.
For the same reasons, I think the latest version of Svelte looks very interesting. I worked on multiple projects where I guided different people with different skillsets (HTML/CSS versus JS) working on the same Vue prototype without having to abandon their comfort zone.
There’s no golden bullet here, and there will probably never be. But in my opinion, as a designer-developer, there’s no need to become a ninja JavaScript developer in order to deliver a modern prototype. Decent HTML and CSS are more necessary than ever.