Systems Deployment for the 99%

Believe it or not, when it comes to personal technology, I’m not in the 1%. Come to think of it, I’m pretty darn sure I’m not in any 1%, but that’s not quite the point. I finally got a new phone after sitting around on my last phone for 2 years – it was ancient. I’m quite pleased with my new phone. My last charge lasted me 41 hours (weekday standard use), and I got 43 hours before that. Last week on Friday, I got 26 hours out of a single charge that included 3 hours of a Google Hangout (video conference on the phone). All in all I think it’s going pretty well. I’m a Motorola guy – I like the build quality, I think Motorola has the best antennas in the industry, and I happen to be a Google everything type of guy making Android work well for me. Basically, I can make calls on my phone, I can drop my phone, and I can use it all day. What I’m not is the guy who complains about a phone not having 2 gigs of RAM, my -ability to custom ROM (completely modify the OS on the phone), and have a 2% better screen quality than the next guy.

When I go out and read the message boards about phones (as I did extensively when I was researching what to buy), the total amount of complaining about fringe functionality shocked me. I mean, is it really more important to have a phone that you can fully customize than one that does not drop calls? Do you really have to have 2 gigs of RAM on a phone that might be 5% faster for it, but you have to charge up every 8 hours? I guess we all have our priorities, but I’m pretty sure that the guys who complain about this stuff are the 1%. Most of us just want to not drop a call, not have to charge our phone every couple hours, and for the rest, if we can do 80 to 90% of every other phone, we’re pretty pleased.

This is the exact same problem when we select new technologies for HR. There are just some people who seem to scream the loudest, and because of that, we happen to pay attention to them. Rather than figuring out exactly what we need to be successful 99% of the time, we’re left chasing the minority exceptions. And because those exceptions are screaming madly at us, we think they become part of the core requirement. When it comes down to decisions about this or that, and whatever tradeoffs we have, we’ve often been led to think that 1% is a bit more important and urgent than it really is.

I’ve actually been an advocate for a while of forgoing the requirements gathering process and just having a set of use cases. What is it exactly that we need to get done, what are the outcomes we need to achieve, and how do we measure that we have achieved them? Sure there are going to be little things in there that need to be considered, but if we have a set of systems that gets us to an outcome instead of a set of requirements, then we can move on and figure out which system provides that outcome in the best way. Often, we’ll realize that of the three systems that achieve the outcome, our next selection criteria is not the field and functional capability, but the user experience that is next in importance. Really, outcomes don’t matter if users don’t use. Then after all is said and done, if there’s still room for negotiation between a couple systems, the nitty gritty details come in, but only after we’ve decided that the system actually gets us to the right end state.

I don’t know about you guys, but my end state goal is to be able to make a call without dropping. As a Verizon / Motorola guy, I have not dropped a call in probably 2 years, and I’m pretty sure I hit more cities and states than most of you. All I’m saying is that I don’t need to chase the stuff that some people think is really cool. My phone is there for a very specific purpose and if I can get that done 100% of the time, then I’m good to go. Isn’t HR technology the same?

One comment

I fully agree with your view on replacing requirement gathering with use cases and would also add that you should combine this with personas so you can understand who you’re designing for.

In addition the use cases need to be rooted in real user research. We use the Design Thinking approach which emphasises observation (and iterative prototyping / testing).

With technology it’s always important to understand the experience and the context. That means understanding what they were doing before using the technology (why they decided to use it) and what they did after as a result.