Business Design Usability

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 their own. For the developer, this isn’t an avenue quite as free to them to explore. Such departures from the riggers of the rule of programmatic law are seldom walked and usually exploratory, usually only fleetingly yielding any 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, this was an eye-opener.

But then over time, as I became 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 the 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.

Also, being self taught means that I have in some ways avoided some of the regimented and disciplined teaching methods and have instead explored my own methods and ways. In doing this, I have approached problems from angles that might not have been as intuitive, but in doing so, I’ve uncovered unconventional and unique ways of solving problems.

I enthuse in user interface design. There is an enormous amount of give & take between a design that is 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, these rules aren’t really all that adjustable, but how you choose to present functionality and how you choose to 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 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, I never tell them too much about what you do, or how you do it.

There are many reasons for this, none more important than preserving the mysticism of my black art, but one rule that could qualify as being maybe equally important: if the client knows enough to know that what they’re asking for is likely to make your life hard, then they may choose to limit their imagination simply to make your life easier.

This may then have far-reaching repercussions. The client 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. 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 within work produced by other agencies I’ve either worked for, 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…

By Wayne Smallman

Wayne is the man behind the Blah, Blah! Technology website, and the creator of the Under Cloud, a digital research assistant for journalists and academics.

2 replies on “Really bad design versus very good programming”

“where functionality imposes unreasonable effort on the design and the user”

What about where design imposes unreasonable effort on the developer? Your focus is on design (as a codification of the needs of the client) as the only rule, but if cost of development (including adequate testing) exceeds the agreed budget then it’s like trying to fit a quart into a pint pot.

As a Project Manager (who has been a programmer and a designer in my time) who often deals with client requests to ‘do the impossible’, I have to explain how there’s a payback to them getting what they want. We can give them what they want, it just may take longer and cost more. There are three tenets which bound any work done in this realm: Time, Cost, and Quality.

If your main constraint is Time, we can get it done, but it’ll cost more and the quality may suffer.
If your main constraint is Cost, we can reduce the quality (e.g. don’t test)
If your main constraint is Quality, it may well take longer and cost more.
Of course if the requirements are reasonable you may be able to get exactly what you want.

“the needs of the client central to the task”

BUT the needs of the client are ephemeral unless codified in a requirements statement. If you can’t describe them you can’t deliver them. Once the requirements are documented they then go through a number of cycles to reach a stage where they can be coded. Rapid development methodologies overcome the translation difficulties that this process incurs to some extent.
The ideal shortcut is for the requirements gatherer, designer and developer to be the same person (which is where you’ve found your bonuses because there’s no translation problems within your own brain). But that’s not always possible, or desirable, where the skills aren’t available, or the time is short.

“if the client knows enough to know that what they’re asking for is likely to make you’re life hard, then they may choose to limit their imagination simply to make your life easier”

What’s wrong with that? It’s called compromise.

“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.”

Compromise again! Usually it’s the client who wants ‘the functionality’ and it’s up to the designer to make it all fit – which is sometimes impossible. If the designer is capable, she will negotiate a compromise in functionality with the client rather than create a poor design to fit all the functionality in. Or she will negotiate a compromise in the design in order to fit all the functionality in.

A key to ‘getting a good result’ is understanding what your immovable requirements are and compromising on the rest of the requirements as necessary to achieve the result.

“What about where design imposes unreasonable effort on the developer?”

That exists.

Simply because I didn’t touch on that side of things doesn’t mean that such issues aren’t relevant.

In fact, I’d say that the wayward designer can create no end of problems for the whole team, not least him / her self when they come to slicing & dicing their design in preparation for development.

“‘If the client knows enough to know that what they’re asking for is likely to make you’re life hard, then they may choose to limit their imagination simply to make your life easier…’

What’s wrong with that? It’s called compromise.”

Quite a lot, and little of which having anything to do with compromise.

If the client has a picture in their head whereby they think that what they’re going to ask for might be a problem; typically translating into extra time & cost, then good ideas can sometimes be set aside and otherwise worthy features might never see the light of day.

I’d prefer a client to hit me with all of their ideas, good or bad, so that I can work my way through them.

There have been times when I’ve taken the challenge of developing a feature that just looked utterly un-producible [sic] and made the thing work in a way that just wan’t anticipated before hand.

I can’t think of one single occasion when I considered a compromise.

Such things are there for the client to consider, not me.

If the client has a small budget but wants the moon on a stick, then my question is, “If you want to meet your budget, what don’t you want?”

They make the compromise, not me…

Leave a Reply

Your email address will not be published. Required fields are marked *