Dividing React Work Between Designers and Developers

“Who writes the HTML code in a React app? Should it be the frontend developer, or should it be the designer’s responsibility?”

Ah, the age-old question: how to divide work between the developers and the designers?

Both sides want to contribute toward an awesome end product, and the fastest way to get there is to play to your respective strengths (or so the thinking goes).

So people get this idea that the designer will do the HTML and CSS while the developer writes the JS, and then you’ll just marry the two together and it’ll be happily ever after.

But that’s likely to lead to disaster. Developers can’t write all the JavaScript code without ever touching HTML. There’s too much interaction between the two. Some degree of hopping-back-and-forth is almost always necessary.

This rosy ideal was one of the selling points of Angular: templates are written in real HTML in separate files, so the idea of dividing the work cleanly at the HTML-file boundary was built right in.

Compare this to React, where “HTML” written is written inline with the JavaScript, and you can see why designers might be apprehensive if they’re not used to JS.

Now, technically, there isn’t any “HTML” in a React app. It’s called JSX, and though it looks similar, there are a few differences. For the most part, though, valid XHTML (close every tag!) is valid JSX. Biggest difference for designers: the “class” attribute becomes “className” (even if there are multiple classes to specify).

Ways of Working

Here are a few different ideas for how developers and designers can divide and conquer to build apps quickly:

Workflow 1

• [Designer] Create mockups for whole page(s)
• [Designer/Dev] Create a static page (HTML+CSS) from the mockups
• [Dev] Cut up the static page into React components, add necessary logic

Good if: Designer doesn’t know JS and can’t (or doesn’t want to) learn.

Watch out for: More iterations might be required if the static pages don’t adequately describe the feature(s).

Workflow 2

• [Dev] Build an ugly-but-functional implementation based on feature spec
• [Designer] Work with the React components (JSX) to add styles

Good if: Designer is comfortable modifying pre-written JSX, working with CSS, and probably has some knowledge of using the browser dev tools.

Watch out for: The “ugly” implementation may turn out to be lacking in more than just style. If a more complicated user experience is needed, substantial re-work could be necessary.

Workflow 3

• [Designer] Learn Enough JSX to be Dangerous (TM). Create the static components in React with JSX.
• [Dev] Add the necessary logic to the React components, wire up the server calls, and make it all interactive.

Good if: Designer is willing (or happy!) to learn some new skills.

Watch out for: Simple components will fit this flow nicely, but complex ones with a lot of conditional logic will be harder to approximate with plain JSX that doesn’t include any JavaScript.

Wrap Up

Hopefully this gives you some ideas for how to structure work within your own team.

If you’re already following one of these workflows (or even something entirely different), let’s have a discussion in the comments below.

And if you’re interested in learning React, I have a React book and also a React course, which you can buy together or separately. While I recommend some knowledge of JavaScript, folks with very little JS experience have said it’s easy to follow.