Using Figma to Drive Frontend Development
If you’re a bootcamp grad coding out your frontend without designing it first, you’re skipping an incredibly helpful step.
So here are the facts. As a fresh bootcamp grad working on portfolio projects, you are the designer, and the front-end dev, and the back-end dev, and the project manager.
It took me a while to figure this out; I think I went through the 5 stages of grief,* but this is what it is. What do we do with this? Process is very important.
*five stages of grief: denial, anger, bargaining, depression, acceptance.
I want to talk about taking a couple days out recently to go back to basics and learn Figma to help myself. Turns out it’s not a regression, but actually the right move, a best practice. Ed from the Dev Ed YouTube channel strongly recommends designing with Figma ahead of time in this Figma tutorial. Also, even as a beginner, this is something that I’ve known I should be doing for a while, but I think one negative side effect of the (at the time) useful and propulsive sense of urgency to learn and move quickly in my bootcamp, is that best practices like this weren’t usually given time or attention.
It took me slowing down and allotting myself two weeks of mental space to really work on a project from scratch to create the atmosphere of patience which allowed me to say “ok, we should probably design the UI before I start writing React code.”
And this is also what the React docs recommend. It just feels a little sucky to read something like this as a bootcamp grad: “If you’re working with a designer, they may have already done this, so go talk to them! Their Photoshop layer names may end up being the names of your React components!”
Remember, if you are building your own project, you are not just the frontend and backend dev, you are also the PM and designer. So if you’re feeling a bit at a loss while reading the “Thinking in React” doc, realize that this newbie tutorial actually starts one step ahead of where you might be: it assumes you’ve already designed the frontend, and you just need to analyze it and draw boxes around it so you can start coding.
If you haven’t figured out your design and you don’t know how to use a design program, you might consider starting with a Figma tutorial. For me, with my current project, this helped me approach the project confidently, knowing that I was starting at the beginning, not in the middle. By designing the UI first using Figma, I was following the development principle of “reducing the greatest amount of uncertainty earliest.” (Thanks to Sam Fisher of Fisher Metrical for this nugget of wisdom.)
This brought me to some other questions:
First, a thought that’s already come up. Thinking in React mentions that Figma/Photoshop design layers might actually just be the different components of the app. While I have some doubts about this occurring entirely naturally without any design expertise, I think the tendency of UI and design thinking does help tilt us towards this. For example, to my knowledge, in Figma you can’t make a container element (a box or some other shape) and double click on it to add text. You need to create the container (a box) and then create a text element and nest that inside of the container.
In this way, Figma’s UI design process reinforces important principles governing HTML, like nested elements and components. These are principles that also come across in HTML but less immediately and more abstractly; I often notice HTML reminding me of these principles when I have problems and mistakes in my frontend.
Reminders built into the design process with an app like Figma also help me think more clearly about how to step intelligently through increasing levels of complexity in the app-building process. By thinking purely about component hierarchy questions, like how one component may be rendering several others, I can first build a static app thinking purely about props and connectivity between different components. I don’t have to consider state.
Or as Thinking in React puts it: “To build a static version of your app that renders your data model, you’ll want to build components that reuse other components and pass data using props. props are a way of passing data from parent to child. If you’re familiar with the concept of state, don’t use state at all to build this static version. State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app, you don’t need it.”
This answers one nagging question that I had, which is, if I am building this out as a static app and focusing only on UI at first, am I creating problems for myself down the road by temporarily ignoring questions of state management? Is it a huge problem that I haven’t decided whether I want to use manage state with Hooks or Redux on this project?
At least according to my reading of Thinking in React’s explanation, no, I’m just coding in an organized way and minimizing context switching between UI design and app interactivity. According to the React team “it’s best to decouple these processes because building a static version requires a lot of typing and no thinking, and adding interactivity requires a lot of thinking and not a lot of typing.”
To conclude, I want to share a screenshot of a Figma design for the project I am currently working on, and a screenshot of the corresponding UI built with React, React-Bootstrap, and CSS + CSS Grid. This is the first time I’ve been happy with the way a UI that I built turned out (still building, so knock on wood), and that’s 100% thanks to designing it ahead of time on Figma.
I hope this was helpful. If you have ideas or resources on how to learn good software development processes as a self-taught developer, please comment and share your insights! Thanks.