Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 12 other subscribers

Dynamics 365 Adoption Model

/Dynamics 365 Adoption Model
CRM user adoption

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.

User Adoption Issue

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“.

 

 

What Inhibits Adoption

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.

Dynamics 365 Adoption Model

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.

Three Key Areas in Dynamics 365

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.

Example Scenario

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!

By | 2017-02-10T10:58:19+00:00 February 10th, 2017|D365, Dynamics 365, Dynamics CRM, User Experence|
  • Pingback: Dynamics 365 Adoption Model - Microsoft Dynamics CRM Community()

  • Ryan Maclean

    I’ve found this in a lot of places. In my current job I inherited a MS CRM system that was previously designed by a team of technical consultants to replace a set of Access databases, and they did exactly what you described – went for a like-for-like replacement, with no thought as to the usability of the system.

    I also find that a lot of CRM/D365 consultants are quick to resort to custom coding, rather than using OOTB functionality – a quick glance at the CRM Forum will show you what I mean. Inevitably, as the system is updated the code breaks, and leads to errors. I personally try and implement no-code solutions wherever possible, which can sometimes take a bit more time, but has the benefit of being much easier to maintain and support going forward.

    It is still a struggle with user adoption to get people to realise they don’t need to maintain separate spreadsheets, and to have trust in the system (though why they trust an unsecured spreadsheet with no version control, over a secure, auditable database like CRM is still a mystery to me!)

    • Thanks Ryan, I totally get what you mean with Access DBs. Seen it many times. The big thing I am trying to say is we need to start more with how people will interact with what we build than just a feature list.