Penpot Grid and Canonical at Hacktoberfest

We are Juan Ruitiña and Ege Su Acar, UX designers at Canonical. In mid-October we reached Penpot to find design tasks to tackle for Hacktoberfest.

We picked the Grid Layout feature to dive deeper into the user experience. Below you will find them divided into categories of the feature. After our feedback, we also provide one specific use case (tables) we believe that can reap the benefits of the Grid Layout to the max.

Even if we communicated privately, we think it is important to share the outcome with the community for the sake of open design :dizzy: Thank you Clara and Andrés for your kindness and openness; we are excited about this feature and the future of Penpot. Let’s keep this collaboration going!

— Ege and Juan

Penpot file | On


Learning Curve / General

  • For the user that isn’t familiar with the CSS grid, there are some points that might contribute to a slow learning phase at the beginning of their exploration:

    • Function names of items and content are confusing. I needed to read the Complete Guide to Grid in detail to understand it. It was very hard to observe/learn by doing.
    • Same for the different naming of align and justify under content functions.
  • Suggestion: Provide onboarding tooltips, contextual information/help, and links to documentation or a reputable source that explains the general concepts.


  • Grid configuration is lost when the user swaps from grid to flex, and back to grid.
    • Suggestion: Either save the config or display a warning such as “Your grid configuration will be lost if you switch to flex.”
  • Bug: Similarly, when a frame is already a grid, clicking on “Grid” on the Flex/Grid selector resets the grid as well. Nothing should happen when clicking on the grid again.


  • Currently there are two properties called the Grid (layout grid and the grid of the page). For the layout grid the differentiation exists because it’s under the title layout. For the grid of the page this is not the case.
    • Suggestion: Specify the function name more i.g. Page Grid vs Layout Grid.

Edit Grid

  • We are not sure if the Edit Grid button has the right button style. It’s a button that activates another function/mode that can be configured. However, it’s the same button style as the buttons whose function directly affects the selected item. For example:

  • When the user clicks on the buttons above, related property is modified in that instance.

  • This button has a different property but looks similar to the ones above.

  • More importantly, Edit Grid is inherently different from the functions that are grouped together. Unlike flex, grid would arguably always need to be defined before it’s used, so “Edit grid” becomes step 1 when using the Grid feature.

    • Suggestion: The button style should be different and should be as prominent as possible. Also it should be located separately from the other grid functions due to inherent differences from others. We think it’s best if it’s located above because it is necessary to define a grid before using it.

  • In the popup above, both Done and Close buttons have the same functionality. Our initial thought was that the changes made will be lost if the user clicks on the Close button, and will be saved if they click on the Done button. However this isn’t the current experience. If two buttons work the same way one of them is redundant. Clicking on the page already closes the edit. In this case we have 3 functions that serve the same purpose.

    • Suggestion1: Given the changes are always automatically saved, remove the “Done” button.
  • Also on the popup, Locate and Done (Saving edits or finishing editing) are contextually different functions. It’s confusing for the user for them to be grouped together.

    • Suggestion2: Move the “Locate” button to the side panel.
  • Unlike all the other functions, there is no hover information about what the above properties are in the Edit Grid mode. So the user can only learn by trial and error. It is particularly important to explain units, such as “fr”, as designers might not be familiar with them.

    • Suggestion: Having a hover explanation similar to other functions.

  • Bug: When the column/row size unit is in AUTO, there are two bugs with the bin icon above. Instead of deleting the column/row it only resets the size changes if the user has made any. In other cases, the bin icon performs as expected (removing the column).
  • Bug: When zooming in, the bin icon gradually disappears into the unknown. See below:

  • Note on accessibility: we noticed some fields are not labelled for screen readers. Clara mentioned that you will be updating Penpot’s UI soon with accessibility in mind. Let us know if you would like us to have a look at that at some point, we’re not experts but we are interested in accessibility :slightly_smiling_face:

Table use case

Creating table layouts is notoriously impractical on other design software. Our colleague Maximilian Blazek has high hopes for Penpot’s grid to make table creation easier. Grid is powerful and versatile, and we think making it work for this use case would be great.

