I Feel Your Pain November 4, 2009
Posted by Chuck Musciano in Leadership, Technology.Tags: Development, Interfaces, Software, Users
add a comment
Users are in a tough position. They’ve evolved to the point where they cannot do their jobs without computers. The systems that they use are becoming more and more sophisticated, with equally sophisticated interfaces. Worst of all, they have little or no control over how those systems are built.
Our users rely on us to build systems that are easy to use, reliable, and consistent. They have no idea how we do this, not do they care. They trust us to take care of the awful details of system design and development to make things that they find useful. Regrettably, I don’t think we on the IT side of the house do as good a job as we could on their behalf.
We often make design decisions that cause users great angst. I’m not talking about sweeping design changes; I’m thinking more about the small, subtle things that can make a big difference in a user’s life. The layout of a screen, the ordering of a menu, the arrangement of a list can dramatically affect the usability of a tool. Poor usability results in unhappy users.
Many times, these kind of decisions get made on the basis of how complicated it can be to implement a better alternative. In short, we reduce development time and expect the user to deal with a less-effective interface. We reduce developer pain at the expense of user pain, and that’s wrong.
I’ve written about this before. One of my biggest peeves in just about every web site on earth is that you cannot enter anything but digits into a credit card number field. The developer will not set the field to “numeric only;” instead, they’ll put some awful text near it that explains that you should not type dashes or spaces in the field. Here’s a big idea: how about you write some code to strip out dashes and spaces, so I can type the number in a way that make sense to me? The developer saved twenty minutes; users spend collective years trying to type things correctly.
There are countless examples of this in every system we use. Time and again, developers and designers make their lives easier by asking users to do a little bit more. The problem is that the development time is incurred once; the user time incurred over and over and over again, for years.
We owe our users better. They trust us to build systems they can use. We need to feel their pain, take it on ourselves, and remove it from their day-to-day lives. Users are the most important part of any system; we need to show that we understand that by building things that respect their time and energy. Show your users some love: build things that put them first.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio126″ only_single=false]
The Happy Path November 2, 2009
Posted by Chuck Musciano in Random Musings.Tags: Software, Technology, Testing, Users
2 comments
In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software. I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.
As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users. Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.
There is a limit, of course. You can’t test forever. The trick is to know what to test, and to test those parts thoroughly.
A co-worker of mine often talks about the “happy path.” The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved. We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.
This results in testing scenarios like this
- User selects an item and adds it to their cart
- User enters billing data
- User enters shipping data
- User clicks “Check Out”
- Transaction is processed
If this works, has the system been tested? Yes. Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”
We need to move off the happy path and wander in the weeds. What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?
It doesn’t take long to test the happy path. It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.
For some reason, I was born off the happy path. Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).
I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.” As much as it annoys developers, people who can break things are crucial to building solid products. Better that we break them instead of a user.
We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build. Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio125″ only_single=false]
Knowing When To Stop October 30, 2009
Posted by Chuck Musciano in Leadership.Tags: Leadership, Management Skills, Project Management, Software, Teams, Users
6 comments
A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets. In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).
The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule. Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice. It turns out it is really hard to know when to stop.
In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment. The moment a developer begins working on the eighty-first percentile of a project, they have gone too far. They need to be pulled off and turned loose on the first percent of the next project. This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone. At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value. They need to let go and move on.
[Note that this is not true for testers. There is no 80/20 rule for testers. They need to test 100% of the 80% that has been built. More on this in another post.]
The problem is that no one knows when they have reached the eighty percent point. Very few projects have a bounded definition that makes it easy to see when enough is enough. Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.
It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec. Seemingly appropriate questions lead people down paths that occupy way too much of their time. Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.
That’s when you need a “sudden interrupter:” someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off-track. They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.
I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about. Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget. If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone. Interrupt them!
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]
Where The Prices Are Insane! July 10, 2009
Posted by Chuck Musciano in Leadership, Technology.Tags: Customer Service, Software, Users
8 comments
It happens four times a year, like clockwork. Just before the end of March, June, September, and December, the phone calls and emails flood in, all promising the same thing: unheard-of pricing on products you absolutely cannot live without. These once-in-a-lifetime prices are only available for a short time, if you act now!
What’s being sold at immense discounts? ShamWow or Snuggis? A Pocket Fisherman or a 12-CD set of the greatest hits from the 70s?
Nope. The big sale is on software. Big software: databases, ERPs, business intelligence platforms, and the like. Even with the fabulous discounts, the prices still run well into six figures, plus implementation costs.
Who buys software like this? Is there a CIO anywhere in the world who will write a check and buy software at the drop of a hat?
Done correctly, big system purchases take a long time. Requirements analysis and market evaluation are tedious but vital to ensure a good fit for your organization. Understanding the deployment costs and timeframe is crucial for success and can takes weeks to figure out. Just reading and negotiating the support and licensing contracts is a major exercise all by itself.
Moreover, as CIOs work to gain the respect of their executive peers, the last thing any of us should be doing is running to the CFO’s office on June 30th, looking for a signature to close a deal before 5 PM. Rushing a deal to save a buck is unprofessional, and any other C-level executive should question our abilities if we behave like that.
That isn’t to say that I don’t appreciate a good deal. But the right way to approach a quarter-end discount is to start working towards it at the beginning of the quarter. Everyone on both sides of the table knows that pricing gets tighter as the quarter and year ends. By doing all the heavy lifting well before that time, we can focus on solid price negotiation without being pressured to short-circuit our diligence when things go down to the wire.
I really appreciate those vendors that come to me well in advance to put together a great deal with plenty of time to spare. Not only does that let me do my job on my side, it also lets me manage the process with my management team, giving them plenty of time to learn about the proposal. When I do go forward with the final pricing at the end of the quarter, there are no surprises to delay the process. By helping my company reach a good decision in a timely fashion, a vendor makes themselves (and my team) look good.
Selling is about relationships and providing solid value over time. Vendors, please leave the high-pressure tactics to late-night TV ads and used car lots, and give your customers time to evaluate and respond to good offers in a timely fashion. We’ll all close on more deals with a lot less stress.
The Effective CIO 