The Big Pink Button (Enlightened Software Development)

SoftwareIf you develop software, you’ve probably been frustrated from interacting with “them”. You know who I mean – those pesky end-users ; the consumers of your product. You’ve probably thought (more than once I’m sure) that these users are either:


a: nuts
b: dumb
c: dumb nuts

While I’ve seen my share of nut jobs, what I’ve found, more often than not is that when I find myself thinking like this, it’s because I’m trying to see the user’s perspective through my software developer glasses.

Here’s the deal: Most users aren’t dumb – they just don’t understand software development. What you’ll probably find is that most users are good at what they do, and they’re just trying to get the most out of your application by telling you how to make your tool better in the best way they can. Oops, I said it. I called your beautiful, shiny, gift-from-god application a tool. A user simply wants to use your tool to get their job done quicker and with less effort.

Think of power tools for a moment – do the engineers at De-Walt know more about building houses or fine furniture than the customers who use their tools? ‘Course not. At the same time, a craftsman could not build a better power tool than an engineer; to produce a truly great product it takes the involvement of both parties. When it comes to software, users often understand the business case for using your tool better than you do. When they see an area for improvement, they express their desires as best they can, but they’re speaking a different language than you are.

What does this have to do with “The Big Pink Button”? Well, software development parallels the power tool analogy more closely than you might realize, and it results in something I refer to as “The Big Pink Button”. The scenario goes something like this: You gather requirements and user input (you actually do this right?) design, develop, test (you do this also, right?) and then release your software to the user community. You are so proud of your accomplishment – all that optimized database code, the slick new UI widgets that you’ve incorporated, and all that clever stuff most users never notice and really don’t care about. Your tool is shiny, it’s sharp, and it’s ready to rip!


You start to receive feedback from people actually using the tool, excuse me – your software, and darn it if those people don’t ask for the craziest things! For example: “I want a big pink button right in the middle of the scree than when clicked does…”. You think – big pink button? In the middle of the screen? It does what? You’re crazy. Next!

These software requests come in many flavors, and you’ve probably seen one or more of their variants.

Here’s a few – do you recognize any?

  • If you only had xyz feature in your software, everyone would buy it! (If you’ve spent any time in software development, you’ve heard this HUNDREDS of times.)
  • I can’t believe not everyone needs XYZ in the software! (I’ve heard this hundreds of times as well.)
  • The software is useless without XYZ! (fortunately, I’ve not heard this as much as the others, but it happens.)

Of course, you can’t give the user “The Big Pink Button”. It doesn’t adhere to proper UI standards and not every user would want the button or the function it provides. Plus, it’s pink. So what do you do?

Great software design requires listening…

What you need to do is think about what the user is really asking for. I know, they asked for “The Big Pink Button”, right? Not so much. What the user is telling you is there is something missing in your software, or there is an impediment to the user’s work flow. Keep in mind, the user is good at what they do, not at designing software. Your job is to interpret their request into something that makes sense from a software architecture standpoint.

OK, the user wants the button big and pink. Why? Well, they’re indicating the importance of this new feature, and they are saying they want the new feature to be obvious to users and easily accessible. Your job is to decipher the request and act accordingly. I’m not saying every request has merit (well, actually all requests from users have some merit, even the nutty ones) or that you should automatically implement all suggestions in your software (triage is a topic for another article).

I’m saying you need to figure out what the user needs, which is often different from what the user asks for. This is something that takes experience, but experience can be hastened by the simple act of realizing that users aren’t idiot – they’re simply trying to explain to you what they need in order to get the most from your software. The best software developers and designers do this instinctively, but if you don’t find this an easy thing to do, here are some steps to get you going:

  1. Understand what the user is trying to accomplish. (user perspective)
  2. Understand why the user needs to accomplish this task. (user perspective)
  3. Determine where in the work flow this feature needs to be present. (user perspective)
  4. Determine what the feature would do in the software (developer perspective)
  5. Determine what the UI would look like (developer perspective)
  6. Decide if it makes sense from a business standpoint to add this feature to your software (business perspective)
  7. If it makes sense, the request goes into the queue for prioritization, etc. (business perspective)

As you can see, interpreting user requests requires a number of hats. You need to be able to understand the request from the user’s perspective, then interpret the request using a developer’s perspective, and then evaluate the feasibility from a business perspective. Also, I’m not saying you need to write a requirements doc or feature spec for every request; you ought to be able to do most of this in your head. If you can’t, you need to work on this; it’s an important skill you need to master if you want to be a successful software developer.

Great developers create great software, but only by listening and interpreting the requests of their users (and request from great users are golden!). You’ll never be perfect at this, but you can get good at it and when you do, your value to your team and your organization will go up immensely, and so will the quality and desirability of your software!

Remember, even though it might sound like gibberish, your user is trying to tell you something – learn how to listen!

I welcome your thoughts on this topic, as it’s one that’s near and dear to my heart. At Tigerpaw Software, we work hard at this – really hard. Sometimes we miss the boat, other times we nail it on the head. Sometimes I mix my metaphors. :) In the end, if your users aren’t happy, you’re screwed. Keep that in mind.





Powered by Facebook Comments