Do we really need another MP3 converter? Or another Windows registry cleaner? What about a new time management program that’s just like all the other time management programs only with one extra feature?

When it comes to developing new software, originality is in short supply. So many companies seem to take the safe route and build a product that has been built before. They convince themselves that their product is going to be different, and that their interpretation is so much better than the competitions. The field they choose to work in is almost always flooded with more established versions of their new product. PageFour, my first project, falls into this category.

So who are we designing software for? Or more importantly, who are we not designing software for? A quick search on Google throws up the following:

Why is no one designing software for undertakers? They’re a business just like any other. Well, maybe not just like any other - but they keep records, make sales, and have a product range and stock to manage. They must be keeping tabs on all those different coloured coffins and bottles of formaldehyde somewhere.

It’s not only undertakers who are suffering from a lack of quality software to help them do their jobs. Software for nuns returns only two results, one of which is a link to a porn site. Pet shops, preachers, magicians… all suffer from a similar lack of attention.

Why are new software startups not taking advantage of this gap in the market? Granted, sourcing the product requirements may involve some hanging out in morgues and cemeteries, but surely a shot at becoming a market leader in an area that is guaranteed never to run short of business more than makes up for working in a socially embarrassing field.

So here’s a call to all you morticians, pet shop owners, preachers and magicians out there. How happy are you with your current software solutions? Are they drab, grey and barely functional? Do you dream of better days to come, when software with pretty icons will be designed just for you?

This is more than idle curiosity. I’m researching new product ideas, and would genuinely like to hear from anyone working in slightly unusual fields where dedicated software solutions are in short supply. if this sounds like you, and we’ll talk.

Programmers don’t like users. In an ideal world, whatever product they are designing would be beautifully written with the latest trendy technology, passed on to a testing department (preferably in a different city), and never sold to a single user. It would work like a charm when configured correctly through hacking various text and script files in Notepad, produce in depth exception reports for every problem encountered, and have a beautifully crafted and fully modular framework of code that can be reused in every future conceivable product - whether a flight simulator for NASA or a stock inventory for Jerry’s Fish and Chip Shop.

The problem with users is that they tend to get this crazy idea that what they see on the screen actually is the product. They seem to think that the hastily thrown together heap of grey dialogs and tacky icons sourced from a free download site is what they’ve paid all that money for.

They’d be right.

Software is designed to be used, which means it’s designed for users to use. Note the emphasis on the word use here. When someone pays you money for a piece of software, they don’t care how the underlying code base has been constructed, and they don’t care about the structure of the database. All that matters is: Can I use it to do the job, or will it cause me grief?

Every programmer pays lip service these days to the importance of user interfaces, but in most cases they don’t really believe it. Like an alcoholic who tells you about his drink problem, they say the words because they are the words people expect to hear, but deep down they still believe that they control the drink, it does not control them, and the GUI really isn’t as important as the engine running underneath.

For too many programmers the GUI is the bit bolted on at the last minute to satisfy users and the guys in sales. It is often designed by someone who thinks typing configuration commands into a text file is far more useful than an interactive GUI with trees and checkboxes; that a visual interface can never allow the flexibility and customisation of a simple configuration file. This is all true - if the sole user of the product is the guy who wrote it!

If you don’t think about the user from day one, you will never design a truly great product; you will never design a product people want to use. Even the giants make this mistake. I stumbled across an article the other day on the failings of Lotus Notes, one of IBMs big groupware products everyone was talking about ten years ago. To quote one of the many disgruntled users:

“Notes’s backend functionality has no bearing on us 100m or so end-users. As far as we are concerned the GUI is the system. And boyo… is the GUI client a heap of ill-conceived, non-intuitive rubbish.”

Lotus Notes now has the dubious honour of its very own hate site where its many failings and embarrassments are displayed and dissected for all the world to see.

There’s a lot more competition out there today than there was ten or twenty years ago. If you build a technological marvel and ship it with a shabby user interface, and the competition builds a functional product that looks fantastic, who do you think will win the sale?

My TV remote has twenty nine buttons I’ve never used; the VCR has thirty; the DVD player twenty six. And before you ask - yes I really did count them all.

There’s a name for this kind of excess: it’s called featuritis, and it pops up in all sorts of design failures. I stumbled across an interesting article on The Featuritis Curve the other day that goes a long way to explaining why we have to endure this.

Good designs are obvious. When aesthetic and functional beauty combine, the result is not just pleasing to the eye, but a pleasure to use. This is why the iPod is so popular. Chances are it’s not the best value for money - there are probably other music players that produce a better sound, have a longer battery life, or have a whole raft of additional features - but the iPod looks like a work of art and is simple and straight forward to use.

When have you ever heard someone boast that they couldn’t program their iPod?

So who should we be designing for anyway? The 98% who use a small number of features all the time, or the 2% who use advanced features once a week? Wouldn’t it be a whole lot simpler if my TV remote had a single advanced button that opened a menu for all those quirky, unused features?

Make no mistake here - you’ve never used those mysterious buttons either, and you probably don’t know anyone who has.

