Official Workflow Case Study - Show us your pain!

I admit I haven't read all the messages so far, I hope the obvious glaring omissions in DOTS are covered (can't click on an entity in the Scene view to inspect its components, which is absolutely vital for debugging).

For something minor: The names of some (built-in) fields in the Inspector are pretty long and you just can't see them if the panel is not wide enough. Whenever this happens I reflexively mouse over the visible portion of the text expecting a tooltip to pop up with the entire name and always end up disappointed. I'm aware that some of these do come with lengthy and useful tooltips but for the ones that don't have any could you please consider defaulting to its name when it can't be seen fully?

 

I think it hasn't been mentioned yet but the Console could use a refresh as well.

• Lacks customization e.g. changing line height.
  
• Doesn't have custom logging categories that can be hidden as desired.
  
• Can't filter log messages with regex, strings, etc. There are some annoying but harmless errors popping from time to time... Would be nice if we could at least hide them.
  
• Better rendering of the console, maybe with columns.
• More readable stacktraces with clickable line entries.

 

please make it image based. So tired of selecting ui bounds by mistake

 

That's why I pretty much never use the new Script from add component any more. The other reason is that it doesn't use the same script template as right click -> new C# script.

That means my edited template with boilerplate namespace and style doesn't come in. Two frustrating oddities.

 

What conventions? Not even Unity themselves follow one single convention. It's a lost cause at this point.

 

"Convensions" is just a document someone has to create. If it's official, people will follow the rules written in said document.

 

Not if Unity doesn't lead by example, and they won't because that would break legacy and hardcoded names for stuff.

 

To be fair, 3ds max and maya have similar (terrible) workflows for most things (but not all). That said, I can't count the number of artists I know who finally got fed up and moved to Blender for basic modeling/design work thanks to the tedium maya made them endure for so many years. There are better workflows out there. And I only propose one of them.

Thanks for your input. I'm not sure what "screen swap" feature you're referring to. Your resolution is also much higher than mine (meaning smaller UI panels and more scene view space), and as such, you have plenty of screen space to work with. However, for those with bad eyes (or eyes that are getting bad), tiny text presented in high resolutions is not possible for everyone. With larger and larger panels, you need to start hiding them or condensing them.

Not everyone has good eyes or large screens, and for many, the text needs to be larger (making the panels smaller in terms of the amount of data they can contain). This necessitates the increase in panel size, but also the prominence of important elements over the smaller, less important ones, now needs to be reworked in a carefully-guided attempt to maintain flow at smaller resolutions (and therefore larger text/window sizes).




However, it would be REALLY NICE to have a consistent and fluid experience overall.

Whether it's just inconsistent editor tools or getting in/out of play mode (or quickly seeing what your scene view is doing to your game view), the process is never fluid (even if you've learned to ignore it over the years like most people have). I say it is bad because, by its very design (or lack thereof), it is bad -- and this is simply because there is no consistency (from one task to the next) in workflow.



The mockup above is an improvement (thanks to Workspaces), but the major improvement is that is is designer-centric and takes into account things like Tools, Windows, (per-workspace / per-toolset) Shortcuts, and especially the SceneView (which can instantly be swapped with the game view).

 

When the game is running slow (e.g. while recording with Unity Recorder) holding the frame step option is much slower than simply unpausing. If you hold the step button for even a second or two, the editor might take 40 seconds to play through those frames and will be unresponsive until then, whereas unpausing the game would play those frames in 4-5 seconds. This is true for normal 60fps too I believe.

An easy one: the state of opened and loaded scenes should be saved whenever there is a change. Currently, it is only saved when the editor is closed normally. So if there is a crash or the editor has to be forcibly restarted for any reason, the user's scene setup is lost. Currently this happens often enough to be annoying.

 

Showing and Hiding Editor Windows on a Shortcut like the toolbar in Blender would indeed be really helpful, not only for designers - especially for the Hierarchy and Project View - Right now I have to manually switch between Console and Project View all the time, with the Hierarchy open at all times (which consumes Space) even when using it only once ~every two hours.

