Usability Issues: Quick Start

There are two kinds of users. Those who want to understand how the darn thing works up front before they start playing with the application and those who expect to start the darn work as soon as possible.

For the latter vendors prepare sometimes something like a quick start scenario. Some predefined settings which allow avoiding long and dull configuration process. Computer games are a great example. Very often you can choose to set every detail of your character/team/environment by yourself or you can choose among one of predefined sets.

There are great examples in different areas too. Our financial and accounting application has test database installed by default. People can check how it works on test data without affecting production database.

Of course quick starts aren’t applicable in every application – usually they are useful whenever some pre-configuration must be made by the user. However this kind of approach you can find even in Internet Explorer with predefined list of favorites.

Whole usability issues series.

Easy versus Hard

It’s easy to criticize others work.
It’s hard to be fair yet critical when it comes to judging own work.

It’s easy to point others failures.
It’s hard to admit own failure.

It’s easy to over-interpret others points in discussion.
It’s hard to say sorry when you go too far with your judgments.

It’s easy to work from this point to that point.
It’s hard to look always for a broader perspective.

It’s easy to become angry when things go wrong.
It’s hard to overcome angriness and look for constructive solutions when things go wrong.

It’s easy to look for excuses.
It’s hard to look for solutions.

It’s easy to say.
It’s hard to do.

It’s easy to say “no.”
It’s hard to look for a compromise.

Just a reminder. Mainly for myself.

Usability Issues: Tab Order

Open your application. Start hitting Tab on your keyboard. Look where focus goes. Is order intuitive or random? Are all controls accessible?

Try to fill in form in your application. Go through edit boxes, check boxes and radio buttons with Tab. Can you get to another control you are expected to fill with one Tab press? Each time?

Setting correct tab order is a small, yet dull, development task. You don’t gain much completing the task. On the other hand you lose much if you reject to set the tab order properly. Your users get frustrated with the product. User experience peaks down. Everyone starts using competitor’s software. Your company bankrupts... OK, I went too far with that one. However that’s another small thing usability is built from.

Whole usability issues series.

Setting Wrong Rules

The other day I wrote about setting rules and things which usually need to be done to have new arrangements working. However you’ll see some of your Great Ideas which you’ve implemented in the work environment don’t look as great as they appeared at the beginning.

What to do? Run in panic? No, not so clever. Pretend it’s all OK? Well, at least that way you don’t admit you’ve failed, but I wouldn’t say it’s worth to add everyone another dull task just to show you aren’t so great as you’d like to be. Change the rule? Oh yes, of course!

If something doesn’t work in your house you either fix it or throw it away. Why shouldn’t you do the same with processes in your work? Don’t force people to do unnecessary work or they’ll force you to look for replacements. It’s a fair deal, isn’t it?

And no, your reputation among team won’t be harmed. Quite the opposite.

Software Tools: Purchase versus Development

Few days ago Ray White with his post about buying versus building software components reminded me my very first post on the blog which touched the same subject.

Over a couple of years I’d add one more thing to the discussion. Remember what your core business is. Sometimes you can judge building software just for yourself basing on functional comparison and cost analysis. However before making a decision go deeper.

Think if that would bring your company forward? How much effort you’ll need to maintain that piece of software. How many projects you won’t be able to handle because of building software tools inside. What’s the alternative cost?

I think over time I evolve more into “leave it to professionals” kind of approach. What is yours?

Usability Issues: Nice Enough

Make your application looking nice. I don’t say every app has to be shiny and polished like Vista, but make it looking good enough for your users. If you write for system administrators then console should be enough. But if you do anything more, even when your UI can look ugly don't make it sloppy. Controls set straight. Buttons placed intuitively on each window. Toolbars don’t changing their appearance randomly. All controls and options accessible with keyboard.

You get much with little effort.

Whole usability issues series.

Change Your Estimates Now!

You’ve heard that probably.

“Your projects are usually late. Do something about that. We lose credibility in the eyes of our customers.”

Ouch.

“And another thing. Last schedules you’ve prepared are unacceptable. They should be cut at least by a half.”

And now you’re confused.

“Sure, feel free to cut deadlines by 50% and yes, this time we’ll deliver on time.”

Except of that’s not true.

To be honest I always feel uneasy when I have to deal with those kinds of situations. Yes, I understand so called business perspective. I actually can imagine that a couple of months of schedule can be unacceptable for a customer. I know that easier or more appropriate solution from the technical perspective can be rather not suitable business-wise. However at the end of the day you need to deliver. Hopefully something within scope, time and budget.

There is no easy answer how project manager can discuss those accusations. Several things can help however.

1. Make your estimates as reliable as you can. Create something what you believe can be achieved. It’ll be easier to discuss that later on.

2. Look for a compromise. A couple of man-months of development can be covered differently with different resources. You need different buffers for a newbie than for a veteran member of the team.

3. Remember about your environment. Estimates shouldn’t be done for veterans when you don’t have any in your team. If you have a number of other projects to do don’t consider there are none.

4. Be assertive. When something isn’t reasonable, point it. When something can’t be done, explain why your team isn’t capable of doing that. Describe what needs to be done if you are expected to achieve that goal. More experienced team? Some training maybe?

5. Talk about merits. Don’t start “it is so because I say so” type of discussion. It’s a dead-end. Think. Were past estimates good? Where you made mistakes? Why? Is that similar situation in any way?

6. Admit where you failed. Don’t try to play the hero because most likely you’re not. Most likely at least several of your estimates were wrong. Don’t try to hide that. Try to name reasons why it happened so. If it don’t help with the current discussion at least you look more credible with that.

And remember one thing: it isn’t a win-lose only scenario. You can end with win-win or lose-lose too. The former should be your goal.

Setting Rules

Now you’re a manager and you have some power. Now you’ll show them. You’ll set up The Rule.

Of course we all know The Rule is reasonable and will be an improvement. You do it because you believe it’ll help, not just to show you have the power.

You announce The Rule to all interested parties and that day you go to bed with great feeling. You did something. Everything will be better now.

Then Mr. Reality comes to kick you in the ass. No one cares about The Rule. Everyone works exactly the same as before. Don’t they see it would all be better if they obeyed?

Most likely they don’t. At least not all of them. Not everyone will be convinced by your words, they expect to see results. And they won’t see results unless they start to obey The Rule. We have a deadlock here.

The thing you need to do is to check regularly how people deal with The Rule. Remind them they should do what they are asked for. Tell them once again why The Rule was invited. Hopefully after several iterations everyone will treat it as a natural part of their workplace and you’ll no longer need to think about that.

Usability Issues: Most Frequent Used Means Most Important

Which features are the most important? For salespeople newest ones. For marketing your application differentiators. For developers those which bring interesting problems to solve. Unfortunately usually none of them actually eat their own dog food. And for users the most important features are those which are used the most frequently.

If you need or want to work on usability focus on those functions. It can be search and time you need to wait to see first results (first 10, not all 16,9 million of matching results). It can be filing an invoice for simple invoicing application (what a surprise). It can be writing or test formatting for word processor. You name it. It’s your software.

Checks how accessible are those features. Measure how fast they response. Verify if they are easy to use. Think how intuitive for a new user they’ll be. Focus only on features which are used the most often. When you have no ideas how to improve them move to next, a bit less frequently used.

Whole usability issues series.