This post is about CRM Developers and end users, remember, it’s not a competition.
“ …pay attention to what users do, not what they say”
— Jakob Nielsen
“ You cannot NOT have a user experience”
— Lou Carbone
Why did Google create 2 separate email programs
I read an interesting article this week on techcrunch which prompted me to write this blog
Why Did Google Decide To Split Inbox From Gmail?
The article is about the new email app created by Google called inbox. I have used inbox and it’s very different from Gmail and this confused a lot of people, why have google created two email apps?
Some people at google looked at how people used email and designed an emailed map with the majority of people in mind. What is interesting about the article is the internal derision of the Inbox app and redesign of the email app. The article has a key section
In response, the head of the Gmail design team made a presentation entitled “You Are Not the User.” If you were not lucky enough to witness the carnage in person you could view its archived version on the internal Google+.
The presentation detailed the reasons behind every decision the design/product team made showing gobs of usability data supporting the decisions to remove advanced features that the overwhelming majority of Gmail users were never using. These features, it was argued, were unnecessarily complicating the user interface when most people just wanted a simple email client.
The top comment to this article is
“You are not the user” should be tattooed on the insides of the eyelids of every techie everywhere.
Why is this important to CRM developers
The question is why is important for a CRM Developer to know they are not the end user. The first point is Developers should heed this quote from Ken Becker
“ The user is NOT a lower life form
— Ken Becker
CRM Developers can have a love/hate relationship with end users. CRM Developers need end users because they are the ones who need the new CRM system the developers have been tasked to work on. End users can make the CRM Developers world difficult by
- Poorly defined requirements
- Not very IT illiterate, making it difficult to explain functionality in CRM/customizations
- Requirements massively out of scope
- Finding bugs with the previous solution/code
- The source of Change requests
The end-user can cause the CRM Developer some headaches, but importantly they are key to providing a great a solution because they are users in the old software and will be the end users in the new CRM solution the CRM developer will be creating. The more effectively you can capture the requirements from the end users the better the solution is going to be.
The point I am trying to make is
A CRM Developer needs to create a customization and functionality to create an effective, easy to use CRM system which offers the end-user the functionality needed to do their job.
or
The CRM Developer needs to collaborate with the end-user, not deliver what he thinks the end-user wants or should want
CRM project/solutions
Two of the common problems which can go wrong in a CRM project
- The solution doesn’t meet the end users requirements
- The solution is not easy to use – BAD User interface (great example of a user interface designed by a programmer, beautifully functional)
If you want to read more reasons a CRM project could go wrong, read my previous article – 13 signs your CRM project is doomed
Both of the reason’s specified above are usually caused by not capturing the requirements of the end users effectively or the developer ignoring the requirements and delivering the customizations the CRM Developer would want to use.
CRM Developers and end user interaction
CRM Developers will interact with the end user either directly gathering requirements or through technical spec/bugs raised
Potential problems which can arise when CRM Developers interact with end users
When creating customizations CRM Developers can make incorrect assumptions on the functionality required
- CRM Developers know and use CRM terminology which can confuse the end-user who is not as CRM literate
- CRM Developers assume users have the same level of knowledge of IT and CRM
- CRM developers forget their gaps in product knowledge/system knowledge/CRM Developer makes incorrect assumptions about requirements and how the functionality should work
- End users may forget/miss parts of the requirements
- When CRM developers see/hear a problem they instantly start thinking about the technical solution but the first goal should
- Customization bias from CRM developers can create customizations driven by the developer rather than the requirement
I shall discuss the above in a little more detail
CRM Developers know and use CRM terminology which can confuse the end user who is not as CRM literate
Microsoft Dynamics CRM uses lots of technical terminology entities, forms, fields, views, records, events, plugins, Business rules, workflows. Microsoft Dynamics CRM also has out of the box data like Accounts, contacts, leads, orders, quotes, products, incidents etc etc, which I will refer to as business terminology
Both the technical terminology and business terminology use terms which end users will have probably come into contact with before, but could mean something different in CRM, this can cause confusion for end users.
It’s difficult for CRM Developers remember the time when they all the terminology in CRM was new to them and because they use CRM every day, talk to other developers in those terms it’s difficult to appreciate how confusing this can be to end users.
I have had numerous discussions with customers discussing how Leads are used in CRM e.g. Unqualified (no verified contact or account data) potential leads. Outside of CRM (and in CRM) leads can be used in lots of different ways and mean different things to different companies.
- Some companies don’t use leads
- Use leads for marketing lists brought
- Leads have account/contact data in
The end users understanding of business terminology can add a layer of confusion to discussions and requirements which can lead to misunderstandings and misleading assumptions.
This is a difficult one to resolve but good CRM developers will have this in mind before any interaction with end users and should be aware this can happen. One of the best tools to help combat this is to show the end-user CRM and it’s functionality as soon as possible, this will help give them a context and a visual reference.
CRM Developers assume users have the same level of knowledge of IT and CRM
I could have put in brackets (thinks everyone should have a high level of IT/CRM knowledge). This point is one of the reasons CRM developers can look down on users abilities. The end goal of a CRM project or writing CRM customizations is to create a better system/process using Microsoft Dynamics CRM and you have to work with the end-user not against them.
I view IT literacy a bit like language skills (e.g. Talking with another language) if you don’t need to communicate in another language then you don’t. End users have the IT skills needed to do their job and if they don’t need to use a computer much then they don’t.
Assumptions are a lazy way to increase the likelihood of a project failure.
CRM developers forget their gaps in product knowledge/system knowledge
The other side of the coin mention in the previous section. CRM developers are prone to assume how things should work, instead of clarifying and asking the end user how the process works. When writing CRM customizations CRM developers will come to lots of forks in the customization where the code has to do update values. Lots of CRM developers have chosen to do what they think the code should do or “what makes sense” but often this can turn out not to be how the customer does things.
When decisions/forks appear in customizations these needs to be clarified with the end-user/business analyst to ensure the correct decision is made. When working with end users it pays to keep in mind
You are not the end-user
When I think about CRM developers making assumptions, for some reason I always think about the end of the ham story
A young woman was preparing a ham dinner. After she cut off the end of the ham, she placed it in a pan for baking.
Her friend asked her,”Why did you cut off the end of the ham”?
And she replied ,“I really don’t know but my mother always did, so I thought you were supposed to.”
Later when talking to her mother she asked her why she cut off the end of the ham before baking it, and her mother replied, “I really don’t know, but that’s the way my mom always did it.”
A few weeks later while visiting her grandmother, the young woman asked, “Grandma, why is it that you cut off the end of a ham before you bake it?”
Her grandmother replied, “Well dear, otherwise it would never fit into my baking pan.”
This story succinctly summarizes the sneaky, creeping consequences of assumptions which can end up having major consequences to actions in the story but functionality/custmomizations in the world of CRM.
End users may forget/miss parts of the requirements
Capturing requirements is a tricky process and there is no way to guarantee you get them all, some of the reasons are
- Different users do things in a different way using different criteria/goals
- End users are not used to writing down their processes and forget things
- Business analyst/CRM Consultants might not ask the correct questions or have access to the right people
This can lead to requirement documents which have some of the requirements missing or some holes. Don’t make assumptions and fill in the holes yourself, but clarify the requirements with the end-user.
When CRM developers see/hear a problem they instantly start thinking about the technical solution but the first goal should
CRM developers often enjoying coding and the process of crafting a customization. Their first instinct when hearing/seeing a technical spec or requirements is to start coding or thinking about the technical solution.
Listen to Master Yoda
It’s good practice to get as much information from the end-user as you can about a requirement before you start thinking about creating any solutions.
Get the design correct (as can be) before you start thinking of solutions
It’s a lot easier to change customizations before they are written than it is once you have already started creating the customization/code, with this in mind, try to make sure you get all the requirements and find any problems before you start developing.
Customization bias from CRM developers can create customizations driven by the developer rather than the requirement
Customizations can sometimes be made to fit CRM developers requirements because
- The developer wants to try out some new functionality/3rd party tool
- The developer is comfortable with one type of customization and will choose that method (e.g. When you have a hammer, everything looks like a nail)
- The developer can bully the user
This section is really about the developer leading the user down the customization the developer wants to write and not the customization best suited to the requirement. CRM development is a collaboration with the end-user to create a system which will help them do their job.
The driver behind this problem is the CRM developer is using personal criteria for choosing the customizations rather than doing what’s best for the end-user/customer.
You are not the end user
You are not end user is something you should keep in your mind when interacting with end users or end-user requirements via technical specs/functionality requirements.
The best CRM solutions and customizations are created collaborating with the end users to create a solution which gives them the functionality needed to effectively do their job. The only way to do this is do capture all their requirements.
There is a great quote from Gerald Weinberg on a great blog post No Matter What They Tell You, It’s a People Problem
“no matter what they tell you, it’s always a people problem.”
The quote was talking about programming problems, but this applies to CRM development. A lot of failed CRM projects fail due to projects not delivering the functionality the customer needs to do their job. Two major sources of problems in turning requirements into Microsoft Dynamics solution
- Not getting the full requirements
- Not turning the requirements into functionality/CRM solution
At the heart of the those two problems are people problems, which can steer the project down the wrong path. Once the code and customizations have been written/created it’s harder, more time-consuming and messier to fix those problems.
The emphasis is on the CRM developer/consultant to try to avoid these problems by realising they are not the end-user, they have different knowledge, skills and you have to manage yourself and the end-user.
pictures
Who are you from here
google techcrunch here
Hosk's Dynamic Blog 