One of my main responsibilities as a Technical Lead at Magnetism is to make sure that we deliver a quality system to our clients. When you buy a brand-new car, you wouldn’t be happy if there was even the tiniest scratch on it, so why would you settle for a brand-new system that is cluttered, confusing, or slow to use?
Anyone can customize and configure a Dynamics 365 system, but it’s easy to overlook things that can really make a difference. In this article, I will share some of the items that are in our checklists to make sure that the client is getting a system that is easy to use, intuitive, performant, and allows them to do their jobs better than ever before.
Rule number 1 – the system must do what it was designed to do. Let’s move on.
We’re building on top of the Dynamics 365 platform, so we’re mostly restricted to its user interface. But there are some little things that can be done to really improve user adoption and create an intuitive system.
Create a Theme that matches the client’s branding and upload a high-quality logo to sit in the top bar and in the App. Make sure you have icons for all custom entities.
The more things there are on the screen, the harder it is to find the right thing to click. Here are a few things we look out for. There are many more in our checklists.
1. Hide unnecessary entities by removing them from the SiteMap and removing security permissions from those entities.
2. Hide out-of-the-box Dashboards by removing Security Roles from them.
3. Hide buttons on the Command Bar that you don’t want users to press. This is best done by changing security permissions, otherwise you can hide buttons using Ribbon Workbench.
4. Hide unnecessary views by deactivating them.
5. Remove fields that you don’t need on forms.
6. Tidy up the Related section on forms so only the entities you need are there. Remove any duplicates and place them in a logical order, e.g. alphabetically.
A system that is self-explanatory is easy to use. Here are two things you can do to help users understand the system better. There are many more in our checklists.
1. Add a Description to fields so it shows up when the user hovers over the label on a form.
2. If extending your system with custom Command Bar buttons, consider using a confirmation prompt. For example, when a user deactivates a record, Dynamics 365 will ask you to confirm the deactivation. You should follow the same principles in your custom development.
Anything that requires a name in Dynamics 365 should be set properly. Use the right name and plural name for entities, use the right name for fields, charts, dashboards, forms, views, reports, etc. Make sure the spelling and casing is correct too and consider adopting naming conventions so there is consistency. If a client sees a spelling mistake, they will wonder what other corners you’ve cut when building their system.
Users spend the most time on forms and views. For forms:
1. Consider how the user is going to interact with the form. Where should the most important fields be? What can be removed from the form? Do you need sub-grids, or will the Related section be enough?
2. Use multiple tabs so there’s not too much vertical scrolling.
3. Fields shouldn’t span the entire width of the form. Separate out into sections.
1. Have consistency across views. For views with similar columns, make sure they’re in the same order and have the same column widths.
2. Remove unnecessary columns from views. For example, “My Active Contacts” shouldn’t show the Status field.
3. Set the correct column widths based on the data that is held in the column.
The system needs to be fast. There’s nothing worse than waiting for something to complete with no indication if anything is happening. If you have client-side or server-side custom logic running, make sure it completes quickly and doesn’t hold up the user interface. Consider using progress indicators where possible.
A lot of what I’ve described is what you see on the front-end, but it’s equally important to ensure that quality is at the front of your mind when doing back-end work. We follow strict naming conventions for fields which follow Microsoft’s standards. The schema names of our lookup fields end with id, and the schema names of our option set fields end with code. Why? We believe that if you strive for quality for the things users don’t see, you’ll also strive for quality for the things they do see.
What I have described above is just a few things that we do to ensure a quality system is delivered to our clients. There are many other things to consider, but this should be enough to get you thinking. Spend the time, declutter the system, make it intuitive, be consistent.