I’ve been reminding people (some might say ranting) about the fact that people should read Alan Cooper’s classic The Inmates Are Running the Asylum in the context of Salesforce development for a bit, so I figured I’d elaborate on it and look at some of its points in more depth. I’m not going to lie: this is going to be more than one post.

First, the book can be hard to find these days but it now seems to have moved under O’Reilly’s banner which is good because it means it will probably live on. It also probably means you can access it through an online tool at your library. Isn’t the Internet great? If you’re in Toronto this is true, but if you want to borrow a heavily marked up and bookmarked copy get in touch.

The Book’s Central Premise

Cooper and his firm carved out a solid niche in Interaction Design, which is a term that doesn’t get used in the Salesforce ecosystem in my experience. This is a shame because it happens every day and no thinking about it can be potentially disastrous.

Given this history it’s perhaps not surprising that the best way to summarize Cooper’s view in the book in a single sentence would be: “Don’t let programmers design software solutions.” There’s a lot of nuance in between the pages, but that message rings through pretty clearly.

One of Cooper’s favourite examples of the problems letting programmers run the show is the classic confirmation dialog box. If you’ve ever closed a window with a file in it and been asked “You have unsaved changes. Are you sure you want to close?” you’ve seen this kind of behaviour. Cooper’s argument would be “I said I wanted it closed, just close it.” From a product design point of view there are a few possible solutions–the most obvious one being automatically saving the file. (Accidentally save changes you didn’t want to? Undo, and auto-save the previous version.)

Validation Rules are Salesforce’s Confirmation Box

The Salesforce version of the confirmation dialog box is the validation rule. Validation rules are a quick and easy way to throw an error, and they’re typically managed by Admins–they’re don’t require Developer skills. The problem is they’re also incredibly disruptive to workflows–they prevent the person using Salesforce from doing what they want.

There are times when this is a good thing and they’re used to ensure data quality. To this day, I’m a bit shocked that Salesforce doesn’t ship with some basic validations–why are users allowed to enter a birthday in the future? This makes no sense, and it’s a pretty binary example. A less binary example is allowing people to re-open closed opportunities–what if they’re just trying to fix a mistake? There’s solutions in the middle, but you need to figure out what works for your business process.

Too many validation rules though and you just create user frustration. Peoplea are just trying to do their jobs! I worked around this once by essentially creating a bunch of validation rules and posting them at the top of the page: you could save the record, but you couldn’t move the Opportunity forward if there were any errors. I’m not sure it was a perfect solution, but it meant people could do their jobs without being robots and everything was kept up to date.

Quick and easy doesn’t make a tool good. Sledgehammers are fast and have a big impact, but using one to drive a nail is probably a bad idea.

Salesforce is an Operational Tool, Not a Technology Tool

In a Salesforce world, the key is focusing on letting your company’s staff get their jobs done. Perfect data doesn’t help if people don’t want to use the system. Programmers tend to focus on perfect and binary solutions, without regard to how people go about their day to day jobs. This makes sense from a purely technical perspective–why allow errors after all?–but it doesn’t reflect reality.

So, the first thing to remember is that when you’re planning your Salesforce project you need to focus on the workflow and design the solution. This means your business analysts are your key resource–not developers.

This is one of the reasons that when I hire Admins I look for a background that’s included a stint in sales or business development: all the certifications in the world aren’t as valuable as that experience. They’ve lived it, and they can empathize and understand what people need to do everyday. Programmers? They rarely have this background.

So, with that central premise laid out we’ll look next at some of the books finer points–starting with Personas. Next week.