Good Dynamics 365 form design is the difference between a system people use and a system people avoid. I have walked into plenty of projects where the technology was fine, the data model was sensible, and the users still hated it because the main form looked like a tax return.
The fix is rarely clever. It comes down to being ruthless about what goes on the form and where it sits. Here is how I approach it.
Start with the job, not the table
The usual mistake is designing a form around the table. Someone says the Account needs these 60 fields, so all 60 go on the form. Nobody asks what the person looking at it is actually trying to do.
Sit with two or three real users and watch them for an hour. Note what they look at first, what they type, and what they scroll past every single time. That list is your form. Everything else is a candidate for a different tab, a different view, or the bin.
Cut the number of fields on the main form
Every field you add costs something. It costs load time, it costs attention, and it costs a decision about whether to fill it in. A form with 80 fields gets half of them filled with rubbish or left empty.
My rule of thumb is that the first screen should carry roughly 10 to 15 fields. If a field is only needed by one team once a quarter, it does not belong up there. Put it further down or on a separate form for that team.
Ask who owns each field
If you cannot name a person who reads the data in a field, you probably do not need it. I have removed dozens of fields from live systems and not one person ever came back to ask where they went. Be brave about it.
Use tabs and sections properly
Tabs are there to stop people scrolling forever. Put the things users need constantly on the first tab, and group the rest by purpose, such as billing, history or technical details. Name them in plain English, not in the language of your data model.
Sections inside a tab should hold fields that belong together. Two columns usually reads better than three, and a clear section heading saves people hunting. Keep related lookups next to each other so users are not jumping around the screen.
Hide what is not relevant
Show and hide logic is worth the effort. If a customer is an individual, hide the company fields. If a case is closed, you do not need the escalation section taking up room. I normally do this with business rules first, and I only reach for script when I must. My post on business rules versus JavaScript explains where that line sits.
Speed is part of the design
A beautiful form that takes eight seconds to open is a bad form. Users will not complain about it politely. They will just stop opening records, and then your data goes stale.
The usual suspects are too many fields, too many subgrids, embedded Power BI tiles and a pile of onLoad scripts all firing at once. Microsoft publishes guidance on keeping to a sensible number of controls and tabs, and it is worth following. If your forms are already slow, my guide to Dynamics 365 performance problems will help you find the cause.
Lazy load the heavy stuff
Anything below the fold on a secondary tab can be loaded only when someone opens that tab. Subgrids and charts on a hidden tab do not need to cost you anything until they are needed. Use this heavily on busy forms.
Quick create and the header
The form header is prime real estate and most people waste it. Put the three or four things a user wants at a glance up there, like owner, status and the next action date. They should not need to scroll to know where a record stands.
Quick create forms are the other underused tool. Keep them to the bare minimum needed to make a valid record, usually four to six fields. Users can add the detail later, and you avoid the half completed records that come from forcing everything on day one.
Handle required fields with care
Required fields feel like a good way to get clean data. In practice, forcing people to fill in things they do not know produces junk like a full stop or a dummy phone number. Make a field required only when the process truly cannot move forward without it.
A better approach is to make fields required at a particular stage. A business process flow can ask for the right information at the right moment, which is far more natural. I covered that in my piece on business process flows in Dynamics 365.
Different roles can have different forms
You do not need one form to rule them all. Dynamics lets you assign different main forms to different security roles, so a salesperson sees one layout and a finance user sees another. This is one of the quickest wins for adoption and almost nobody uses it.
Keep the number of forms small though. Three well maintained forms beat ten that drift out of date. Treat every form as something you will have to support for years.
Test with real users before you ship
Put the draft form in front of the people who will use it daily, and ask them to do their actual job on it. Do not explain anything first. Wherever they hesitate, the design needs work.
This costs an afternoon and saves months of grumbling after go live. It also fits neatly with a proper user adoption plan, because people support what they helped shape.
Make it boring and consistent
The best forms I have built are dull. Same tab order across tables, same header pattern, same naming. Once a user learns one form, they should be able to guess how the next one works.
If you want a hand reviewing your Dynamics 365 forms, or you are planning a build and want it done properly first time, take a look at my Dynamics 365 services or just get in touch.
