As a designer, your job is to match someone’s needs/problems with a solution. The tricky part is, this someone is not necessarily the client you are talking with and who pays you, it could be a third party that you only know of through your paying client.
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 only the problem of a person that you need to solve. Which sometimes involves far less technics than expected, but far more empathy because the actual problem might not be entirely technical, or even sometimes not technical at all.
Imagine a client that comes to you asking for a drilling machine. If you ask him “what for ?”, he will answer “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 what the hole is for, instead of jumping on the guns, the client would have a chance to explain that he 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, or because his neighbour bought a new cool drill. The client doesn’t have knowledge of the available options, and even if he had, there is still the part about imagination that is needed. But people fall back more easily into known patterns than they imagine solutions from the ground up. That’s why he is your client.
In this case, the bestest drilling machine is 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 often 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.
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 damaging 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).
To back up a bit, you should never include a technology or a device into your problem’s formulation. If I was the client above, I would go to the engineer saying “I need to hang lightweight picture frames on drywall, what do you have for me ?”. This way of asking would not bias the solution and it is the actual problem, so it directly opens all the possibilities.
Of course, if you are just building an all-purpose tool kit, you need a drill because you need a drill. But even then… Battery or wire ? Heh, if you use it only once in a while, better have it wired because your battery will be dead all the time and just pulling an extension cord is more reliable albeit slightly less comfortable to use.
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 it everywhere for convenience, no matter the client’s needs. If you let that blind you from the 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. It can simply be something already known and used, but never for that particular purpose or application.
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 and web browser because it was simple HTML and CSS.
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 effect of particular sliders. 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, and there is most of the time a real problem hidden underneath the presented problem. 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.
