[RFC] Admin UX Design (and hello from Figma!)

[rreid-figma]

Hello from Figma!

Heya, Payload community - I’m Ry, a designer at Figma based in NYC. (First-time caller, long-time admirer.) I’ve been working closely with James and the Payload team for a few months now, and figured it was finally time to jump in here.

In case you missed it, Payload was acquired by Figma back in June. You likely haven’t seen much of a difference in how Payload operates, and that’s by design. We’re still laser-focused on Payload’s roadmap, and executing as quickly and expertly as you’ve come to expect from the team in the past.

On top of that, our newly combined Payload-Figma team is already taking on improvements and new features—ones we’re approaching as thoughtfully and collaboratively as we can. That’s why each of these new projects will include at least one OG Payload designer and/or developer, and will be grounded in these handful of design principles:

1. Learn. Before we touch a single pixel, we want to absorb as much as we can. The depth and breadth of what you’ve all built is enormous, and it’s critical that we understand every aspect in order to decide what to solve and how to solve it.
2. Reinforce. We want to lean into what Payload already does well today, making sure we maintain the magic you’ve all come to expect. We brought Payload into the fold because of that magic, and we have every intent to keep it alive.
3. Expand. We want to build atop Payload’s rock-solid foundation, expanding on the features and capabilities it can provide for you. That means pushing what Payload already does even farther, along with finding ways to take advantage of Figma and Payload together.

When it comes to integrating our products, I’d like to be super explicit: We’ll share lessons and solutions from Figma where we can, but we won’t arbitrarily apply them where they don’t make sense. If anything, we aim to evolve Figma’s design system to support the unique patterns and use cases that Payload captures today. Ultimately, our goal is to (continue to) build something excellent for and with this community as open source software.

RFC: Admin UX Design

To get the ball rolling, I want to focus on one particular piece of the Payload pie: the Admin UI. As a relatively lightweight, minimal experience, we know there’s more we could do here, but... where do we start? That’s where we’d love your help.

We’re confident that Payload 4.0 should include an evolution the admin experience. Together, with all of you, we want to evaluate the design of that experience from top to bottom: how it looks/feels, how it’s structured, and how it works.

We already know some of what needs to improve, like:

• Information architecture: There’s plenty of room to improve how intuitive and clean the UI / core layout is out of the box.
• Drawers: They’re deeply powerful, but also take up a ton of real estate. We can make these much more nimble.
• Modals: The full-screen takeover and blur obscures context and unmoors you. We can tone these down to the just the right level of coverage and depth.
• Navigation: Between collections, folders, and the upcoming tree view, there are a growing number of ways to navigate in Payload. We can unify these while keeping those options within arm’s reach.
• Styling: From colors to fonts to effects, we can make styling simpler, more cohesive, and more innately accessible.
• Relationships: As one of Payload’s most powerful components, we can make it cleaner and simpler to use out of the box while maintaining its capabilities.

We know there’s more to be done, and we want to hear it. Tiny nits, big gripes, and everything in between—give us anything you’ve got.

This is just the beginning of something big, and we can’t wait to do this alongside all of you. We’ll share more updates along the way, so stay tuned. Thanks so much!

[ROBJkE]

Just copy the Notion UI 🫣

[jmikrut]

rip

[rreid-figma]

this feels like the pitch for like 90% of YC applicants

[swheeler7]

I would love to see improvements to the join field for relationships, as I love and use the join field/relationships regularly in a lot in the apps I build.

• Support WhereBuilder and search in the join field so users can filter/search joined data directly in the document
• Row button to delete/remove relationship (With an admin option to specify if the delete should cascade or not)
• Row button to directly open the related documents view instead of opening in a drawer (or option to change the default behavior, or maybe a column with "action" buttons can be added? Delete, Edit in Drawer, and Open document)
• Support for polymorphic joins (It's unclear to me if this is currently supported, I haven't been able to get it to work).
• Remove the "Type" column for non polymorphic joins

For me those are the main quality of life improvements that would make working with joins 1000% better. The other suggestion I have would be adding an alternative "array" appearance for joined data. I love the array field and it's really nice being able to edit arrays all directly within the parent document. But using the apis with array data (especially when updating array data) is a huge pain as you need to update the whole array field. It's also hard to work with relationships within/to array fields - there have been times when I have wanted to specify a relationship on an array item (not the collection the array is in) but that doesn't really work or make sense with arrays. So I guess for those reasons I think it would be awesome if joins could have an "array" appearance and you could specify which fields to show in the array - this would give the benefits of joins with amazing API capabilities and explicit relationships definitions while keeping the great array editing experience in the admin where everything can be edited in one collection

[hades200082]

I'd also like to add to this - allow the addition of existing items to a join. Currently it only allows creation of new items.

[rreid-figma]

This is awesome @swheeler7, really appreciate you doing deep on this. Whether or not we make big changes to joins as part of this specific project, I'll make sure this gets documented for when we do. Sharing it with the team now, in any case 🙏

[paulpopus]

Remove the "Type" column for non polymorphic joins

We can do this right now, let's get it in for next release

[cwray-tech]

I'm really excited about Figma being involved with Payload. As someone new to Payload (loving it btw), it will be awesome to see the design improvements y'all make. I am not sure if I have input in this RFC, but I'll be thinking about it.

