In the first two parts of this article series we’ve explored both the history of the Dynamics CRM platform as well as the impact of the mobile computing era. But what about the general design principles that apply to customizing the familiar CRM web application? How have these evolved over the years? That’s exactly what we’re about to find out in part 3.
Traditional CRM Systems
Going back to the early days of CRM 3.0, this is an example of what a customized XRM environment might have looked like. Although later versions like CRM 2011 introduced more presentation options, they still built on top of the same navigation paradigm and default layout. Forms were indeed very form-like, typically consisting of a two column list of fields broken into sections. Additionally you had form tabs to group the fields together, but later in CRM 2011 these transformed into anchors as the form became one long, scrolling page instead of actual tabbed presentation.
While the form fields and layouts were mostly a boring but working way of presenting information about the record in question, the relationships to the related child entities posed a bigger problem. The left side menus of both the main window’s sitemap as well as the form window’s related records menu had a tendency of “exploding“ with a large number of new entities, making the user interface appear somewhat hostile to a user who was not familiar with the purpose of each of these records. The icing on the cake was that every other click seemed to open up a new popup window, stealing your focus and resulting in a growing number of browser windows to manage.
This underlines a characteristic of the Dynamics CRM platform during it’s first chapter: you really had to know where to look for the information you were interested in. You stood the best chances in achieving this goal if you were tech-minded enough to understand how relational database applications in general worked and were able to picture the data model of the CRM or XRM application in your head while navigating in it.
(5) The hierarchical nature of the user interface meant that you were basically always looking at a single entity at a time, either on a record detail form or in a view of several records. (6) The system didn’t offer much ways to summarize data across entities, which meant that the more normalized your data model was, the more effort it required from the end user to collect the information to help them understand the big picture. Essentially CRM was a system optimized for data entry and storage, but not for data presentation. It was not a very efficient system for sharing information between users, unless all of them knew where to go to look for the data entry made by another user, and when.
A Modern CRM System
Here’s an example of the very same XRM concept re-implemented and redesigned in a CRM 2013 environment. I’m sure most of you have already seen at least glimpses of the new user interface and read about some of the new features included, so I’m not going to do a detailed “what’s new” review of CRM 2013 now. Instead I’ll approach the subject from a higher level and talk about the paradigm shift that has taken place.
There used to be a clear distinction between a list view and a record view in the CRM application, which was emphasized by always keeping them in their separate browser windows. (1) With the elimination of most of the popup windows in CRM 2013, the lines between these areas have now blurred, although from a customization perspective the different configuration points remain intact. The end user will, however, encounter a much more “flat” application that doesn’t try to constantly remind the user about the different levels of hierarchy between the UI components and the records presented. With the new global Navigation Bar, you can get to almost any screen of the application from anywhere.
Another aspect that works to reduce the hierarchical nature of CRM is that we now have a set of features available that allow combining information from several different source entities onto a single form. (2) The first method was introduced already in CRM 2011 when subgrids made it possible to show data from child entities on the parent entity form – such as a list of contacts working for the account currently being viewed. CRM 2013 has now expanded this capability into the other direction, meaning that you can also pull a set of fields from any entity that has a parental relationship to the current entity, using a feature called Quick View Forms. The out-of-the-box example for this would be to show details of the primary contact on the account form.
In addition to these generic platform capabilities, there is now a specific control available for showing the related activities of the record in a form element called the Social Pane. (3) The presentation of the activity data shown here allows the user to expand the details of that record to review information such as the email body text. Additionally the creation of new tasks and phone calls can be done inline on the form. What’s even more important is the prominent display of the activity feeds for each record, as this makes it possible for a system customizer to provide an automatically generated stream of the latest events that a user viewing the record should be aware of.
Putting all of these changes and new features together means that we should no longer treat the entity forms as simply a storage space for its attributes, or a tool for data entry. Instead they can be perceived as dashboards which collect all the relevant data from around the record. That data is presented to the user in a format that aims to deliver a quick overview of the most important information, regardless of the physical storage location of the data. The updated default forms contained in the CRM 2013 application version have been designed with a brand new layout that highlights this new purpose, with a widescreen layout consisting of three primary columns in the top tab of the form. Starting from the left you will always find the key attributes of the record itself, followed by the latest activities or feed posts describing what’s been going on around this record recently. On the right side column we then see a selection of related entity data that a user accessing that entity is most likely to be interested in.
When upgrading to CRM 2013 or designing brand new solutions, you are not forced to follow the same design principles in the form layout. It is however very advisable to try and adapt your solution design into this new model, because essentially this is how a Dynamics CRM based business application will be expected to function from now on.
CRM Is Not a GUI for Database Tables
This brings us to a very important topic that I see as a common pitfall which has caused challenges with Dynamics CRM implementation and development projects in the past. The customization of CRM has traditionally been very much focused on configuring and extending the data model. Adding attributes, creating new custom entities and defining the 1:N, N:1 or N:N relationships between them. Sometimes it may have seemed that the Dynamics CRM platform would essentially be a graphical user interface for creating and managing database tables, but in my opinion this is a completely wrong way to approach CRM.
Now, it might be a bit too unorthodox to say that you should not spend so much time planning your data model when implementing Dynamics CRM, so I’ll rather say that in addition to the data modeling work you should reserve more time for planning the overall end user experience of the application. It shouldn’t be something that “just happens” as a result of how you’ve defined the structure of your business data in the application.
Back in the old days when CRM was much more limited in terms of the user interface configuration options, it was quite typical that there was a bunch of new entities and relationships added into environment and then the work was considered completed. The UI presentation of these data structures wasn’t always considered a separate design task, partially because of the tight connection between the entity structure and the user interface generated from it. Now with CRM 2013, the amount of configuration options related to the presentation layer is becoming so extensive that it’s not necessarily obvious at all how a specific set of data should be made visible in the UI. This is why it requires much more design work than in the past, if you truly want it to leverage the capabilities of the latest CRM platform version.
Having said that, CRM is still very much a product that has a set of built-in features and these features support a few possible alternatives of how to implement a particular business requirement. Trying to decouple the data and presentation layers from one another will quickly land you in a territory where custom code is needed to meet the requirements. It is therefore important to approach the solution design work from a perspective that keeps both the data and the presentation layers well within sight at all times, to ensure that you don’t end up choosing a path that will take you too far into either one area, causing problems and dead ends later in the design process when bumping into the limitations of the application.
Levels of CRM Solution Design
The high level model of how I approach these design questions is split into the three levels presented in the graph. Of course the planning work should start from the business process level that’s not shown here, but for the purpose of our discussion, I’ve decided not to cover the process angle in this diagram.
The data model, as mentioned, is too often seen as both the start and the end of the solution design when it comes to Dynamics CRM. But what should come after it then?
Data presentation is what a large share of Dynamics CRM configuration points deal with, such as views, form layouts, charts and so on. You can already accomplish a much more user friendly solution by spending more time on thinking about the optimal way to present your data, instead of just adding fields as requested. This is a game of inclusion, exclusion and priorities, though. There’s very little limits on how much data you can physically store in the CRM database, but there are both hard limits on how much you can technically show on the application screen, as well as softer limits of how the end users can discover and absorb information from the system. Depending on how you structure you record forms, how you sort and filter your views and how you choose to compile your dashboards, the data in the CRM system can appear to the users as either invaluable or irrelevant. So, please be careful when thinking about this part of the solution.
Going even further than the presentation layer, the final level of user interaction design means taking all of the choices you’ve made on the previous layers and putting them into action. This level is about how a user will step through a detailed chain of events, what he or she will give as an input to the system and finally how the resulting output from the system will meet the expectations of the user. For example, you could choose a common task that a CRM system user will perform, such as the process of adding a new contact record, and then analyze how much friction is encountered during this process – which actually might stop the user from successfully completing the goal if things really go wrong.
Traditionally there has been fairly little attention paid to the user interaction layer in a typical CRM implementation project. One of the reasons is that the cost of altering the standard behavior of the CRM application has been perceived too high, due to the amount of custom development work required. However, in a platform like Dynamics CRM 2013 there is now actually a number of configuration options and tools built in to the product that allow you to alter the flow of user interaction and to help reduce friction in the common processes. I’d say that if you’re not looking into the possibilities of optimizing your CRM system on the user interaction level then you’re actually throwing money away by not making the most out of the software licenses you have paid for.
CRM 2013 Considerations for User Interaction Design
Coming down from the high level discussion, here are a few practical pointers that I’d encourage you to pay attention to when designing a solution for CRM 2013.
1) The new top Navigation Bar in CRM 2013 is both a blessing and a curse. It’s far less intimidating than the traditional, long menus in the main application window. However, in any organization that has a large number of custom entities in use, you’re likely to encounter usability issues if you don’t properly arrange the entity menus in the Nav Bar. If you previously didn’t edit the CRM Sitemap that defines this menu structure, now’s the time to start thinking about it.
2) The left side menus are not only gone from the main application window – they’ve also been removed from the record detail windows. Accessing related child records is now most easily accomplished if you have placed them in a subgrid on the parent entity form, so please make use of them.
3) The Quick View Forms open up great new opportunities to mash up data from a number of different entities. Explore their capabilities and play around with the subgrid option here especially.
4) The Quick Create form is a very convenient feature for streamlining the data entry process. To make sure that it doesn’t lead into problems with missing data, don’t forget to customize and test these new form types, too.
5) While the Ribbon is gone from CRM 2013, its actions still remain mostly available. Similar to the Nav Bar, you’re much more likely to need a few optimizations done to the new Command Bar, so that your users can locate the most important commands easily.
6) Finally, the most visually impressive feature of CRM 2013 has to be the new Business Process Flow control, available on the top of entity forms like the opportunity, for example, to show the stages of the process. Before you rush out into applying it, be sure to map out your real business processes and data requirements, then simulate them with the BPF control and see if they actually make sense while presented there. Leave room for proper trial and error here, because you’ll probably need it in order to achieve a final working solution.
Continue to the next article: Dynamics CRM Platform Evolution, Part 4: Delivering Responsive Solutions