Software is often designed in the same way, for the same 2% of users. Feature after feature is added, each just as prominent as the one before, with little thought given to the complexity this adds to the product as a whole.

At the nine to five over the past few weeks, we’ve been putting the finishing touches to a new product aimed at the business market. It’s the sum of eighteen months work for four programmers - plenty of time and resources to produce a first class piece of work. But it’s not first class. Dialog after dialog contains features, options, and checkboxes that no one really understands. The poor unfortunate writing the help file has to suffer every time he asks for an explanation of feature X. In some cases, even the person who designed the feature can’t explain it without re-reading his own code, and even then the explanation can be patchy.

This isn’t funny, it’s critical. Complexity like this is nothing to be proud of. But why does it happen?

You can chant ‘keep it simple‘ until you’re blue in the face, and everyone around you will nod their head in agreement. The problem is, we all have a different perception of what simple means. Programmers are geeks; they belong to the 2% who use all those weird buttons on the TV remote, and for many of them these features are absolutely essential. The sales and marketing types want to be able to say that their product is better than the competition because it can also be used to fry an egg, or do your kid’s homework. But that does not make it better.

Features are not important, it’s the product as a whole that matters. Does it do what it was designed to do, and does it do it fantastically well? Does it look good, run smoothly, and behave intuitively? If it doesn’t, then all the features in the world will not save you.

More features does not equal more sales. More features does not make for happier customers. More features will not make your product better than the competition.

PageFour has reached the stage where featuritis first raises its head. Over the past couple of weeks I’ve been putting together a future development plan, and my focus throughout has been on identifying those mysterious buttons that so few of us ever use. Only time will tell if I’ve succeeded.

When I first created the web-site for PageFour, I’d vaguely heard of the term Search Engine Optimization. It was one of those things I assumed I’d get around to eventually, but it would just have to wait until the more important stuff like rolling out the first, and then the second release of PageFour had been dealt with.

I was wrong.

Had I read those few chapters months ago, I would have realised the importance of the URL, and chosen a domain name with more relevance to the product. www.imbt.co.uk has no meaning to anyone but me. I know it’s short for It must be Tuesday; I know IMBT Software is the company name; but does anyone else? And would it make a difference if they did? It’s the product that matters, not the company.

PageFour is software for writers, and the new URL is www.softwareforwriting.com.

It’s been live now for about a week and has already been picked up by MSN’s very industrious robots. The Google team however, seem to be sleeping on the job, and let’s not even talk about Yahoo. Still, it was something that needed to be done, and it really couldn’t have been put off any longer. All the links that I control on other websites have been changed, and the new download sites PageFour has been submitted to each carry the new URL.

Things are finally moving in the right direction.

It’s make or break time for PageFour. Version 1.2 went live at half past midnight.

One of the prevailing opinions in software development circles is to release early and release often. By doing this, you develop your product in line with your customers. Features being added to the next release should always be features existing users have asked for, or potential users have queried before deciding not to buy.

Releasing against a six monthly or even worse, a yearly development plan is catastrophic. The software market, and the IT industry in general changes too fast for such long term plans. And one year is a very, very, long time.

Small software companies have one huge advantage over the giants, and that is their ability to do things quickly. For Microsoft to release a new version of MS Word is probably a two year undertaking - for a company of one or two programmers, two or three months is not unrealistic.

I’ve been following this maxim with PageFour since day one. Version 1 was released on October 8th this year. The world did not shake, but the feedback and suggestions were inspiring. Two months later and I’m feeling very confident about the new release.

The only question now is: will the world shake? And if not, can I make it shake?

The Mini Cooper is a great looking car. I want one. A yellow one, with a black top. I don’t care about the engine. I don’t care about how advanced the brake system is. If I never had to lift the bonnet my happiness would be complete.

Most people who buy cars buy what they see on the outside. And why not? New cars don’t break down anymore - at least we don’t expect them to. So why should any of us be interested in what’s going on under the bonnet? If it looks cool, drives smoothly, and has really neat stuff on the dashboard, then it’s perfect.

Car makers have realised this, which is why the Mini Cooper is such a hot car. When are software designers going to get a clue?

Are we really interested in how slick the database structure is? Does it matter to anyone using a software product if the code base is fully modular and object oriented? And why are the dialogs all so grey and drab? - the Soviet Union lost the cold war. All that functional, boring, dullness is old hat now.

This is not dumbing down! We all like pretty things. Given the choice between pretty things that work well, and ugly things that seem to work no better, we want the pretty things. The designers of ugly things may try to convince us that their product is superior because of all the new technologies gone into the database, or the team of developers drafted in from NASA who built the engine, but the bottom line is: it’s still ugly.

Many of us spend hours every day sitting in front of the same computer, working with the same software packages. It may be a CRM system, a database or spreadsheet, or a simple word processor. Wouldn’t it be really great if these software systems looked and behaved as good on the outside as they claim to do on the inside?

Give us pretty icons, a clutter free workspace, an intuitive working environment, and please - stop blaming us when things go wrong! To use a tired old phrase commonly used in every context except this one by software designers: ‘It ain’t rocket science.’ Not even if your developers used to work for NASA.

