I was so proud of this first object as well as the data it supported. The chart was a winner. All was going so well until we walked through creating a donation record.
“So, we will have to choose the program every time?”
“If an individual makes multiple donations at one time, you mean we have to create a new record for each?”
“Why doesn’t the donation date default to today?”
“There are too many things to fill out. Our volunteers will not be able to do this.”
“How do we select the right account or household?”
“This is too much work!”
Well, that hurt. Undaunted, I facilitated quite a few discussions on this topic, even getting back to anonymous donors.
I am going to cheat a little bit and present things out of order for the sake of brevity. It was at this point that I should have pulled in the volunteer coordinator. That was a big mistake. Instead, we created a second object, discussed later, to allow for multiple donation entries on one screen. Whether we will eventually use it is questionable at this point, for one simple reason.
You Can Lead a Horse to Water …
The volunteer coordinator knows her volunteers. She knows the turnover. She knows the chaos in receiving, the training, the capabilities, the breaking points. After several intense discussions, it was clear that there was simply no way the volunteers would be able to interact with a computer in the heat of battle. No negotiations.
This was a surprise to all of us. We never even thought to ask the question. This was all about automation, right? Nope. It’s about data. We need the data, and we need to get it into the system in the simplest possible manner. Those of us who live and breathe technology have a deep disdain for paper and writing implements. But that’s a very narrow viewpoint.
At this point, the plan is to keep the existing log sheet, and attempt to coax the volunteers into at least looking up a donor by phone number, and if it is not there, kindly requesting at minimum a name, phone number and email address so that we can have some method to identify and communicate with the individual.
The log will then be processed by other volunteers, away from the chaos, and these volunteers can input the data into Salesforce. Yes, it is double entry, but perhaps the most efficient process.
This was a very important and hard lesson. The capabilities of the volunteers must be factored into any decision very early in the process. We haven’t made that mistake again – it is a topic that comes up regularly in design discussions.
Consolidating Data Entry
Whether or not we decide to use a “multiple donations on one screen” approach, there is still lots to share that may be very applicable in other settings.
Let’s go back to an earlier and important design consideration: in order to keep license costs down, we are focusing on a role-based design which limits any volunteer’s exposure to no more than five or six objects. This keeps us a good distance from the maximum of ten and that leaves a lot of room for growth in the future.
The role that will be using these objects is “Receiving.” To that end, we created a new receiving profile and an app that only exposes the account and contact tabs. The receiving object does not need its own tab because it is a transitory object – it only exists to create the individual donation records. The donation object doesn’t need its own tab either because the receiving volunteers will only need the related list on the household (account).
Even though the tabs are not showing, the receiving profile must have access to the receiving and donations objects as well as any objects associated with these two.
The goal of the transient receiving object is reducing keystrokes. In the event a donor has multiple transactions during the same visit it is (in theory) much easier to create one record, fill in the appropriate data, and have Salesforce turn this into three donation records.
Why did I add “in theory?” Before reading on take a good look at this form. What is your first impression?
Now I consider myself pretty decent at designing a good user experience. But now that I really take a look at this form, knowing all of the automation behind it – and understanding how much data can be “created” with just a few clicks – I am no longer enamored with my work.
There are two obvious reasons for this:
- It is way too busy
- It will only save time when there are multiple donations
So how did this monster form get created? The developer side of me got out of control and I completely lost my UX mind.
To save face, there really are some cool things here that might be useful in certain situations. I will share those with you in the next couple of posts.