It’s Not What Your Software Does, It’s What People Do With Your Software
Last month I purchased GarageBand for my iPad. I used to be pretty involved in the music industry so I was really interested to see how Apple had translated a music sequencer into an iPad application. The result is really amazing and I had a blast assembling drum tracks, bending guitar strings and playing B3 organs.
But then I gave it to my 7-year old.
In about 15 minutes he had created a song. It had a drum track and some rock guitar and it sounded pretty good. In fact, in his mind it was amazing. He instantly wanted to send it out to grandparents, aunts and uncles and would play it for anyone who would listen. He had discovered the joy of creating music.
Why do I tell you this story? Because often in the software world we get caught up with “feature lists.” Feature lists make it so easy for us to compare our software against our competition. But feature lists don’t ensure outcomes.The iPad version of Garageband would lose in a feature comparison with any other music recording application. It’s missing a ton of basic features that are required for a good music recorder. But none of that matters because it can make a 7-year old feel like a rockstar. The creators of Garageband for iPad didn’t care about what their software could do. They cared about what people could do with their software.
Take a good look at the software you are creating. Are you creating a list of features or are you turning ordinary people into rock stars?
- Can you take a low skilled photographer and make them look great?
- Can you take a small business owner and turn them into a web analytics genius?
- Can you take ordinary people and turn them into documentation superstars?
The features don’t matter. It’s all about the outcomes. What can people do with your software? How does it make them better or happier? Can it turn a 7-year old into a rock star? I know our software can’t – yet, but it is something to which we should all aspire.
Free eBook: 5 Keys to Successful Documentation
Learn how to get better results out of your software documentation:
April 28th, 2011 at 10:15 am
I always like to think of it as the users moving in to the software, and making it their own place. The features set the large structural elements, walls, ceiling, etc. but people really need to re-decorate in order to feel at home (and thus keep returning). Software, in that sense, is similar to a building. If it’s built well, and convenient, then there will be a line-up of people waiting to get in. If not, then they’ll just seek shelter elsewhere.
Paul.
April 28th, 2011 at 12:49 pm
“The features don’t matter. It’s all about the outcomes. What can people do with your software? How does it make them better or happier?”
There’s a serious contradiction here. Either the features matter, or it’s all about the outcomes. Either people are serious photographers, musician or writers, or they’re dilettantes. Having software that makes you feel like you’ve accomplished something, when in fact you haven’t, is like crack cocaine for dilettantes. iMovie, move over.
Photographers used to say, “it’s not the camera, it’s the eye behind the camera that matters.” That was true before cameras started making all kinds of adjustments on your behalf that you didn’t ask for. Now, getting most digital cameras not to shoot at the smallest aperture with the best contrast range requires a PhD. So what we have are snapshots, not photographs. And boy, do we have a lot of them. But do they tell us anything? Or are they just background noise?
Most importantly, making a software user better is generally the exact opposite of making them happier. Happiness is not a goal in creative endeavors, nor should it be. Happiness is arguably not even something you want the people viewing your art to feel. Better — in the sense of better at a craft, better at composition, better at noticing what’s happening around you in the world and finding unique ways to speak to it? That requires time, patience and learning. Hey. When I was seven, my cousin gave me a Minolta SLR that had been through at least one war. Sure, I had no idea how to use it. But if it had done everything for me, with the perfect picture being the ideal result of each shutter snap, in what way would it have made me “better”? I mean, what would I have learned?
April 28th, 2011 at 1:16 pm
@JS But not everyone wants to or can be an expert in all things. My goal in software has always been to help normal people do exceptional things.
April 28th, 2011 at 5:22 pm
It’s clear to me, from the article and subsequent comments, that identifying the user is the first and foremost priority. The experience and the feature set are just the outcomes of an intimate understanding of the target user.
Of course, all of this is easier said than done but the odds of product success seem to hinge upon a clear understanding of the users and their expectations(or the lack thereof).
April 28th, 2011 at 7:26 pm
What you’re describing here applies to a subset of a subset of software – namely, creation-oriented software targeted to beginners and amateurs.
Of course, it’s great to delight the user, to let them create fairly good work by automating a lot of annoying or technical parts of the creation process. Indeed, Apple loves creating apps of this nature: Garageband, Keynote, iPhoto, iWeb, etc. The downside is that everybody’s results start looking the same, as they’re based off of the same templates, the same styles, and the limited set of default parameters that make these creations look good in the first place. In fact, the podcast community routinely uses Garageband samples as theme music and have to make sure no other popular podcast is using the same sample.
Features matter when you either target power users (which, by definition, will look beyond the cookie-cutter automated tools), or when you write software for something other than creation, e.g., RSS reader.
April 28th, 2011 at 8:03 pm
Greg, that seems a noble goal…but how exceptional can something be when anybody can do it? Doing something exceptional, by definition, means learning, training and focusing on things that other people are too lazy to devote their time to. You didn’t learn to write software by taking shortcuts…so which is more elitist? Me saying that people should have to work harder to produce art? Or you saying that normal people are simply incapable of taking the time or effort to learn to do something complicated?
I don’t buy this idea of “can’t”. Offering exceptional abilities to normal people through automation is kind of like suggesting steroids as a way to avoid going to the gym. If people don’t care enough to learn something complicated, is it really a worthwhile application of their time to make a piece of music, or a piece of art? Or of anyone else’s time to look at it or think about it? And if not — it no one’s using it to try and communicate, if it’s just a toy that makes sounds — then isn’t it just a kind of narcissism?
April 29th, 2011 at 9:53 am
@JS Being a student in grad school, and a user of the products discussed, I don’t have time to learn programming, video editing, photoshop skills, or the like. I am a basic consumer with hardly any computer skills. As a result I love the fact there are programs out there that can help me create amazing things in an easy way. For instance I made a DVD with a menu for a friend through an apple program. It looked a lot better than anything I could have done on my own. The DVD menu had music, pictures I put in it, and a nice background and lettering. For people who are busy and unskilled, but want to make professional and quality things, we appreciate companies that have us in mind. I think the success of Apple proves that there is a huge market for people like me. It’s not wrong at all to make programs for the skilled and talented; it’s also not wrong to make programs for those of us who aren’t very tech savvy.
April 29th, 2011 at 10:07 am
@Allen – Thanks for the comment. Features definitely matter for power users but what I am talking about still applies to “power-user” applications. I used to do a lot of training for Logic users (before Apple purchased them) and ultrasound software. Features aren’t a bad thing and you need to have great features to have a great product. But features by themselves aren’t enough. Features need to translate into a workflow that helps the user produce a valuable output.
When training people on the applications I mentioned previously I saw a lot of features that literally no one ever used. The problem was that the developers hadn’t seen the feature all the way through. They had a feature that met a spec but the workflow was so ridiculous that no one ever used the feature in their day to day tasks. Whether the feature is for a high-end user or an amateur it needs to help that user accomplish something.
April 29th, 2011 at 10:08 am
@Ravi – Thanks for the comment. Yes, identifying the target user is definitely key. I think that sitting down with target users and watching how they work is really important as well. By doing that we can identify workflow issues that prevent great features from ever getting used.
May 10th, 2011 at 5:12 pm
Good software provides a useful outcome to the user with a reasonable amount of effort to learn and use it. Great software does that but is also engaging and enjoyable to use–hence the trends toward gamification and consumerization of business software. Users want their business applications to look and behave more like the consumer sites and applications. Great software requires an intimate knowledge of the target user population and a process such as lean/agile that iteratively defines and refines the feature set. Easy in principle–very difficult in practice.
May 16th, 2011 at 12:46 pm
I think some of the people responding with criticism to this article are missing the point. I don’t think anyone is trying to say that features aren’t important. Instead, what is being suggested is that trying to learn anything by reading a long manual is not as effective as having your specific questions answered in an easily understood fashion.
I do agree that there are products out there that attempt to over-simplify certain operations, perhaps to the degree where the freedom to be creative has been compromised.
However, when it comes to DOCUMENTATION, I can’t agree more that when I want to have a specific question answered, most documentation fails to be effective – either because it’s not searchable, or because it describes the intricacies of the product and its technical features, rather than how to use it.
Using the example of an SLR camera from one of the comments, I can remember having so much difficulty learning to properly use my first SLR camera some 40 years ago. I would have benefited so much from documentation that described how to properly deal with specific situations such as:
These are only a couple of instances where documentation about a specific QUESTION would have been more helpful than a manual that simply talks about “features”.
Now, as a software author that has, over the last 30 years, created “task-based” documentation for my products, I see that there is a tool that can help me through that process more effectively.