Really bad design versus very good programming

Originally posted on Always-On

As a designer and a programmer, I get to see things from a pretty unique position. And as a business owner, my view is sometimes a lofty one, coloured by the varying issues that I need to keep in mind when engaging in a project. Within each project, there is a triumvirate made up of a designer, a developer and the client.

The client has needs, these needs are communicated to both the designer and the programmer. But, the way in which these needs are interpreted by the designer and the programmer are often quite different.

The two worlds of the developer and the designer are quite different: the developer deals with parameters, perimeters and usually quite rigid rules. The designer however has very few restrictions and has ‘creative license’ to indulge themselves in the ephemeral, the intangible and the implausible.

There are rules for the designer, but if the designer is of a certain ilk, they can dismiss such rules and make there own. For the developer, this isn’t an avenue free to them to explore. Such departures from the riggers of the rule of programmatic law are seldom walked and usually exploratory and may only fleetingly yield value.

So again, two worlds collide.

There was a time when I would deride the developer for their limited imagination, but then I started teaching myself to be a programmer, and I could then see into their world through their eyes. Needless to say, it was an eye-opener.

But then over time, as I become a more accomplished programmer, I saw that the rules of the world of the programmer were no less prone to adjustment and in some ways, no less malleable than that of the designer.

This might not make sense to seasoned programmer, because they may well be reading this and saying: ‘You’re talking crap, and lots of it, too!’ But I would ask that they bear with me before committing their expletive-ridden rebuttal to the comments section of this article.

There is one thing that shouldn’t be forgotten when either designing or developing: the needs of the client. And by extension, the needs of their customers -- which is often the case with my clients, given that they’re usually businesses who deal with consumers.

I enthuse in user interface design. There is an enormous amount of leeway between extremely intuitive usability and abject failure. I love the exploration of the twin towering tenets of user interface design: design communication and design aesthetic. That is, the function of design married with the look of design. Not always mutually accepting of one another, not always in agreement, and therein lies the challenge.

So as both designer and developer, I can see where a design is likely to break functionality, or where functionality imposes unreasonable effort on the design and the user.

Now, getting back to the issue of the rules of the world of the programmer, it’s worth clarifying now what I mean by the rules being adjustable: in and of themselves, they aren’t really, but how you present functionality and you coerce logic is.

And I see this because I keep the needs of the client central to the task at hand. I might develop something that in terms of functionality is seemingly overly-complex and in need of revision, but the sum of this complexity is simplicity for the end user.

There is a certain reluctance on the part of some developers to break with the rules of programming laid down to them, even if the goal of meeting the needs of client would be fulfilled. So this may very well be an issue of purism versus liberalism.

I’m probably neither a liberalist or a purist. Because I’m self-taught, I sort of sit outside of both camps. No one ever sat down with me and said: ‘... And these are the rules, just don’t go and break them, OK?’ I did break them, and that’s not because I’m some maverick programmer, I broke them because I didn’t know any better at the time.

I have a rule when dealing with my clients: never tell them too much about what you do, or how you do it. There are many reasons for this, non more important than preserving the mysticism of your black art, but one equally important reason being, if they know enough to know they’re making you’re life hard, then they may choose to limit their imagination simply to make your life easier.

This may then have far-reaching repercussions. They may choose to scale down or dilute an idea just to keep things simple. So knowledge isn’t always a good thing, especially if that knowledge is in the wrong hands.

Sometimes however, a client does need to know more. Especially when you get: ‘Yep. Love the design. But .. [pause for thought] could we change the green to blue? That’s not too hard, is it?’

Usually, it is extremely hard. And in times gone by, it’s meant completely ripping up the design and starting from scratch. Worse still, if you’ve gone beyond the design stage and have entered into development, such a sudden change can become an Herculean task. Which is sad. So, a little education used judiciously can help more than it hinders.

I imagine some of you are wondering how the title of this article ties in with any of this? I shall clarify. In my years of designing and developing, I noticed a repeating rule. It’s a rule that doesn’t always apply, simply because there are too many factors beyond the project itself, such as who the end user is, quality of marketing et cetera, but the rule is quite simple, and it is as follows:

You can have an average design and poor functionality and the thing will probably work. But if you have a poor design and excellent functionality, it will usually fail.

Like I said, this isn’t always the case, but I’ve seen it work out that way many, many times both within my own work and with work from other agencies I’ve either worked for, worked with and watched from afar.

I’d like to think that I’m able to provide good and sometimes excellent design with some times above average, other times pretty good functionality. But that’s not for me to say, modesty prevents, you understand...