In the old days (a few years ago) we would engage with a customer and they would typically say, ‘I need this kind of application…’ That was usually an indicator that they had identified a problem and had divined a solution. The solution was, of course, a mobile application that did this or that. I’m sure that seems like a good idea, but with the luxury of hindsight it might not fit the bill.
When an enterprise decides it needs a specific mobile application it is usually based on their current knowledge of a given situation and assumptions about how best to fix it fast. There’s nothing wrong with this approach but there is a possible downside. What about the users? What are you doing to make their life easier? How will this impact a field person’s ability to do their job? Will they enjoy using this new application or have you just changed the way drudgery is performed?
One thing that has come to light in the past few years is more focus on the user experience as part of the solution. Gone are the days where you beat a round peg into a square hole regardless of the consequences. One size does not fit all and when you do make a selection, borrowing liberally from the Hippocratic Oath, do no harm.
How would you feel if your company asked you to provide a candid assessment of your current CRM system? Assuming there was no retaliation for your responses would you make statements like ‘It’s a joy to work with.’ ‘I can’t wait to get to work because the system makes it’s so easy to do my job’ or possibly ‘It’s like they read my mind and made a system that works the way I do!’ I might suggest a random drug test if you agree any with these statements.
The truth is that ‘systems’ are usually designed to collect data and provide an output. They are not designed to do things the way a human does and therefore we see a breakdown between user experience and the actual application. Sure that system can crank out reports on any given data element known to man but some poor person had to enter the data in the first place and I doubt euphoria was what they experienced during the input process.
Systems designed around the data rarely work like humans, and now you get to ‘train’ (you should probably read that as brainwash) your employees to do things the way the system requires. I was always amazed when I would visit call centers and observe reps moving so fast that the system would have to catch up. They bounced through so many screens before they got to the real meat of what they were doing that they could easily memorize ‘hit Enter, Ctrl K, Enter, tab twice, Enter, F2, F8, tab 3 times, Enter’ Now I’m ready to input your name…
Are we serious about this stuff?
How is that making anybody’s life easier? What would have happened if the way the application was going to be used and the experience of the user was taken into account in the design and implementation phase? How much time-in-motion could you have saved? Don’t think this is a big deal? Imagine a call center with 770 reps and each one has to do this each time they talk to a customer. Based on typical call volumes you are probably looking at 10 minutes of wasted motion per rep per day. That’s huge when you look at the grand scale of things (in our example, 770 * 10 = 7700 minutes per day = 128 hours per day = 640 hours per 5 day week, or 896 hours per 7 day week!).
On the mobile side it gets worse. A mobile user, by definition, is not sitting at a desk in some cushy, climate controlled office sipping a latte while working on their computer. They are most likely ‘in the trench’ and slugging it out as they go. If you provide a user experience like I mentioned above the impact is far greater. They have lower horsepower devices (smartphone versus desktop computer), they have a less reliable and lower bandwidth connection (cell coverage vs. LAN connection) and most likely they are standing in front of the customer sweating as they try to master this technological beast. I see this every day!
What I’m suggesting is that some – no, a great deal of – consideration must be given to the way an application is going to be used. If you tell me you need a ‘time card application’ that’s a pretty straightforward request. How I execute that design makes it a bit more unpredictable. If I’m an idiot and I just cram all the stuff into a poorly thought out application the users will suffer. If I use a small amount of intelligence (which is usually all I can muster) I can vastly improve the user experience. In my opinion, the way somebody does something is more important in the design phase than what they are doing. Data is data but how I do what I do (regardless of the data elements involved) will drive my experience.
Imagine if some of the same people that write software designed the user interface for your car? How happy would you be with that experience? And just saying ‘it doesn’t suck as bad as some other car’ is no way to go through life. I’m envisioning you driving down the highway at top speed when you want to change lanes. You engage the turn signal with the simple process of turning off the radio, turning it back on, activating your windshield wipers, pulling the parking brake release handle, opening and closing the glove box and then rapidly clicking the turn signal handle to make the light actually flash…I don’t think so.
Tags: Brian Philbin, Business Process, Field Automation, Field Service, Human Centered Mobility, Mobile Apps, Mobile Futures Today, User Interface
