Published On : 9 April 2020 |Last Updated : 9 April 2020 |1223 words|5.1 min read|0 Comments|

There is a parabola I came up with a few years ago, about design and engineering, and it seems to fulfil its purpose quite well, so I though I might share it here.

As a designer, your job is to match someone’s needs/problems with a solution. The tricky part is, that someone is not necessarily the client you talk with and who pays you. As an engineer, the particular kind of design you do aims toward technical solutions, so you might produce plans, blueprints, calculations and prototypes to carry on with that goal. But, in engineering school, I learned that this was to solve a technical problem, and I disagree with that. Technics are only a mean to an end, ultimately, and it is still the problem of a someone you need to solve. Which sometimes involves far less technics than expected, but far more empathy. So we are still solving people problems.

Imagine a client that comes to you asking for a drilling machine. If you ask him “what for ?”, he will answer you “to drill holes” (duh). So, an average engineer might jump on the guns, draw, compute and prototype the bestest drilling machine : the fastest, lightest, cheapest and more reliable little dust maker to turn every bit of concrete back into pure sand.

But… The client is not a designer and is a liar.

If you keep asking questions about “why do you need to drill holes” instead of jumping on the guns, the client would have had a chance of explaining that he only needs to hang a frame on his wall, for example. From which he derivated, himself, that he would need a hook, so a hole, hence a drill. Why ? Probably because he always saw frames hanged on hooks, and never questioned the existence of better options.

In which case, the bestest drilling machine is not only over-engineered, but there are loads of other solutions that just appeared when you pulled the real issue out of him, like double-faced tape or a picture rail in case you want to change your frames disposition without shooting permanent holes all over your walls.

The thing is, the client is the worst to diagnose his own needs. And it’s not necessarily because he is stupid, it is usually a difficult cognitive exercise to take some distance with our everyday problems, especially after having developed coping and avoidance mechanisms, that are bad habits in disguise pretty much all the time. But people can become very proficient at inefficient and sub-optimal workflows, until they try to teach them to someone else.

But, what is even worse, the client will often come to you with a pre-solved problem, thinking he did you a favour, while he only just lead you into a one-way and instilled a bias in your mind. See, the client is not the professional problem solver, he barely even knows his problem. That is why, for example, for big projects, some engineering firms specialize in specifications books, and some others in plans : this avoid biasing the solution from the early stage of design, by splitting the job between people who focus on defusing the landmine of clearly defining the real problem, and people considering all the solutions to choose the best and turn it into a deliverable thing (good or service).

The thing about holding your horses at early design stage is we all have some pet technology we like and are comfortable with, and want to plug everywhere for convenience, no matter the client’s needs. If you let that blind you from start, you are missing innovations opportunities. And innovation is not necessarily a long and tiresome process if the problem (and the scope of the solution) is clearly defined, nor does it need to design something from scratch and change the face of the World with it.

In software design, that’s something common too. People think their problems in terms of “I want to bend [that unadapted software] into doing [this simple task]” instead of “I want to achieve [this result] in [this context] with a tool that requires [that much learning]”. Putting the tool or the technology in the description of the problem to solve is very bad. Of course, you are tempted to capitalize on [that complex software you spent so much time learning], and that’s understandable, but you might do yourself a large disfavour on the long run.

I once helped an assistant-architect, over a couple of evenings, who wanted to bend Microsoft Excel into displaying furniture listings from a building blueprints. He fought Visual Basic for more than a week to produce an half-working solution. It took me almost an hour to cut through the technical crap (“so I want to use the soft do that this and that”) he was throwing at me and get to the real core problem : we wanted to display a grocery list of the furniture to buy for each room in a building, so the client could check and approve the invoice. It was a simple problem, but, believe me, its description was obfuscated. As he was working with Autodesk Revit to manage the whole project, and they provide a nice Python API, in less than 2 hours, I built him a Python bridge that exported the listings from CSV files to HTML tables, and building a local website (just a collection of HTML pages, really) with a list of rooms as index, and each room getting its own page linked from the index. With an extra 6 h, we set the styling, cleaning, adding the room blueprints image in pages, and done. The solution was light, fast, and compatible with whatever OS.

In darktable, I often get questions like “I want to use [this module] to do [this unrelated things], possibly like [this different software]”. So, once again, it is often exhausting to come back to the original expected result on the image, especially since the fashion of “intuitive” image processing UX hides all its technicality, so users are uneducated (and stay that way) about color science/theory/language, psychophysics and technical limitations of colour spaces. Photographers don’t approach retouching in terms of visual result/goal, but in terms of setting effect. Again, you need to cut through the crap with a machete to understand what people see, what they want to see, what happens instead, and often, it is more education about basic colour science than programming.

The early steps of design are more of a detective job, with a lot of psychology in it, and some serious translating skills involved. People never want what they think they want. Also, language makes it harder, because it is not accurate and very inefficient as a logical processing and communication tool, and metaphors only get you this far. So the answer is to translate everything into abstract maths and physics language, because those require to be much more specific and provide a better logical framework, but translating from natural language (subjective, ambiguous and logically sloppy) to actionable language (objective, logical and specific) is the most difficult exercise of them all, and it really helps to have experience on both sides.

Once you have crossed the barrier of subjectivity, you are home and it’s only stuff you can learn at school or in books. Draw sketches, unroll the proper science to compute what you need, don’t forget to ask the tech guys if your brilliant ideas can be manufactured and maintained, build shit and enjoy that new baby of yours.

This site uses Akismet to reduce spam. Learn how your comment data is processed.