To setup things in Unity, there are a lot of Drag&Drop operations needed.
Project - (Asset) -> Scene
Project -> (Asset) -> Project (moving Assets)
Project -> (Asset) -> (C#) Component (in the Inspector to reference an asset)
Project -> (C# File) -> Inspector (to add a new script, especially if two scripts have the same name in different namespaces)
Project -> (Asset) -> Hierarchy
Hierarchy -> (GameObject) -> Inspector (as Reference into a field of a Component)
Hierarchy -> (GameObject) -> Project (to create a Prefab)
Inspector -> (Component) -> other Inspector (as Reference into a field of a Component)
Inspector -> (Component) -> Hierarchy (to move a script to another object without losing values)

Anything missing in this list?

 

I've been necromancing a thread I posted about a year ago, but it was pointed out that it may get better attention over here. So hopefully instead of annoyingly bumping it back to the top of the forum every month or so, I'll see if I can get more input here.

My problem is twofold. One is a workflow issue, the other one seems to be a bug.

1)


If you have a smaller project panel, these breadcrumbs are an absolute nightmare. As you click on things, it will often over your entire selection and all options in the list. It's far more frustrating than having nothing at all.

2)


The bug is that if you have two project panels open, it will show the breadcrumbs on both panels, not just the one that is currently being selected upon.