One tricky bit would be the behaviour of adding or removing columns and rows. In HTML, tables (what is in a cell, row or column) are clearly defined by markup. For grid, it is not as straightforward, as this is only done by CSS styles. By default, content in grid “cells” flows to the next free cell. For instance, this means that adding a new column would move the first item in the next row to the previous row in the new column. Similarly, removing a column would push the last element of a row into the first column of the following row. This behaviour is consistent between CSS grid and Penpot, but impractical for the use of grid layout for tables.

One suggestion would be to use all the work you have put into the grid to have a separate “table” layout mode that is just adjusted to account for the differences between HTML tables and CSS grids, while retaining features such as drag and drop for cell content.

Some other features that could be helpful for this use case are:

  • Keep the ability to change the size of rows and columns, not only individual cells (vs flex/Figma’s auto layout behaviour)
  • Drag and drop to rearrange rows and columns
  • A way to duplicate rows or columns

These are common in visual editors (from Figma to text processors and spreadsheets) and could work even with the current “grid” layout.


I could not try grid yet, but I had similar problems with the flex-feature (despite CSS skills) . The attempt to design-like-codeable transfers what is meant to be written-in-CSS-code into a design tool. That is not without compromises – For example, while code easily can deal with a lot of modes, design tools are usually really good at continuous direct manipulation. Also, the naming of CSS attributes needs to be type-able and parse-able code, whereas these are no concerns for features in a UI, per se. (Though I understand that “designed as codeable” is a good selling point)


Juan & Ege,

Such an outstanding job! You’ve done a deep dive that understands the proposal while underlining key issues, both the ones we already had in mind (validating some suspicions, which is extremely valuable) and some that we did not. At the Penpot team, we are beyond grateful.

Now, let’s get our hands dirty. We made a detailed review of the proposed suggestions and came to some conclusions. I will try to summarize them following the structure of your feedback.

Learning Curve / General

We already have evidence that supports the idea that the feature is familiar and understandable for people with previous CSS grid knowledge, which is great, but we’re not satisfied with that. We agree that the learning curve for people who don’t know CSS grid is high (more-than-acceptable-high in my opinion). We loved your proposal to provide contextual info and learning resources and will implement it (see the screenshot below with the final interface). In addition, we are exploring ways to make the interface more understandable for everyone, but this will need a bit more time to work on.

The “?” button will show a tooltip and will point to the User Guide. We’ll add it to the Flex Layout settings too :slight_smile:


Although we understand the reasons behind this, we are not convinced with this solution for two reasons:

  • Is showing a message each time you change the grid type to intrusive? Could it interfere with your workflow? We tend to think so.
  • We believe that the action is not so destructive to need this level of control. In case of changing the layout type by mistake or you think it twice you can just undo it as with any other change to get back to the previous state.

However, we’ll keep an eye on this issue just in case it comes up again in other tests, meaning that we should revisit this decision.


This is a tricky one and we still haven’t found a convincing solution (the word “Page” is a bit reductionist in this context). There’s a clash between one very standard concept with another that is also standard and happens to be a namesake… we’ll keep you posted.

Edit grid

  • We agree that the position of the “Edit grid” button is far from ideal and that its lack of consistency makes it hard to recognize. We are moving it above as per your suggestion.
    We are still reluctant to change the style of the button, we have a visual system with some restrictions that we usually want to bypass for legitimate reasons (such as the one we’re talking about) but we prefer not to do it for the sake of the interface consistency. If the change of location is not enough we might reconsider this last decision.

  • About the popup, totally agree, too many buttons. About the “Locate” button position, in our current tests is being proved useful as it is. We are thinking of adding it also at the sidebar, but in any case, leaving it at the popup. This is how the popup will look (again, new UI applied):

  • The bug with the bin icon is already solved. Good catch!

  • Accessibility: We are in the middle of a complete rework of the whole Penpot’s UI, not only in terms of the look & feel but also at the code level (components, CSS, etc). Some of the issues like the ones that you mentioned are being taken care of with this rework and I’m sure that we’ll still have work to do after that. If you want to keep looking for accessibility issues the best will be to wait for us to finish this UI revamp.

Table use case