My primary aim when designing PageFour was to make an attractive word processor that worked well. I wanted it to look cool, drive smoothly, and have really neat stuff on the dashboard. With version 1.2 only days away, I’m coming closer to achieving this.

Paul Graham, in his book Hackers and Painters, wrote:

To make something good, you have to be thinking, “wow, this is really great,” not “what a piece of shit; these fools will love it.”

Many years ago, my day job consisted of working on a piece of software for the business market that I considered to be a piece of shit. Now, this is not the best opinion to have of the product you spend forty hours a week working on, and it would be true to say that holding that view did not help me add anything really great to the design of the product.

To design well, you must passionately believe that what you are working on is really great, and that even if it never sells a million copies, or even a single one, it is still really great.

Four months ago I went part time at my current nine to five to work on my own ideas. PageFour began life as a personal project, born out of my own frustrations with MS Word. I wanted to design a word processor that placed the emphasis on words; a word processor that made life easier for creative writers; a word processor without a single piece of business oriented functionality. I wanted to design a word processor for the way I worked.

I’m writing this in PageFour now, and I think it’s really great.

Since I began working in earnest on something I felt passionate about, my working day has gotten easier, my designs are better, and the new ideas that have been absent for the past year have started to flow again. I have a list of projects I can’t wait to start work on next year, and every one of them has the makings of a great project.

When I rolled out the first beta version of PageFour over two months ago, I was convinced that the only changes I would need to make before releasing the full product would be a few minor bug fixes. I could not have been more wrong.

Like so many software designers before me, I made the fatal mistake of assuming I knew what was best. I assumed that because I had decided particular features were important, my potential market would feel the same; that because I felt something was acceptable in its current form, everyone else would agree; that because I worked in a certain way, so too would the thousands of writers out there who I was writing PageFour for.

In retrospect, I can see how my first beta release was more about testing the idea behind the product, than testing the product itself.

I’ll be honest - it threw me just a little at first. But I took it on the chin, went back to the drawing board, and made many of the major structural changes that were suggested. The end result was a first release that was far superior to the version I had planned.

An idea in isolation is just an idea - it needs refining before it can become anything substantial. Developing an idea into a product for use by other people cannot succeed without the input and knowledge of those people.

Version 1.2 of PageFour is due for release in four weeks. It contains many of the suggested enhancements from the previous beta run not yet incorporated; enhancements that mark a significant improvement in the product.

The beta version of 1.2 will be released next weekend. This time around, I can’t wait for the feedback.

Let’s say you have a brilliant idea. You absolutely love it, think it’s the greatest thing since sliced bread, and are firmly convinced that it will revolutionise the way people think about XYZ - not to mention the fortune it is sure to make you. But before you spend any time doing in depth market research - or simply bypass this critical step and start designing - you decide to run your idea past a few other people.

Now, this is the smart thing to do - all the books say so!

Just how valid are the responses you get? When I was starting work on version one of PageFour, I ran the idea past a number of people - some I’d known for a long time, some I’d never met or even spoke to, and some were anonymous fonts of ‘free’ advice on internet discussion boards.

The responses I received fell into three categories:

“That’s a fantastic idea. Go for it! Life is short.”

Of all the feedback I received, 95% fell into categories one or two, with a roughly even split between them.

Sitting back and listening to the carpe diem crowd can be uplifting for about five minutes. You feel vindicated, energised and convinced that you’ve really got something here. Then you start to wonder. The guy sitting opposite you, spewing forth on the joys he had starting his first company twenty years ago, wishing he were young again, is the same guy who ran his own company into the ground by jumping on every band-wagon that passed him by, and by accepting every new idea presented to him by a suit with an MBA as if it were the holy grail. Channel partners anyone?

Just how valid is “That’s a fantastic idea,” as a solid assessment of a business plan?

Now, negative feedback can be really constructive. You have the opportunity to hear from people with all sorts of experience on what may be wrong with your product or idea, what pitfalls lie before you, how company B tried the same thing only to discover that the market really wanted something else. But so much of this criticism comes in the form of aggressive slap-downs, rather than anything you can really use. You can just picture the same people who respond to you in this way moving on to flame and troll their way across the internet, happy in their anonymity, free to wallow in their own uninspiring tired lives.

The third response is the only one that matters. It doesn’t matter how many people think your idea is fantastic, or how many people think it’s the dumbest thing they’ve ever heard. These are probably the same people who were sure the dot com bubble would never burst, or that this whole internet thing was just a fad anyway.

In the early stages, every idea has a hundred and one things wrong with it. A second or third version of a product may have nothing in common with the original idea apart from the name, and sometimes not even that. Real, honest, constructive criticism should help you identify some of these areas; should help you to move from your initial idea to something that might resemble a product, or at the very least help you identify the areas that may cause problems as you move forward.

If you are lucky enough to find someone who offers you this kind of advice, get down on your knees and worship them. Beg to be their apprentice. Call them Yoda if you have to, but listen to every word they say.