If I could get a way to disable these popup breadcrumbs to only show the ones on the left hand side (even in truncated form for smaller project panels, I would be very happy. The current behavior is a constant annoyance.

 

Unity has no bugs! (ehrm! *cloth* *cloth*)
Everything's "by design", so even the "bug" must be a feature!




No. But srsly though -- I agree with you.

Sadly, the breadcrumbs thing has never been very handy to me. Unity could toss it entirely and I wouldn't notice.
Why? -- Because for YEARS I thought it was just a simple status bar.
Maybe I'm wrong to expect breadcrumbs to be at the TOP of the window (for navigation purposes) -- not at the bottom.

 

I need to vent and this thread will do, bear with me.

Over the past 8 days, I spent 30% of my time writing a compute based replacement for the terrain renderer.

Spoiler: Because...

Terrain-to-mesh lack of progressive LOD was wrecking Switch's and Xbox One's GPU with micro triangles, and Unity terrain has a high CPU cost that scales linearly with the number of terrains and cameras (the game has a rear mirror), eating over 10‰ of our main thread budget. I replicated Unity terrain using DrawProceduralIndirect and compute shaders to calculate the LODs and perform culling.

Then I spent 70% of my time trying to figure out why my terrain was flickering on Switch. Rewrote nearly all of it over and over. All my theories failed. Burst into joy when I found an error in the size of the indirect buffer. No effect.

I finally found the cause, after I miraculously managed to make a GPU capture of the glitch: it's an Unity bug.

Spoiler: Bug description

Each LOD level has a prepared property block with everything that never changes set in advance, passed to the draw indirect call. Unity was mixing up the instance data buffers between draw calls randomly. I'll work around it by making unique instances of the material and setting the buffers on them instead of the property blocks.

But hey, that's OK, bugs happen. Everyone lost tons of time on stupid bugs.

What is not OK is the sense of dread I feel when I think about reporting this bug. This is a workflow pain.

First off, no matter how much detail I give, no repro project, no service. I'm not a hobbyist, the games we work on are other people's IPs and we cannot just upload them to a 3rd party. Which means I have to set aside even more time to try and repro the bug on a sanitized project.

Secondly, there's a tendency for bugs to be fixed on the latest preview version of Unity and maybe, it will get back ported to other supported versions.

So not only I have have to work extra to get my bug report heard, I'll not benefit of the bug fix until I upgrade to the latest (and likely unstable) version of Unity, which will require even more work because who knows what new and exciting bugs, deprecations and feature removals will come alongside.

Sorry for the rant.

 

I'd say not a problem - yours is a very real and practical problem, and exactly of the kind that Unity rarely, if ever sees in-house because they haven't shipped an actual game yet.

 

And the pain continues: I found no workaround for the bug and now here I go making an idiot-proof repro project to get my case heard since I don't have 1 million bucks handy to pay for source code access.

For anyone interested: Unity keeps using the wrong StructuredBuffers across multiple Graphics.DrawProceduralIndirect or Graphics.DrawMeshInstancedIndirect calls. I found posts about a similar bug from 2016. They obviously forgot to fix it on Nintendo Switch. So if you're planning to rely on modern GPU-based techniques to escape Unity's inefficiencies, be advised it might not work as expected.

 

I recently spent about a month in a conversation with support because I wasn't able to log into my unity account with a google integration from unity. This was so that I could download an asset that I bought.

I told them what I was doing, and the issue I was having, giving them a link to the error that google provided that stated the issue was on their google integration, and they still spent a month of me reinstalling things despite me telling them what the problem was. Finally they gave me a workaround to log in with a different account (apparently we all have 2 accounts, did you know that?). That was good enough for me because I just wanted to download that thing.

Several months later, the unity launcher updated with a fixed google integration supposedly. I haven't had the heart to try it.

Now let's be real here. Working with 3rd party API's can be a pain, but I've done a fair amount of that in another life as a web developer. There is no reason I should have received the push back that I did on that issue when it was pretty clear what the problem was. Imagine how excited I am to put in bug reports of more meaningful issues when that was such a hassle. I am professional game developer, not employed by Unity's QA department. I get that bugs happen, but it needs to feel less like volunteer work in order to contribute on that side of things.

 

I'm a bit late to the party, but I still hope to get some attention from @willgoldstone and/or @superpig.

Script Data Upgrade. A protocol for updating the data in the components when their script is upgraded. It was announced in the forums in 2016 and included a shared document and a custom Unity build.

Despite being a feature that would be incredibly useful for most code development workflows, it looks stalled since 2017.

New layers and static flags system. Back in 2015 you were working on improving this part, and requested feedback on the different possible design choices. The post in the old Beta group includes links to detailed documents on the possible approaches (requires access to the legacy Beta group):

https://groups.google.com/forum/#!msg/unity-beta-testing/HSia-i1Bvag/FBXYwVs8JUMJ

Today in 2020 we still have 32 layers to be shared among all systems in Unity.

 

It made sense that it stalled. It was a very complex feature, and me and several other Unity users told them that if we had the ability to reserialize all scenes and assets, then we would be able to do the same thing with good old [FormerlySerializedAs] and ISerializationCallbackReceiver.

We got that in AssetDatabase.ForceReserializeAssets.

I'm not saying that the script data upgrade thing wouldn't be nice, but the value vs. effort proposition there went straight down the drain for us once ForceReserializeAssets showed up. That being said, we're not very often in situations where assets with changes live on branches for a long time before being merged. If that was the case, things would look different.

I'm not sure, but when I look at a new URP project in 2020.2, the Mesh Renderer has it's own "Rendering Layer Mask", which states in it's tooltip "Mask that can be used with SRP DrawRenderers command to filter renderers outside of the normal layering system", so we might be getting there?

The ideal thing here would be to have rendering components define rendering layers, and physics components define physics layers, and copy those over when upgrading projects. That way you stay kinda backwards compatible, and don't have to break things too hard.

 

How? I'm still struggling with ugly workarounds using these every time I update some script in a non-backwards compatible way requiring data upgrade.

 

Say you've got a field you need to rename from foo to bar. You do this:

Code (csharp):

1. [FormerlySerializedAs("foo")] public int bar;

Then you run AssetDatabase.ForceReserializeAssets on either all scenes and prefabs if it's in a MonoBehaviour, or on all the ScriptableObjects of the matching type if not. Then you delete the [FormerlySerializedAs]. If you've got team members that might be working on that type of file, you instead commit it with [FormerlySerializedAs], wait until you're sure all team members have merged that, then run ForceReserializeAssets and delete.

If you need to do something more complex than field renaming, you use ISerializationCallbackReceiver to modify the data in OnAfterDeserialize/OnBeforeSerialize, then run ForceReserializeAssets.

 

I'm already using FormerlySerializedAs and ISerializationCallbackReceiver. I know about the trivial cases. ForceReserializeAssets doesn't make any difference. Many times you can't do that as the script upgrade is shipped to other's projects. Think on upgrades to Asset Store scripts, or customer's projects where many people work in local copies of the same project and get updates via VCS. You can only expect that the component will be loaded at some point and will be fetched with data (that might be new data or not) immediately.

So when the data needs to be upgraded in a more complex way, say for example:

• From an int to a class that must contain the previous int value.
• The variable name doesn't change but its value must be upgraded in a specific way to work in the new script.

then I how to upgrade that? How do you figure out if the deserialized data has already been updated or not?

 

In that case you'd introduce a version field and do manual versioning by checking the value it has against the latest one.

In those cases - especially around asset store stuff - a proper built-in versioning system would be very convenient. It's possible to handle it manually, but it requires having all of the old data definitions around, which is a pain.

 

Another thing that is rather frustrating for me is that Boo.lang is still floating around in the namespace.

I use a VS extension called IntelliSense Extender that adds a lot of things to my intellisense. For the most part it works splendidly because I don't have to remember which using to import, I start typing and autocomplete, then find the thing I'm looking for. However, if I don't have

using System.Collections.Generic;

already and I try to add a list, this is what pops up:


As you can see, the first couple hits are not the list I'm looking for. Frequently I'm in a hurry and accidentally import Boo.Lang into my project and it takes a while for me to realize why my list isn't working right. Now I know that this is a personal problem, I could do better, it's a fault of IntellisenseExtender, etc etc etc. HOWEVER, Boo has been deprecated for a long time. Can I at least get an option to remove it from my project? Please? The best I've found is to use

[InitializeOnLoad]

and manually pick it out of my Reference Include. That's a real PITA though.

For a while I was just using this snippet

Spoiler

Code (CSharp):

1. using UnityEditor;
2. using SyntaxTree.VisualStudio.Unity.Bridge;
3.  
4. [InitializeOnLoad]
5. public class ReferenceRemovalProjectHook {
6.     static ReferenceRemovalProjectHook () {
7.         const string references = "\r\n    <Reference Include=\"Boo.Lang\" />\r\n    <Reference Include=\"UnityScript.Lang\" />";
8.  
9.         ProjectFilesGenerator.ProjectFileGeneration += (string name, string content) =>
10.             content.Replace (references, "");
11.     }
12. }

Somewhere along the way it broke and I've been ignoring it. I decided to look into it today and it appears the file file got updated and it looks like this now:

That means I gotta write a regex and go through all those hoops just to remove this. And frankly, it feels dirty, prone to breaking, and there's a real fear about unknown consequences of doing that.

For posterity sake, here is a regex that seems to be working:

new Regex(@"\s*(<Reference Include=.(Boo.Lang|UnityScript.Lang).).*\s*.*\s*(<\/Reference>)");

 

Wow, I had no idea they still shipped these! Digging around there's still a

booc.exe

in the install folder of 2019.3.

 

The other thing that would really be a game changer for the console is being able to change the font. It's baffling to me that it isn't and can't be in a monospace font. Even when I'm trying to use it to print out data, the data isn't presented clearly because of that.

 

There's a number of things with editing components in the inspector that are pretty clunky:

I can drag and move components around, but if I don't drop pixel-perfectly on the line between two other components, the action is ignored. I almost always have to try multiple times.

I can 'copy' & 'paste', but not 'cut'?

I really wish I could select multiple components and copy/cut and paste them all in another object. Doing it one by one is quite tedious.

There needs to be a way of distinguishing multiple components of the same type on an object. A user-customizable name on all components would be awesome. But a simpler solution for custom components might be a 'GetComponentName()' method on MonoBehaviours, which when it exists, is called by the inspector to set the title. This would also be great to show when components are referenced from others.

 

I saw that 'cut' is on the roadmap so thats coming

 

Yeah. This is annoying. Same for dragging in the Hierarchy, where it's an art to not drag something into another GO.

And I agree that we should be able to distinguish from components with the same name when adding components. Showing the file location or namespace as a pop-over would be useful. The Kinematic Character Controller comes with a walkthrough showing different ways of doing things. This is what I see when i try to add one of those components manually...



Which one is the one I'm after? The only way to be sure is to drag the script from the Project window instead.

 

This video shows a nice way of working that I really miss in unity.

It has a fullscreen workflow, and the prefabs are shown in a nice grid pallette, with bright preview thumbnails.

This way you can layout levels like a painter does, you have your pallete and the tools are context sensitive

 

Basically you're saying:





And yeah, I think there should be a grid palette that should let you grab prefabs freely.

However, I think the direct "icon-to-brush" thing is a bit over-used.
All the prefab icons should be able to dropdown a sub-menu to show you prefab variants (i.e. you click TreeMaple, a dropdown with all variations of the TreeMaple should appear to let you select from, giving you the source of your final "brush" -- i.e. presets for the canopy, material, trunk, and whatever other prefab variants you've created).

 

Not sure if this has been mentioned or not, but I'd love to be able to create multiple prefabs at once with drag and drop game object to project folder.

 

@Antony-Blackett +1 on this. Would be a huge time saver for asset makers.

Some suggestions of my own:

1. As someone making extensive VFX packs on the store, I hope you'll bring back multi particle editing in the Project folder. If not, please let me drop my prefabs into the scene and edit multiple of them in the Hierarchy and click "Apply Changes to Prefab(s)" like it was back in ~2017.4. This would save me thousands of clicks.
   
   
2. Would be great having a better save/load function in the Gradient Editor and have expandable folders or categories for different projects. Maybe it could be useful saving gradient libraries in the project folder as well.
   
   For those that have big libraries, changing the size/width of the gradient presets would be nice too.

 

@willgoldstone
Thank you for this thread.


I have a pain point with the editor and the extremely narrow pixel range to select the vertical scroll bar. I feel like I have 5 pixels worth of space to select it before accidentally selecting somethign else. Video to show what I mean

Is anyone else experiencing this?
I'm on Unity 2019.3.14f1

 

Great to hear things are moving in the direction of improved workflow, thanks for that

There are a couple things that I have as high priority.

1. I would love an other view almost the same as the project view but with only references to the project items, That I can sort all I want, without affecting how its stored on the disk. with Smart folders etc.

2. The ability to adjust the preview window for objects, right now they are almost all the time too dark. ( change the background to user color and the lighting )



3. Fullscreen in Play-mode. ( no overlays nothing just a fullscreen window )

 

I'm hoping you're looking more at "Smart Prefabs" rather than just "Smart Folders".

Depends on what you're going for.

For example, if you're _really_ looking at doing "Smart Folders" in a "Smart" way, I would seriously focus on the badass "Variants" concept of prefabs (to reduce the number of visible options to users at any moment). This gets in the way with most large projects with a huge number of assets (variants of rocks/trees etc.), and it in no way is "fun" to work with.

Try something like this instead:



This would put the currently-selected option as the icon to "click" and reopen it to whatever "page" the selected option is currently on. Ideally, this would only show actual "variants" of the prefab, and encourage a "variant-based" workflow in the editor overall -- which is A LOT more compatible with a DOTS-only (read: data-driven) project workflow going forward.

Hopefully this would be rolled-into a nice "grouping" option to let users make collections of different assets (preferably automatically -- i.e. if you have a naming convention, use that convention to automatically "group" many prefabs / assets / parts into named collections instantly, perhaps with a tiny popup letting you name the collection.)



Also, ideally, you should be able to right-click and instantly remove an asset/prefab from ALL collections (and delete any collections that have 0 entries during the asset removal process to "clean-up" your project as you go -- this "removal from collection" process can quickly get out of hand when adding/removing assets from many collections at once -- _especially_ when doing this in bulk, such as when purchasing from the asset store and removing huge parts of it upon importing into your project). A "Remove from all Collections" feature is something Blender doesn't have in its collections menu (but is something that it sorely needs, assuming the goal of assets is to get them into a scene/level as quickly and as frictionlessly as possible, which includes searching/sorting/adding/removing from different dependencies on the asset's data, which should be part of the whole purpose of a "Smart Folder" anyway -- in my opinion).


One more thing -- expanding on the grid-based variant idea above, have you thought about doing some sort of grid-based thing like this in the Project view (to further consolidate space)? (See middle "Project" dropdown near "Drag/Drop from here"):



The idea is to give a small-ish grid of prefab icons that you can mouseover and see more detail (like with a magnifier window outside the box or near the mouse cursor, showing name, higher-res icon) when a folder is full of prefabs and variants). The prefabs would be displayed in a similar manner as the previous concept (albeit with smaller thumbnails), but the click menu would popup as normal to display the variants just like the above-most concept.

