Feedback and reviews
Communicating and giving feedback on our work is the lifeblood of a design system.
Well-functioning machinery around feedback and reviewing is essential for our design system to actually do its job. As I've stated already at the outset of this course, a design system is literally nothing if it is not respected and does not carry meaning.
So, what do we do to encourage a healthy culture? Well, there are several ways in which you could receive feedback. Without resorting to some all-encompassing taxonomy, you can expect at least these three:
I can't really help you with conversation in person, but I can provide guidance on the first two subjects!
Getting into the feedback loop#
How your feedback loop and change management works is a part that has to be something you and your team decides. If we backtrack to what I've previously said on governance, then this process should be explicit, known, useful, and directed. In other words, you should have some formalization that aims to make this process support structured change in a way everyone understands. This does not, and should not, have to involve rigorous paperwork, long meetings, or other blocking factors!
As we've already seen, it helps to build linearity into how a change flows from an idea to it being rolled out. In our project here, the way we've set up our operations is that everything that has to do with components always goes into Chromatic. There is no way around that. And if we go to our recent documentation work, we saw that small continuous documentation is a lot less hassle to deal with than doing lots of writing after the fact.
Conversation is good for small informal dialogue but is less good for formal, documented decisions.
Figma comments are great for contextually relevant notes that drive decision-making.
GitHub pull requests are excellent as a means to enforce documented, auditable changes in a somewhat formalized manner.
You want to take the best of these when setting up expected communication channels. How about we try it out in reality?
Making a controlled change#
Let's make a small change to demonstrate a pull request and how that works in our toolchain.
Commenting on the design#
Open up Figma and open your design file.
For our demo, let's imagine we had someone raise a usability concern in regards to the Input element being a bit unclear when it's actually focused or not. As an improvement, how about we change the styling of it?
This example may be a bit contrived since we are both writing the comment and reading it, but imagine for a second that someone wrote it for you.
Go to your Elements page and find the Input element. Press
C to enter comment mode, and click on the Input to place a comment on it. In my case, I wrote:
When this element is focused, can we try adding sharp corners and a fat outline?.
Notice how you can both reply and mark it as done with the checkmark symbol. By clicking the three dots, you can even access an option to copy a link to this exact comment! A contextual Figma comment is just so much better than writing a disjointed line in a typical DM tool like Slack.
The number represents the ID of the comment, which in my case happens to be
2. You can safely disregard what the exact number is. It does, however, make it easy to understand what folks are referring to!
Okay, with that, you understand the basics of Figma comments, and we have some feedback to use for our change.
Creating a feature branch#
We will create a feature branch to contain our change. When we feel ready, we will then do a "pull request," meaning we are requesting people in our team to validate, verify, and comment on our work. If it's good, it'll then be merged into our
First, create a new branch for us with:
As you see, the branch will be called, unremarkably,
improve-input-focus. The naming of a branch can take many shapes, such as referring to a ticket number. In our case, though, it's just a simple semantic naming we are going for.