[ForrestDevs]

One thing that I'd like to add here is an idea about a windowing system for the payload admin.

Check this out:
React Winbox Js
DEMO:

The idea behind windowing is that you might want to have multiple create doc views open or a list and a create view. Because you might be editing or working a doc that requires you have information from another.

The most recent idea I have in my head is within an ERP system. Where you have a sales order for a customer and then you need to create a purchase order from a vendor based on what that customer just ordered. So having all that information present within the same screen is a huge time saver.

Rather than the hassle of starting to create a new doc and then realizing you need to close it or partially save it (not always possible) to go back to another doc and reference the info that you need.

Windowing allows for an adaptable, and customizable workspace. And could be configured as an option for certain views.

Just an idea for a new non-intrusive UI flow that can make the admin web experience feel more native.

[rreid-figma]

@ForrestDevs Love this idea and the thinking behind it. Kind of reminds me of Arc's "Little Arc" concept—sort of a temporary window for quick reference, with the intent of closing it once the job is done.

Adding this to the list of things to consider 🙏

[wayz9]

Something my team and me would love to see is a loading/progress bar for file uploads especially on multiple file uploads. Thanks

[rreid-figma]

Totally reasonable ask @wayz9, adding it to the list.

[bbtgnn]

One CMS UI that I really like is the one of Kirby CMS. One aspect that I think they got right is the spacing of inputs/components. No matter the amount of content and controls, the layout always feels “bright and spacious”

[rreid-figma]

Thanks @bbtgnn - Density is something I really want us to keep in mind, given how easily CMS interfaces can get weighed down.

Feel free to keep passing along other examples as you think of them.

[hades200082]

Some thoughts from me:

• Add a simple option to co-brand the figma login and admin UI by adding our own logo - this helps staff trust the platform when we roll it out.
• Don't forget about position: 'sidebar' - we use this a lot.
• Make collection and global groups in the left nav able to be ordered by the dev somehow. Currently. we just set a group name in the collection/global admin definition and the ordering depends on the order the collections/globals are arranged in payload.config.ts - I'd like to see a config for specifically defining groups and the order in which they appear.

Anything else that makes it easier to deliver great admin user experiences, even for complex apps, to our users would be awesome.

[rreid-figma]

@hades200082 Solid ideas here, and we're totally aligned with them. I'm hoping we can unlock some of these smaller bits that have big impact, like sidebar reordering, but stay tuned.

If you think of anything along similar lines, pls drop 'em here and tag me

[beobungbu]

Shadcn ?

[rreid-figma]

Deferring to @jmikrut and @paulpopus on this one so I don't say anything too spicy 👀

[paulpopus]

Absolutely not

[beobungbu]

I think Payload UI could move forward in two clear directions.

The first is support for pluggable UI libraries. If developers could directly integrate existing open-source kits like shadcn/ui, Mantine or Chakra, it would save a lot of time and allow teams to keep using the design systems they already invested in. There’s no need to rebuild everything from scratch when the ecosystem already offers strong solutions.

The second is a meta-framework approach. Payload should focus on providing the data skeleton: CRUD flows, relationships, forms, tables, and navigation. On top of that, it could expose clean hooks and adapters so any UI library can be connected seamlessly. The built-in admin could remain minimal and fully customizable, serving as a starting point rather than a limitation.

This model would allow developers to either adopt the default skeleton quickly or bring their own UI stack. Refine.dev demonstrates this well by handling data and logic in the core while leaving UI choices to developers. If Payload takes a similar approach, it could become both a reliable backend and admin engine while staying flexible enough to adapt to any frontend ecosystem.

[rreid-figma]

Appreciate the detailed thoughts @beobungbu. We know design system flexibility is something some clients really need, and there are a few ways to go about unlocking that, to your point.

Ultimately I think we should provide flexibility here, just like Payload offers generally. TBD how much we prioritize that as part of this specific project, but this is a great push to think about that more explicitly. Pls share more thoughts like this as they come to you.

[jancbeck]

I'd like for the figma team to think about how a CMS would look and feel like in a world where most content online is created and consumed by human-authorized AI agents. What exactly that would look like I don't know - that's where you come in :)

[gridig]

First thing I do for every resource with slug field is add a direct link to that slug in collection list (eg. home is /home), makes it simple to quickly open multiple resources.

Also, the mobile experience is not the best in general.

[andythomo]

I think for me, there would be three things I would really like to see.

1. An easier way to customise or "white label" the Admin UI. I'm thinking that, possibly, with CSS variables, allowing customisation of spacing, padding, margin, radius, and all the UI primitives so that the user can have a coherent experience between the front-end application and the CMS.
2. I have used CMS as a developer and as an end user. The one thing that has always got to me as an end user is that they aren't often a nice place to be creative and write. You frequently see people writing in their chosen word processing application and copying and pasting it to their CMS. It would be good to see some thought put into the reality if I had to sit and write in Payload for a decent period of time. How does it feel? I appreciate that this isn't helpful, but the best analogy I can give is that you can write in a ballpoint pen or a fountain pen. They both write, but the experience for the end user is entirely different.
3. Everyone is on the move all the time. A better mobile experience would be great.

I have been using Payload for a while now and would like to add that it's a great product, and the rate at which you release features and fix bugs is impressive. Please keep up the amazing work!