Granted, folders should be able to do other things (based on what kinds of assets they contain), but finding prefabs (and their variants) in a compact, extremely visual way should definitely be considered a MAJOR part of the Unity workflow -- especially for designers.

Remember:



So as many of the extraneous panels as possible need to be removed/consolidated (i.e. into compact or context-sensitive versions).

Prefabs are a great place to start, since they're essentially like a "DOTS-object", and they should be treated as such. They're just data, and you can do ANYTHING with them, including "drill-downs" of data. However, above all-else, they should still be tucked-away in discreet "dots" (for lack of a 'better' term?) until they are needed, since your project is likely to contain A LOT of these "dots" of data. They need to be represented a LOT better visually, and as such, they need both a compact and expanded form.

Just my two-cents. Take it or leave it.

 

^ Yes floating pallets would be good to have

And I like to see the thumbnails with better visibility, they are too dark right now for most of my prefabs

Current too dark colors;



Suggested fix:

 

Couldn't agree more. You can use your keyboard to go directly to a letter but if you're looking for something that is somewhere in a sub category of a sub category, you can spend five minutes in this.

These UX shouldn't exist anymore and should have a search function like we have to add component in the inspector.

 

@willgoldstone @gabrielw_unity

I made another video for resizing frames. It's inaccurate basically. If I select from below I can't resize, if I select from above, I can .

