Image Source: “User Adoption is Key”, by Geek and Poke

In any Dynamics 365 project that you implement, if the solution you've constructed is not adopted by the individuals in that organization, fundamentally, the project is a failure. The customer still might be happy, but if after some time the system is not being used and people have started using other software, this means the project has not really been that successful, and user adoption hasn't been achieved.

Over the years, I've seen commonalities wherein user adoption fails. This is because the consultants involved in the project haven't looked at it from a lens of it being adopted. They've looked at it more from a lens of meeting the list of requirements.

Formal change management is out of the scope of what I will cover in this post.

One issue we have in the industry is a lot of consultants are very technical. They are—at their core—technologists. They understand how to take the Lego blocks of Dynamics 365 and put them together. However, they don't usually assemble them in a way that creates a fantastic piece of art–something that looks good on screen and that is logical to follow. For example, if a form needs to capture five fields, they'd just lay five fields out in a column. There's no consideration of whether that's going to create scrolling, or whether the default fields need to be removed because they're irrelevant, etc.

There should be a check that every Form, Dashboard, and View are validated against: is it functional, is it usable, is it intuitive, is it designed in such a way that “Don't Make Me Think”. Often, I find these tests are never done. It's always around “does it capture the requested field of data“, and not “is it the best way to capture information“.

There is a range of things that do inhibit adoption.

• Devices: Forms, Dashboards, and Views are designed focusing on the web experience and are not validated against mobile experience.

• Role Changes: The Dynamics scenario is built around a specific role type and that role changes or is replaced.

• Business Innovation: You design for a certain scenario and the cost of building that. All of a sudden, the business process changes.

• Software Updates: Microsoft constantly introduces new things. What happens when you're part way through a build and decide to update the environment?

It's important to ensure checks were run on a new feature enhancement or functionality because ultimately, the system is being designed for end-users or people that will need to use this solution.

Personally, I do not not like the word “User”. I think it causes us to forget we are designing for PEOPLE.

The diagram shows that oftentimes, we start at what the customer was wanting to do or what we are building. We focus on tasks, products, features, objectives, and functional things that need to be put in there. Then we ask, is it reliable, and is it usable. Then we get to that middle mark. Is it convenient, super easy to use and works as expected? This is the model that should be used around designing any type of interface or functionality into the platform. Unfortunately, that is where most people stop.

We need to move beyond that then move up and ask “is it pleasurable“? Is it an experience worth sharing and meaningful? Does it have personal significance? In other words, does it make one more productive? Does it enhance the way one works daily? Does it impact parts of the organization? Going up, it moves away from tasks to focus on the experience.

The left side of the diagram aims to create a solution that is Valued by the people using it. Features are rated as highly usable and frequently used. And then stories told about how Dynamics has supported a greater customer interaction.

I often see that Dynamics 365 is brought in to replace an old system, and the focus is on that task area rather than creating that meaningful experience. I see requirements for a like-for-likeness replacement. It's a massive failure in implementation of new Dynamics 365 systems because a customer gets the same thing… just with a nicer interface. They should be getting so much more when Dynamics 365 is implemented as Microsoft intended.

With Dynamics 365, I see three key areas that people interact with at any time:

• Dashboards

• Views

• Forms

Oftentimes, I see consultants take these three areas, aiming to check a tick box of meeting a requirement. They don't care to some degree how bad that interface ends up looking or if there is data all over the place, there's no grouping of relevant information, there are required fields buried deep down on the form, and there's no real understanding of how an individual is going to use this on a daily basis and what type of experience they are creating for the users.

When people, that will use the solutions be built on Dynamics 365 are not visualized and designed for, we fail our customers and stakeholders.

We were working with one customer that had a website with 30 web forms requiring different pieces of information that customers could fill in. Their old back-end system was not integrated with their website which forded the data that people provided in the web forms and emailed that to the support team who then copied and pasted out of the email into the application that they had at that time.

When I challenged my team, “why are we not changing that”. (The process still had the email sent from the website, and someone else still needed to key it into Dynamics 365). I said, hang on guys, you're taking a requirement, but you're not actually addressing and making it a more meaningful and pleasurable experience. You need to really take that structured data that was keyed into the website forms and then inject that directly into Dynamics, therefore eliminating the need for the email which “dumbs down” the data, makes it less intelligent and less valuable for those wanting to use it.

I will be posting more on this topic as I drill into the details of user interface and user experience in the coming weeks.

Let me know what you think in the comments below.

Thank you!