Be sure to check out the original post to see the entire inspirational list.

It’s clear that having an understanding of tasks and the underlying business objectives is essential to designing useful software. However, we rarely take into account another factor: the real goals of the end user.

Understanding user goals

On the surface it seems that the end user’s goals are the same as the business. Doesn’t contributing to the company’s success directly benefit the employee? Theoretically, yes; but of course it’s not quite so simple.

To the employee, the goal is not necessarily to do their jobs better and help the company. They may be driven by many underlying goals: appearing competent to superiors, enjoying the task at hand, feeling productive, solving problems, helping others, etc.

Although the user’s goals may not be in direct conflict with the business goals, software that doesn’t address them directly is likely to fail. A leading cause of failed software projects is rejection by the end user.

Identifying user goals

How do we discover the end user’s goals so that we may address them in the software? Here are some starting points to consider:

1. Psychology. As diverse as users may be they are — with rare exceptions — human. A basic understanding of psychology goes a long way toward discovering their true motivations.
2. Spend time with real users. Don’t make assumptions about their jobs, goals, or work habits. What tasks do they seem to pay the most attention to? Keep an eye out for signs of frustration which likely signal failure to meet personal goals.
3. Business structure. In large organizations it’s common for employees on impressing their manager more than anything. How can the software contribute to this?
4. Politics. This can create environments where employees must compete to get ahead, yet can’t give the impression that they are trying too hard. Will publicly ranking everyone’s performance help if being the “winner” generates enemies?
5. Discomfort and boredom. Efficiency is great but how will a user feel about completing the same form all day long? Although the previous 3 forms took longer it wasn’t nearly as brain numbing. People are not computers and yet software frequently treats them as such.

I’d like to hear some feedback on other ways to identify and address user goals. Do you have any examples from real life (software you’ve developed or used) to share? Post a comment below!

On the Apache web server, the rewrite module must be enabled for clean URLs to function properly. This module is usually disabled by default. Fortunately, WampServer provides a graphical interface which makes it simple to modify Apache settings.

Ready to enable rewrite_module? Here’s how:

1. Start WampServer. An icon should appear in your task bar:
2. Click the icon to open WampServer’s main menu.
3. Open the ‘Apache‘ submenu and then ‘Apache modules‘.
4. Scroll down to ‘rewrite_module’ and click to enable it.

That’s all there is to it! A quick tip, but important nonetheless and something I’ve seen a lot of CMS users — myself included — get stuck on. I hope this helps.

How can we know which typefaces mix well? As with most questions in design there is no definitive answer as it comes down to good judgement by the designer.

Fortunately, there is an excellent chart available to assist in the decision process: Mixing Typefaces (PDF). It contains 22 common fonts arranged into a grid which allows you to look up any combination of fonts and quickly see, on a scale of 1-3, how well they are likely to mix.

Download the PDF and have a look.

For Example: Hand Signals

Cyclists use hand signals to indicate a lane change or upcoming turn. For the safety of both cyclist and motorists it’s important that whatever signal is chosen is as unambiguous as possible.

The conventional signal for a right turn is to hold the left arm upright with the elbow bent at a right angle. This is a hand-me-down from signals designed for motorists who — at least in this part of the world — are unable to reach across and point out of the passenger-side window to indicate a right turn.

However, given the context of being on a bicycle, this limitation no longer exists. A cyclist can simply hold out their right arm and point in that direction to indicate a right turn.

Which is the correct choice? Although using the left arm is the “official” signal, I think it’s much clearer to point with the right arm. It’s unambiguous and doesn’t require driver to have any knowledge of hand signals to understand the cyclist’s intent.

Extending this example to design in general, I’d say that context should always be taken into consideration before using any pre-existing symbol. Unless the symbol communicates the message perfectly, it’s worth looking into other options. When symbols are used repeatedly to convey slightly different messages their strength slowly erodes until they become generic and meaningless altogether.

My goal? To empty the wish list so I could start fresh.

Here’s what I tried:

1. I scanned for an “Empty” or “Remove All” button. No such luck.
2. A “Remove” link is provided next to each item. Clicking one revealed that it requires a full page refresh. That’s going to take much too long; there must be a better option.
3. I know! I’ll set the quantity of each item to 0 and then update. This is common behaviour to shopping carts, which is essentially what this wish list is.

Here’s the message I received after setting the quantities to zero and updating:

The developers clearly understand I was attempting to remove items, yet they refuse to help me. Instead it’s suggested that I “simply click the Remove button”. How simple would it be with a list of 20 items? 100? They could code the logic to make this work properly in less time.

The lesson here is that for every error message you write it’s useful to quickly ask “Could I help the user instead of giving them this message?” If the message is a workaround, do it for the user instead of telling them how.

Everything should work, right? Wrong. Instead of seeing a duplicate copy of what I had on my local machine I received an error. Upon closer inspection I found that installing the CMS on the remote server produed camel case table names (ie. ‘myDatabaseTable’) while a local install gave me lowercase names (ie. ‘mydatabasetable’).

What’s going on here?

It turns out that while UNIX is case sensitive, Windows is not. Combine this with the fact that MySQL — when installed with WampServer, at least — converts all table names to lowercase and there’s clearly a problem here.

The application tried to create ‘myDatabaseTable’ and was given ‘mydatabasetable’ instead. A query will work fine on windows (where ‘myDatabaseTable’ is equivalent to ‘mydatabasetable’). However, things change when the database is copied over to a case-sensitive UNIX server. As far as MySQL is concerned, the tables being queried don’t exist!

A Simple Solution, Really

Fortunately, there’s a MySQL setting to alter this behaviour so that table names are not modified. Here’s how to do it:

1. Open the ‘my.ini’ configuration file. This can be found under the MySQL menu in WampServer.
2. On a new line at the end of the file, paste: lower_case_table_names=2
3. Restart all services for the change to take effect.
4. Reinstall the application. The created tables will retain their intended case, and you should be able to export this database onto the live server without incident.

I find it surprising that I haven’t run into this before or heard of others with the same problem; it seems like it should be quite common. Is there a good reason to have MySQL alter the table names by default? Should developers be aware of this and use all lowercase table names? Maybe so.