[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

[wkentdag]

Support WhereBuilder and search in the join field so users can filter/search joined data directly in the document

this is by far my biggest pain point in the current set of fields, hoping it can get some attention in the v4 ui updates!

edit: I actually mean in the relationship field. in the relationship select dropdown i'd like to be able to do more than just fuzzy find on the title field, eg sort by date (if not any arbitrary field) or, in the case of a polymorphic relationship, filter/exclude certain collections.

the simple search works fine most of the time but it's a real impediment when you have a lot of similarly named documents. it would be great if you could click on a button to open up a full WhereBuilder modal.

[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!

[damnsamn]

We tend to bring a common stylesheet between all of our payload projects, which has some quality of life improvements on the UX side of things. Minor tweaks, but we find it makes the CMS editing experience a bit more manageable. I'm largely really happy with the overall UX of Payload, but there are a tonne of little quality-of-life improvements that would have a big impact. Below are some of the major things we bring between projects

1. Layout max-width
When you're not utilising type: "row" fields often, fullscreen-width fields often feel really wasteful and overwhelming. We've found that adding a max-width to the main layouts feels a bit more focussed and intentional. On some displays, fields are often 5x+ wider than their contents. Compare the unconstrained vs constrained layouts at 1440p below: our max-width here is 1300px, which feels narrow initially, but have found it helps keep the editing experience a lot more focussed and clear.

2. Vertical tabs
We've found that adding another layout for the type: "tabs" field has assisted with clarity when we have top-level nested tabs. The similarity to ACF's tabs also just visually seem to make our more WP-familiar clients a bit more comfortable:

3. Vertical relationship pills
Especially when the number of expected items in a type: "relationship" field is high, or when their ordering is important - we've got styles enforce a vertical stack for a relationship field. The ui on the right side becomes a little clumsy, but overall I've found this makes ordered, high-quantity relationship fields easier to manage:

[eremannisto]

The layout max-width even as an option would be huge improvement!

[tsemachh]

For me mainly List VIew need to support next issues:

1. allowing default filter
2. sticky columns
3. quick filter for commonly used fields
4. have a better way to organzie the presets
5. support logical/(me)relative dates in the filter
   You can see some of the ideas implemented at:
   https://github.com/shefing/payload-tools/tree/main/packages/quickfilter

Another thing is the ability to reset specific view preferences (like only for this list view)

Last one supporting right panel in both list and details view allowing flexible editing of content in the context of either the list or the edit page itself (like editing relation from the main collection)

[PP-Tom]

The biggest thing that I've found trips clients up is the status of the page, whether it's a draft, published, unpublished or changed. It's not clear to the editor what status the page is in and whether it's publically accessible or not.

I see Payload as a Content Management Framework, in that it isn't just a CMS but has scope beyond that. But a clear page status, especially once you include internationalisation, is a thing I miss from a dedicated CMS.

Additionally, Tree View is definitely a great a feature to have to help architect complex multi structured websites with Template support for choosing between schemas from the same collection.

These personally have been the biggest friction points for me coming from Storyblok.

[otozyon]

Fully agree to the first point. Upon my first use of Payload I had to look into the database table to make sure what the current status of the document actually is :D

[HarleySalas]

How about Admin DX?

Have you seen the Mantine library in how its possible to change the look and feel of every single component from one file? You can change css variables to make token-like changes across the entire UI library, meaning that you do not need to do anything more than overwrite a few variables to align things nicely with your brand. Alternatively, you can be as granular as you like and change the way individual components look, at a config level. There is room to improve in Mantine I believe, but the concepts are there and it's very powerful.

I would love to see a world where @payloadcms/ui is a UI library, which has a theme system that can be customized and there is no application logic in it. Then, things like @payloadcms/next should import ui elements and build application logic on top of it, or something along those lines. For example, a table element should exist in the ui library, but a separate package or at least export location should contain the components which have application, or shall I say "config" logic associated with them.

Perhaps this is a bit of a different topic, but I think that designing with this sort of intention in mind from early stages is valuable and hope something of this nature will be considered.

[paulpopus]

Have you seen the Mantine library in how its possible to change the look and feel of every single component from one file?

I think this will happen just by the nature of moving to a properly tokenised system. For example there will be a primary colour which will consistently affect all buttons and UI elements for it and so on.

I would love to see a world where @payloadcms/ui is a UI library, which has a theme system that can be customized and there is no application logic in it.

It's something we've been thinking about but it might be out of scope for this one, essentially having our own UI library is what you're getting at here - we'll have more information on this when there's something to show

[birdy90]

It is also useful for extending the admin UI. Because for now I couldn't find any documentation on @payloadcms/ui, so I was not able to use it in my custom views to make things look consistent. On the other hand, trying to add anything else, like tailwind with daisyui, or other ui libraries, always turned out at least a bit painful. Sometimes, because styles were conflicting

[thinkscape-gmbh]

I wanted to share some thoughts on how we could improve the extensibility of the Admin UI. Right now, fully tailoring the admin experience can feel a bit restrictive. Here are a few key areas that would make a huge difference:

• Style Isolation for Third-Party Libraries: We should be able to drop in any UI component library (Tailwind, MUI, Radix, etc.) without Payload’s default styles bleeding in and causing conflicts.

• Comprehensive Component Swapping & Documentation: It should be possible to replace every single component, but this needs to be backed by robust documentation detailing the expected props and data structures. Currently, replacing something like the navigation requires deep-diving into the source code just to figure out what parameters to process.

• Component Reusability/Extension: Following up on the previous point, we shouldn't have to rebuild a component from scratch just to tweak it. For example, if we only want to adjust the ordering logic of the existing navigation, we should be able to reuse the base navigation component and just pass in the new logic.

• Global Layout Control: We need a straightforward way to specify our own structural layouts, like injecting a custom global footer or persistent header across the admin panel.

• Reliable Style Customization (Theming): Modifying the look and feel needs to be stable. Right now, achieving something as simple as removing shadows globally requires overrides that feel fragile. We need a way to customize styles without the constant fear that a minor version release will break our CSS.

• A Minimalistic Base: Ideally, the core Admin UI should be unopinionated. Removing highly specific built-in UI behaviors (like the rigid side-panel toggle) would give developers a much cleaner slate to control visuals and functionality.

• Separation of Concerns: Because the configuration file can become quite large and difficult to manage, it would be beneficial to split it into modular files. For example, UI-specific configurations could be isolated into a dedicated file.

Bonus:

Extending the Scope: Using Payload Admin UI as an App Foundation

On a related note regarding the scope of the Admin panel: I actually use the Admin UI to develop customer facing apps.

It would be highly valuable to host the Admin UI (or an extension of it) on a separate route or app directory specifically for client-facing purposes. This flexibility would allow us to use context-specific layouts tailored to end users, such as replacing the default Table View with a responsive Card View, or hiding administrative controls like the search and filter bars.

E.g.

[vitalijalbu]

@thinkscape-gmbh how did u customized the admin like that? new components from scrach or just overrided theming of payload?
thanks

[AlphaMoonbaseBerlin]

One thing that I am missing a lot in the adminUI are different ways to view the data that are not a pure table view.
It would be great if there would be a selection of some already existing views that are easy to configure like cards (with images), calendar (idealy to be configureable for month, week, day and agenda) and a map.
This would help a lot in more non-website-cms workloads like event-management, POS, Inventory etc. which is something directus is extremly qualified for, but is missing out on that front without custom development.

( All info in here in dummydata and not real people.)

[notflip]

A Calendar view like this would make my year.

[V-iktor]

Being able to set opening hours inside a calendar view would be great.

Assume it would be tricky to support all edge cases though.

[fkkehlet]

Just chiming in with another suggestion, resize handles especially on the live preview window would be greatly appreciated!

[vitalijalbu]

use please react-aria, don't use any radix libs... or at least baseui, please!

[paulpopus]

Out of scope for this initial release, it's easier said than done as we have some extremely complex components. But yes this is something I'd like to do

[luochuanyuewu]

Out of scope for this initial release, it's easier said than done as we have some extremely complex components. But yes this is something I'd like to do

That's so exciting! But I'm curious, which one are you most likely to choose in the end: react-aria or baseUI?

[notflip]

BaseUI would be amazing.

[NotTimTam]

The most crucial element for me is that the components that make up the new admin dashboard are well documented and accessible. When building custom views on payload, I don't want to build the UI from scratch, most of the time, I can accomplish what I need to using your building blocks. And it's nice to have buttons, tabs, etc that look just like the rest of the Payload interface.

Excited!

[paulpopus]

Hey everyone, we're well through the UI updates and we're excited to get it into your hands!

Now is also a great time to highlight any parts of the UI you are struggling to customise or override. Nav is a common one (whole nav vs nav contents) and parts of the document controls but please let us know if there's more missing.

[paulpopus]

@notflip we're still planning this but we will add grid view and then the ability to extend for additional views so plugins can be made for kanbans and any other custom view

[notflip]

@paulpopus Thank you, one other thing that's very important (my clients keep tripping about this), is the media picker. There should be a way to show this as a grid, instead of the default view (with tiny thumbnails).

[swheeler7]

I have tried out the canary and think it looks great, i'm really excited for v4! One area that I was hoping would get more love in v4 is the table used in the join field. It would be really nice if it could have the same features that the main list views used elsewhere in the app get. Things like adding filters and searching. Re-ordering via drag/drop is nice, but with longer lists it's tough to use since we can't use drag/drop across different pages. Having the ability to change the pagination limit in the ui, like we can with the main list views, would help this somewhat. I used directus before payload and while I think payload is miles better than directus at this point, the way that directus handled join fields was really convenient. Also I ran into two bugs related to the join field. Havent opened any issues for these since I know things are changing fast in the canary but happy to create issues if you want me to.

1. If I click the edit button to edit a row in the join table, then close that drawer, and then click the "Add new" button to create a new related document, it opens the edit document drawer for the previously edited row instead of the create document drawer
2. If I click the edit button to edit a row in the join table, then close that drawer, then click the edit button to edit that row again, no drawer opens. I need to click the edit button on another row first.

[philip-programador-web]

Thanks Paul, ill reply here with the issue i mentioned in discord:

1. header component(actual header component in which is the breadcrumbs and account profile picture, not the one rendering above it) cant be replaced or at least hidden(i know team said in a comment that it is very important to import correct context data, but i think a official api toggle to just hide it like opacity 0 and fixed top -100% should do, for now workarounds that i dont know if i have to change every new updates).

2. navbar: payloadcms documentation says it its fully replaceable but they dont say that what you actually do is to replace the content inside the sidebar, the sidebar wrapper is still there, while it isnt an issue per se, what its an issue is that:

• theres no option to handle officially when the sidebar closes, which screen sizes, etc

• theres no official option to handle the animation open-close behavior, right now its clunky doesnt have easy in, out well implemented.

• and theres no option to hide it at all and replace it with an actual new sidebar component, just to replace the content inside of it.

3. the created at documentation control banner that its always there on all edit collection/global views, its the only piece that cant be replaceable or hide official, it just shows the created at info, also the edit button that doesnt do anything pushes content and design layouts from being fully original designs

those issues can be fixed with css custom, but thats the thing, theres no official way to change css things just use BEM classes style and scss file to do that and inspect browser, which is prone to breaking changes in new versions.

same with drawers, dropdown menus, etc.

everything else payloadcms is awesome, but this is a big issue for custom designs dashboards.

[damnsamn]

I've not looked into this in much depth yet, but we've been discussing a lot recently that it would be good to have some control over block selection for the blocks field. Select/dropdown UI, categorisation (grouping) - those sorts of things.

I imagine we could do that now by replacing the field component wholesale, but more granular options here would be great. First party block grouping would be sick as

[PP-Tom]

When it comes to folders and tags when I've been using canary, it's really good for finding assets, but when you actually want to use them it doesn't become as useful as unless you know how to use the filter system (which can be overwhelming for some clients).

It would be good if there was a sidebar in the media select or someway of using the same UI to select tags or folders. I believe this would improve the UX.

[tim-at-erdee]

One way to improve this could be a "pocket" feature.
The user uses the folders, tags and filters for finding media. Each item has a button to add it to the top of the pocket.
Then, the media select only shows the items in the users pocket sorted by the time it was added.

Even with this, I agree the select could use a little improvement.