There is a common misconception about digital designers.
It’s that our job is to make something look good.
Now don’t get me wrong—making something look good is very much a part of what we do. And in our age of technology, there’s little limit and much opportunity to what we can do.
But visual design is the last, and often most straightforward, part.
It’s something I’ve begun to realise the longer I work as a designer: the variety and importance of all the other design tasks that come before I’ve even given a fleeting thought to how it looks.
And it’s something that you might have recognised already. Many though, have yet to see the potential of design thinking, applied across the entire process of creating a digital product. Too often I hear of designers brought onto a project with mere days until release, a solution already decided (and sometimes half built), and told to “do the design”. Translation? “Please make this look pretty, we need to ship ASAP.”
Too often are problems discovered after the product is built and near ready for release. Too often are attempts to fix a more fundamental problem with code. And too often are suboptimal—or even detrimental—solutions shipped.
Great design starts by getting designers involved at the very beginning: what is the problem we’re trying to solve? Why is this a problem? Is it a problem, or have we wrongly identified some side-symptom of something more fundamental? What will it look like when we’ve solved the problem? What metric will tell us how well we’re doing? What assumptions did we place upon trusting these metrics? How can we quickly test these assumptions?
And really, great design starts by getting the entire team involved at the very beginning. Everyone has a personal stake in the problem. No one is a cog in the machine.
It’s pretty clear now how the state of web design is unbearably homogenous. And yes, we as a design community desperately need to diversify—most importantly in the people who make up ‘designers’.
He’s got a point—those layouts are tried and true and tired. However, layout frameworks are a tool, and like any other tool, are immensely helpful when applied correctly.
When we’re solving easy problems, slapping content into a known layout framework could be fairly construed as lazy. But what if your project spans years, touches millions of users, and requires thousands of decisions? When a mere few percent of your user base equals thousands of people, all decisions become important.
Designers get decision fatigue, just like everyone else. And in some cases, the important decisions to be made are not the layout ones. What information do we surface? Are these interactions discoverable? How do we present long and complex content? Leveraging a layout framework means shifting mental capacity from a solved problem, to an unsolved one.
There’s another fact we must take into account before we dismiss layout frameworks completely. As designers we often become siloed in our own products. We only see from the perspective of users learning to use our app.
In reality, each user is learning to use twenty, thirty different apps, and hundreds of different websites. Thus, every novel interaction we introduce must be carefully weighted against its usability and ease of learning. Repeating common patterns is a way we, as a collective design community, make our products easier to learn and easier to use.
Toolkits in Tandem
For the longest time, I thought my job was to make things look good. And to some degree, it still is. But what I’m really doing, is problem solving with a design-thinking toolkit.
Others on your team will have different toolkits. Some might use programming skills. Some might use people skills. Some might use data-analysis skills. That’s what makes a good team of problem solvers: a collection of different toolkits.
Did you ever hear the saying: “If your only tool was a hammer, you’ll treat everything as a nail”?
So it makes no sense for a problem to be solved with, say, a data-analytics toolkit, that then needs to be implemented by a design toolkit, than then needs to be implemented by a code toolkit. That’s like me saying, “this problem is a nail,” and then handing it to a sewing machine.
Your solution might work, but it might not be the highest-impact one. The least-effort. Whatever your metric.
Our toolkits (i.e., people) need to work more in parallel. We need to first uncover what the problem is, and if our possible solutions are truly worth pursuing.
How does the context around the problem affect our possible solution space? Have users already learned bad solutions? How will that affect how we onboard them on our new solution?
Will our new solution make the problem worse?
These aren’t necessarily hard questions. But asking them at the start to the entire team, instead of later, will save us all a tonne of trouble.
Introduce the problem to your team, early. Hear their perspectives, early. Trust the people on your team to be masters of their own toolkits.