Ok, that was unexpected :sweat_smile:, which doesn’t mean it doesn’t make sense. In fact, kind of the opposite. We’ve already had several conversations with designers and PMs from organizations that work with interfaces mainly composed of big and complex tables that need to handle huge amounts of data. The need exists and we feel that there’s an opportunity there to better solve this problem in terms of product design and development. It is not clear though that this should be a Layout option at the same level as FLex and Grid, and we prefer to treat it separately, and that’s why I’ve created this user story including your suggestion.
Fun fact: While discussing this topic, we came up with the idea to add the ability to switch between CSS Grid and Table HTML formatting at the Inspect code panel.
Feel free to add comments there or open a specific post in this Community to open this conversation to more community members.

Current progress

We’ve not only digested the feedback but already started implementing some of the suggestions. We have a working file at Penpot with most of your suggested improvements adapted to the new UI and ready to be implemented. This one is public and anyone can take a look at it and leave comments there.

We also have the new UI activated in the Layout Grid test environment (if you’re reading this and are one of our beta-testers, you already had this new UI from the beginning), so now is closer to the way we will release it than while the Hacktoberfest.

No need to say (but I say it) that we’d love to know your thoughts about this iteration. And I’m not talking only to Ege and Juan here, anyone is more than welcome to join this conversation!


These compromises you brought up are a critical point and part of our most basic considerations. The approach of both Penpot’s Flex and Grid layout tries to bridge the gap between design and code through a shared language (wording and manipulation type, as you very well mentioned). With this in mind, I’m also well aware that this is a risky approach because, in some way, it could be said that it goes against the very reason why GUIs exist, which is (sorry for the extreme reductionism) hiding the computer complexity to match users’ mental models. In any case, both are features that are considered optional in a design workflow, you can do perfectly professional work at Penpot without them and under the usual conventions.

Our hypothesis is that in this specific case, bringing the two mental models closer together can be mutually beneficial, and we are already collecting evidence that shows that, at least with Flex Layout, the approach has been proven successful. However, Grid Layout has a higher level of experimentation and complexity and after various feedbacks like the one expressed above, we are already working on some tradeoffs to make it more understandable to people without previous CSS grid knowledge.


Hi there,

I’ve read these very interesting comments and wanted to share one as well.

I’ve been testing the new beta these last days, and find the changes really great :slight_smile:

Regarding the new UI, it’s much better I think, looks much cleaner and modern, and it was easy to quickly adapt to the changes. So well done on that.

Regarding the New grid feature, I also really love it. A huge thanks for this work !

One thing I noticed that might be changed (or maybe it’s for a reason that I didn’t catch):
When editing a grid, we have the pink frame that appears as well as the options in the right sidebar.

But if I click on one of the child elements in the left panel, the top popup saying “editing grid board” disappears, but the right panel remains unchanged. That means I’m still controlling the whole grid layout and not the child element, although it is the currently selected element in the left panel.

Once I entered the editing grid mode, I would expect the result of selecting a child element in the left “Layers” panel to have the same effect as clicking on this child element on the canvas.

Maybe more confusing: if I enter editing grid mode, then click on a child element on the canvas, the right panel displays the grid cell options for that element (which makes sense), but then if I try to click on child elements in the left panel, the right panel stays frozen.

It’s not a big deal once you understand it though, and maybe there’s a good reason for that ?

This is when in the “edit grid mode”:

And then if I click on an element in the left panel:

I hope it makes some sense ?


Hi @Louis,

Yeah, I think it makes a lot of sense. There are clear inconsistencies in terms of what settings should be shown depending on what is selected and the result is confusing. And especially in the case of your last remark, keep showing grid settings when you select an element that is not related to this grid layout makes no sense at all, you’re not missing anything.

We are already discussing these issues internally, once we have landed potential solutions I’ll share them here.


META: Since people (including me) were posting general grid feature feedback here – should we create a separate, general grid feedback/first impressions tread? Or rename this one?
Otherwise, title and content diverge, making it harder to join and to refind

1 Like

@jdittrich you are right, we should keep this post within the framework of the contribution, thank you for pointing it out.

I’ve created a separate topic to have this general conversation about Grid Layout separated:

1 Like