- Windows 7 64bit
- Unity 2019.3.14f1

 

I have definitely also run into that. It's little things like this that can drive you batty over time.

 

I have several things that would make using he inspector easier for me.
1. Sticky the header of a component to the top that is being cut off when scrolling down. Imo, it adds nice context to what you are looking at, even more so for large components like the Cinemachine Camera. Did a quick mock-up. (I actually tried to do it in editor, but even with reflection it is not possible )


2. Make expanding/collapsing components per GameObject, instead of global. Maybe a shortcut(like holding shift) or context menu item to expand/collapse globally.

3. Add buttons to expand/collapse all components on the object. I know that there is the menu option for it. But I honestly always forget that they are there, and when I do, it just feels inconvenient to me.

4. Add a bar at the top that would have a list of all the components. Maybe their icons, or maybe as a drop down. That you could click, and instantly scroll to, and expand that component. Maybe option to collapse all other components.

5. Not quite as sure if this one is needed if you have the others. But a search bar stuck to the top for searching for a component.

I think these would make navigating and using the inspector quicker, and easier.

 

I like that cartoon outline and bright BG for most "drag/drop" cases, but sometimes you have white/bright elements (i.e. UI / UX controls, clouds, white/gray level elements, etc.) and you need to see them too. Your "white" elements are well-textured, but lowpoly-styled or cartoon-styled assets might not be as clear. A dark BG actually helps in this case.

