Note: This is Part 13 of the Ruminations for Aspiring Designers series.
Even if you don’t directly design anything digital, chances are, your design is going to be used digitally in one way or another.
Digital technologies’ permeating presence makes it hard to ignore and inevitable to understand.
That’s not to say a designer should learn to code, or anything like that. Hell no.
To design in a digitally permeated world, understanding the meaning, nature, nuances and implications of the digital technologies is the critical context of any design that ever happens now.
But how do you grasp it?
To really understand the big picture that digital technologies have shaped and are still shaping, you need to look to the sources.
Most mainstream digital technologies and their ubiquitous applications are at least partially (but critically) shaped by the dominating philosophies behind their inception and evolution.
To put it frankly – if you didn’t understand major programming paradigms (e.g. object-oriented programming, functional programming), modelling language or, more specifically, software design patterns, dominating software design principles or design by contract, then it could be hard for you to make sense of the digital technological scenes around the world, be it software platforms, software products, software technology trends or the emerging technology frontiers. In the same vein, you probably should bother to care and learn about what people say about Web 1.0, Web 2.0 or web3.
Those things are the golden foundation of the entire digital world we’re being immersed in. If you didn’t understand them, then you’d be conventionally described as “having no clue” when you’re designing digital stuff.
To a designer, that may sound like a lot to ask. But it’s not.
The key thing here is to know that, you don’t have to learn about those things like, say, a software developer does.
Just like any designer would need to do, you have to take an architect’s point of view to grasp the grand design before, beside and behind what you see.
What you need to learn and understand is not the meaty details, but the philosophies and histories. The latter is the source of understanding that makes you truly well-informed.
In a sense, that understanding also gives you some kind of “situational awareness” when you design – especially when your work is in the context of digital transformation, which is (or at least pretends to be) happening pretty much everywhere.
For example, when you get started in a big digital project, as much as it’s wise to ask yourself questions like “who are the users?”, “when can I start UX research?” or “what are the goals?”, it’s equally (if not more) important to ask questions like “what’s the topology of the operation/process?”, “what software platforms are being used?” or “what does the software architecture look like in this project?”.
In a digital project, whereas the former types of questions help you articulate the problem space, it’s often the latter types of questions that help you understand it.
The catch is that, obviously, you have to actually understand the answers to those questions. That’s where all those digital technology related domain knowledge comes in.
So where do you start learning?
Read Wikipedia entries, scan through some introductory programming courses, or read some articles and books about the general histories of computation, information technology, software development and programming. And, of course, befriend and learn from the experts of those expertises.
My personal take is that, it’s probably better to understand the following*:
- Basic concepts of programming
- General histories of mainstream programming languages
- Basic concepts of object-oriented programming paradigm and software design patterns
- General histories of computation, computer software development and the internet
- Software architecture, enterprise architecture and business architecture
If you’ve read my article about the design career double diamond, then you already know that nobody learns all those in one pass.
You only learn things slowly, gradually and patiently, through projects, jobs and colleagues, and over the years.
Most of all, you learn it intentionally – learn by design, not by accident.
Eventually you’ll start seeing things differently for the better.
Ways of seeing matter, and a designer never, ever, has only one way.
{END}
* You might think that I’m pretty biased in those matters, because I myself come from a technical background (indeed, I was a developer and software engineer before I was a designer). True, while at the same time, what I can tell you is that so far I haven’t seen anything from my old profession that isn’t helpful in my current one. In fact, the philosophies of OOP alone served me so well that I couldn’t believe design education doesn’t cover it.
Noah Fang 
1 comment