IT Employment

Develop applications that empower users

Kathy Sierra's recent presentation on user empowerment reminds Justin James that developers need to consider how an application will make their users better.

The Business of Software 2012 conference opened with Kathy Sierra giving a really good talk about user empowerment. Her basic premise was simple: Users do not use your application for the sake of using your application -- they use it because it benefits them in some way. This should seem obvious, but it is easy for developers to forget. We get hung up on details that do not help to achieve this goal all the time, whether it be a massive argument over inter architectural decisions or adding new features without any validation they are needed.

I have become increasingly aware that code is a commodity. Yes, it is a tough commodity to get at a high level of quality, but we are at a point where most applications are not that difficult to assemble to a "minimum viable product" (MVP) standard. Sure, taking it from MVP to be totally tweaked and able to dominate the market is often a long, hard road. But if you look around, tons of applications were not spectacular when they started their ascendency to the top. The original iPhone was not terribly good, but it was the first smartphone to really be useful and usable for average people. Android 2.0 that shipped on the Motorola Droid was not very good in my experience, but it did the job well enough to compete with the iPhone of the era. Windows 3.1 and Office 4.3? Check and check. Visual Basic 3.0? Don't get me started.

It is clear that a technically unsound product can create a market; in fact, some of those technically unsound products come to dominate existing markets and defeat existing incumbents. How does this happen? It happens because technical considerations are almost never at the top of the stack in decision making. Kathy's speech really highlighted this for me: Users really only care about what makes them better. When cell phones first become somewhat affordable in the mid '90s, they were not very good, but people bought them because having a cell phone that was not very good was a lot better than not having one at all, and it expanded your ability to work. All of those hours that were previously wasted on driving or otherwise being out of the office suddenly became productive hours. The smartphone has done the same thing.

As developers, we need to learn to take a step back and ask ourselves, how does this make our users better? Does it improve their lives? Does this give them something to show off to their friends? Does this help them do their jobs better? If the answer is "no," then the next question has to be "why are we doing it?"

This is not to discount the value of things like sound application architecture, but these things need to be done within the context of "how does this make our users better?" Gold plating features and internal improvements without validating how they help you with your real end goals is a waste of time. I have been there. For example, I've been in numerous arguments about whether a method should return null or throw an exception in certain circumstances. Did it make our users better? Not at all. Even the technical differences didn't matter in the long run.

As developers, we need to start learning to be ruthless about making our users better. Again, the code itself is a commodity. If we do not do it, our competitors will, and we will find ourselves losing users and market share to them even if we have technical superiority.

If you have the time, you should read the summary of Kathy's talk when it gets posted on the Business of Software blog.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

7 comments
Yangtze
Yangtze

You're both missing the underlying point of the blog. You have to understand what the user is trying to accomplish before you decide what tools to use. You don't build a house without blueprints. And you don't just select the first set of blueprints off the shelf and tell the buyer THIS is what we're building. Even subdivisions give the buyer a choice of floor plans. By deciding the tools before knowing the project just leads to trouble.

HAL 9000
HAL 9000

That a App that is Platform Independent and maybe not the greatest could be more widely adopted and developed just like all the previous software that won the race. Remember Word? It was terrible by itself and was a Nonstarter to business. It wasn't until it was incorporated into Office that it became the default standard. It was never in the class of Word Perfect and even today WP is much better than word but which one is actually used? Of course if the Big Boys with the Big Selling Apps made their product Platform Independent they would be setting the standard which everyone else had to follow. ;) Though above I was assuming that the Developer who was making the App would have already done their Homework and decided that people would actually need what it is that they where developing. Though saying that some of the biggest selling software ever built was built just for the person developing it to use and do a specific job and it took off from there. Col

Sterling chip Camden
Sterling chip Camden

... then I think you're putting words in my mouth. Re: Col's comment -- I think platform independence will become more important, especialy now that we have three viable mobile platforms, but it is crucial that we let users decide how important that is to them.

Yangtze
Yangtze

that your comment emphasized tech over requirements.

Sterling chip Camden
Sterling chip Camden

I was only trying to balance what I thought might be construed as "don't worry about technology" by making the point that technology is one of the factors that can affect your ability to deliver on requirements.

HAL 9000
HAL 9000 like.author.displayName 1 Like

Is making their Apps Cross Platform so that their users are no longer forced to use a Single Platform. That way the customers can move from one platform to another and keep their existing Apps or at the very least continue using the same app without any need to learn anything new. That is where I see the current generation of the Less than Perfects App winning. Col

Sterling chip Camden
Sterling chip Camden

and I miss her blog "Creating Passionate Users." I agree with your point, but I also think it's important to acquire the right tools when those tools help you to do a better job of making your users successful. That is, if they help you deliver faster, or with better quality, or with more features, etc. That means that you might adopt a language like Haskell, not because it's what the cool kids use, but because it actually helps you create a better experience for your users.

Editor's Picks