As a potential alternative:


@Unity:

When generating icons/thumbs:

Unity should generate a temporary HISTOGRAM alongside the default icon (to later check a Grayscale Version of the Thumbnail with the default gray). If necessary, perhaps in a second-pass when viewing the asset for the first time, or when the application is idle, so it may check the brightness of the center-most area of a generated thumbnail against the default gray background (edges of the thumbnail), then, if necessary (i.e. a user selects a high/low brightness range or color gradient), Unity automatically selects a more appropriate shade of gray for the subject in the center of the icon (i.e. using three shades, minimum -- one as default thumbnail bg color). This happens when the brightness levels are too low/high across the image using the default (initially-selected) gray (i.e. when there's not enough _contrast_). A secondary background "color" selection would be made according to the histogram/grayscale version of the original thumbnail generation as a second-pass only if that first thumbnail fails to reach the levels of contrast in the histogram (specified by the user in the editor preferences).

When doing this, the user would have no issues with icon generation (especially if you open the API up to developers who are making tools), nor would they need to have a special outline/shader that must be used when generating the icons either (but a custom shader for bright/dark images might actually still be a great option in user preferences BTW, if it's not too complex).

 

Good point, I would like to see control over the thumbnails in preferenes

set the background color
set the light intensity
set the rotation angle

 

Hy, just jumping by to share some small QoL features that I think could make workflow better. That's all of my opinion, nothing to take too seriously if you don't agree with it! It's in another thread that no one seems to have read hehe https://forum.unity.com/threads/qua...anges-that-could-help-on-common-tasks.851998/

 

Small feature request:

Allow us to set a Shader/Material for Gizmos.DrawMesh. Right now you can only draw gizmo meshes with the default gizmo material.

 

I have been looking for a keyboard shortcut to open the context menu (mouse right click) in the project view or hierarchy view. The windows native context menu key does not do the trick. I cannot find anything in the shortcuts manager. Google and forum search did not deliver, but that might be me... anyone figured this out?

 

@willgoldstone can you have a look at this stream, https://www.twitch.tv/videos/658912102 (i dont know him, just watched the stream today)
i think it highlights many issues that users bump into. (specifically he's testing new XR system, docs, URP, and many other general UX/learning unity related things too)

 

This might have been mentioned already but there is alphabetical sorting all over the place with no alternatives available. Three examples immediately come to mind:

1. Search results in the hierarchy window. 9 times out of 10 I would prefer to see them in the order that they appear in the hierarchy, top to bottom.
2. Search results in the project window.
   
3. Assets in the project view are sorted alphabetically. Often, I would much rather see them sorted (and thus grouped) by their type.

Simple additions that would dramatically improve my workflow!