The blogging spirit definitely has not returned for a long time. I’ve been busy.
There is probably a post or two in me regarding Agile or company culture. Maybe I’ll let those out.
In the meantime, if you’re kicking around here, you are likely more interested in my work than my blog, so…
One set of design challenges when working on enterprise products is the number of different people and roles involved. Many designers and product managers are familiar with the buyer vs. user split where the people using the product aren’t the same as those making the purchase decision.
Product teams have historically given more weight to the buyers and their opinions, requirements, etc. This is for good reason – if the buyer doesn’t buy, your product goes nowhere. Catering exclusively to the buyer usually results in a lousy product that sits on the shelf or is despised. With ever more SaaS products that are sold on a subscription basis, ignoring the end user will result in poor adoption and renewal rates.
Anyone practicing user-centered design knows the importance of studying and working with the people doing the actual work. So, why is it so hard to get access to these people?
While I was working on an enterprise file sharing product, I realized it wasn’t just a simple case of finding the right person to interview. Many of our contacts were IT staff either administrating or evaluating our product. I had many good meetings with these folks, but my frequent requests to meet with our product’s end users often went nowhere.
One day, an IT contact’s comment finally provided the insight to why I wasn’t getting past IT. IT departments are responsible for evaluating, purchasing, and maintaining their company’s systems. So, IT is also responsible for understanding their company’s employees’ needs. Asking to interview the users was either being interpreted as redundant or, worse, insulting!
Getting through these gatekeepers is challenging and requires persuasion and persistence. There are a few approaches to try:
Share your experiences in the comments.
You think your data is backed up, but it’s not.
Okay, maybe it is right now, but will it be there when you need it? Will it be there when you realize you need it?
A while ago, realizing I was doing a poor job of maintaining a home computer backup, I signed up for an online backup service. Once the initial backup was complete, wow, did I feel better – I had one less stressor to nag me.
After several months of magical backup, something started to go wrong. Unfortunately, it wasn’t a disastrous, sudden crash. Unfortunate, because if I had lost everything one day, I would have simply restored the data and continued along just as one would expect to do with a backup. However, whatever it was sneaked up on me. I think the first sign I remember was iTunes losing track of certain files – apps or podcasts or music. I attributed it to other causes besides a drive failure… I had relocated the iTunes library to that drive and figured iTunes was simply confused. I ignored the continuing glitches for a while until I realized I was missing photos.
Well, no problem, I thought. I logged into the backup service, selected the folders I wanted restored, and confidently sat back and waited for the two large .zip files to download over my pitiful DSL connection. Problem solved, emergency dealt with, I set the work of actually restoring the files on the back burner. Life is busy, and I’d deal with this later.
After a week or two, I got back to the mundane task of restoring the files. I had requested two sets of backed up files but, searching my computer, could not find the second .zip file. I checked the backup site for the file, but it had expired and was no longer available. That sinking feeling began it’s downward journey. I attempted to restore the file set again, but the files were not listed. “Oh shit,” I thought.
In user experience, we speak about the mental models people build in their heads to explain how the world works. Sometimes, in the case simple physical systems for example, these models are accurate. For more complicated systems, such as the computer or device on which you’re reading this post, the model may be abstract but still accurate enough to explain cause and effect and predict how things will work. Other times, the model is just wrong, and that leads to mistakes, which can multiply as we misunderstand why the system isn’t working as expected.
Our mental models are constructed from our past experiences, experience with the system we are modeling (the “learning curve” could be called “mental model construction”), and other indirect sources of information such as documentations, friends’ or colleagues’ advice, etc. Until this point of the story, my mental model for online backups was based on my experience with my local backups. Once you backed something up, it was backed up until I decided to delete or overwrite the backup file. Pretty simple. My backup service even offered “unlimited data backup”, further reinforcing my mental model. If it was “unlimited”, then the backup file would never be deleted. Right? Wrong.
My “oh shit” moment was the realization that my mental model was completely wrong. Not only was it wrong but, man, was I an idiot for having constructed it. Me! A software engineer for many years should have known how this stuff works.
These backup services do not store unlimited data forever. They store an unlimited amount of data and keep “previous” file versions for 4 weeks. That means, if you delete a file, you have 4 weeks to restore it before it’s gone forever. That means, if you remove an external drive from the backed up computer the backup service will assume deletion and dump the files after 4 weeks (as a friend discovered). This also applies to files that disappear silently due to a slowly failing hard drive. Your data is not protected from such non-disastrous failures or from your own procrastination.
Is this a surprise to you? Review your backup provider’s web site and tell me if your mental model is correct.
My story does have a happy ending. I contacted the backup service’s tech support and they were able to recover the .zip file since it had been scheduled for deletion but not actually deleted. That was pure luck and I’m happy to have learned my lesson without earning the scars.
Jay Zipursky 