What’s after the canvas?
Hey you, with the glowing rectangle in your face.
Yeah, you.
Do me a favor really quick and open a modern design tool, I’ll wait.
.
.
.
Sketch
Photoshop
XD
Canva
Figma
Framer
Corel
… pick one, doesn’t matter. You’ll see why in a minute.
.
.
.
.
Okay okay, you’re on a phone. Sorry, sorry. Medium won’t let me write responsive articles yet.
Here, have one of mine:
“But you said modern design tool…”
Wait, is that not what I sent you?
“Nah, Tom. That’s like… Mac Paint. It’s almost 40 years old. Also, how did I learn your name?”
Never mind that now, let me find another one. I know I have some around here somewhere.
Here!
“That one is old too… whose voice am I reading these in? It’s not mine… if it’s not mine, then whose is it?”
“If I’m still reading this, are these my thoughts? DO I HAVE FREE WILL??”
Woah there, turbo!
No need for an existential crisis. This is a safe place for safe words and casual thoughts. No need to go down that rabbit hole. I just took you there so you’d keep doom scrolling.
No need to overthink things.
Now to the point.
Design tools. In a real way, have changed so much over the years. But in a much more meaningful and real way — that I need to make my argument valid — they haven’t.
ಠ_ಠ The canvas has stayed the same
That may seem like a small thing. It’s the place where you work. It’s the workspace. It was finite, now with many tools it is “infinite”.
- Open tool
- Draw rectangle
- Pan around
- Drag some shapes more shapes
- Share link
- Repeat
That’s how we designers work day in and day out for making apps, websites, logos, illustrations. It’s all the same.
But why?
Why are product designers, graphic designers, and other designers all using the same modalities for expressing our thought? Are our outputs the same? Are our problems the same? Are our workflows, needs, constraints, expectations, deliverables the same?
What it takes to make a good product design is not what it takes to make a good logo or marketing design.
I’m not talking about the skills, the documentation, or the deliverable.
The what-I-need-to-think-about-before-I’m-done side of things is different.
Not better, not more difficult.
Different.
A product designer should think through (not in any order):
- The user’s needs.
- The technologies’ constraints and capabilities.
- The business’ needs.
- The data that we have to make a product out of (shameless plug for Basedash).
- The environment (physical and digital) the product is being used in.
- The other products that might be used by the user after ours.
- The budgets for development and design(time or $).
- The definition of success, or the tracking of progress against a stated goal.
- The voice, tone, and clarity of words in the product.
- The languages a product might be rendered in.
- The speed of the internet (or lack of connection) a user might have when using a product.
- How to handle product or system errors.
- How to handle errors by the user.
- Future versions and how features can be broken down and released in phases.
- Other teams within a company that might be working on a similar problem.
- Other teams within a company that might have something to add.
- Competitors products and what they do well or poorly.
- What the user might be thinking, seeing, feeling, wanting before, during, and after using your product.
- If what we are allowing the user to do might be manipulated by “bad actors” i.e. criminals and other n’er-do-wellers.
- The user’s physical ability to interact with a product.
- The product's ability to receive the right interactions from the user.
- The brand’s needs and presence in the market.
- If a feature or product needs to exist at all.
But our tools present us with a blank canvas. They say “what does your product look like?”
(≖_≖ ) What does the product look like?
What???
Your product looks the way it looks BECAUSE of all of those other factors. Not because it needs to look flashy or sexy or trendy or cool. Because of a problem to be solved, an understanding of who is using it, where they are, how, and most of all why.
All of the visuals of a product are a result of those other needs.
But yet. We have a canvas.
“Paint a product” your design tool says.
“Evoke meaning through visuals”
“Colors. ADD MOAR COLORS”
For a painting or logo? Sure, use a canvas. For a piece of music, sure evoke emotion as a primary goal.
But for a digital product?
Make something useful, and it will lend beauty. Give someone a way to accomplish a task quickly and easily, so they can get on with their life and that will evoke positive emotion. Add visual touches for flair when they help those goals, but also consider the other factors that are at play for making a product.
Now, don’t get me wrong. I use design tools all day. Big fan, huge. I’ve got an actual Figma blanket for goodness sake and it keeps my toes suuuuper toasty in my dank basement office.
I’m not saying that a canvas shouldn’t exist, or that it’s not a necessary and important tool. Visual design is important, visual design is fun, but visual design is not product design. Product design contains visual design.
And no. Before you say it, this is not a “what is UI or UX post”.
Mmmrkay? Don’t get sidelined, here muh dudes ‘n dudettes.
Our tools give us a million different ways to make things look better, but very few ways to answer the core questions about our products. We have to string together dozens of different workflows to understand what the heck is going on, who we’re making things for, what our goals are.
Visual design is easy.
(╯°□°）╯︵ ┻━┻ Visual design is easy
Woah, woah !
Do not keep on scrolling and go commenting without reading further.
I didn’t say that the skill of visual design is easy. It takes years and lots of work to get “good” at it.
I mean that it’s easy to see a canvas and say:
“I’ll figure all of the hard stuff out later. For now, what if my UI looked like…”
THAT.
THAT is the easy part. The trap.
Visual design isn’t easy to do, it’s easy to fall into the trap of doing first.
The ease we have to make visuals. To prioritize colors over content, icons over accessibility, illustrations over interviews, drop shadows over database structure.
Those other things are hard. They’re time consuming, often invisible, and aren’t nearly as tangible as a visual.
No one retweets a .csv of a clean dataset, rebounds a dribbble shot of a summary of user intentions, or writes a long Medium post called “top 10 features I never released.”
Because looks are cool. Looks sell. People talk about looks. And looks are easy to share.
That. Is the trap of the canvas.
The trap of the canvas
Visual design should not be the first and most approachable step in the product design process. It’s part of a much bigger whole and needs top be treated as such. There needs to be something else to orient our workflows around other than the visuals.
There needs to be something that we constantly reference and orient ourselves around that better reflects how people use our products. Something linear, moving, and always changing over time.
Currently product design tools tell us that we need to focus on designing the scenes (frames, artboards, etc) one by one.
They tell us that we should focus on designing a snapshot in time when a screen exists in a perfect state. In reality though, the screens we design are much more like the scene in a movie. Needing proper lighting, staging, framing, and prep, but part of the whole narrative.
Our tools don’t help us think about the narrative. They only care about the scene. The now.
Click canvas. Make scene. Make frame.
Make a now. Make a fake moment.
Pat yourself on the back for how good that one moment looks. Never think about the before and the after. Just the now.
What else is there?
I hate to break it to you, but apps ain’t static. By nature, they’re filled with user data, personalized, curated, resized, themed, loading, partially filled, errored, invalid, empty, pending, abandoned, resumed, timed out, missing pages, translated, zoomed, backgrounded, minimized, alerted, and docked.
I bolded the 2 that we can do in our design tools. Just 2.
We can make themes.
We can “resize” with tools like autolayout.
Yeah. Umm, that’s kinda it.
Where’s the user data? → We make it up.
Where’s the loading state? → Oh you mean this spinning gif?
Where’s the error state? No, not the red input field, when are the elements in error, what are the errors, and what do they mean?
What does this UI look like zoomed in? HA! WHAT IS A ZOOM??? Zoomed screen, zoomed font, zoomed phone. Good luck with that, slick!
What is the user flow?
Which user?
Which flow?
Your app isn’t one user, one flow, and sure as hell isn’t one screen, then why are we emphasizing the small details instead of the big picture??
“Get to the point, Tom”
Okay okay. This is what I want 👇
Here’s the link to the original so you can see it in detail: https://xkcd.com/657/. Amazing comic, amazing visualization.
It clearly shows, without any of the visual noise of each scene, how the characters (Users) in those movies (Flows) progresses throughout the entire narrative. They overlap, intersect, share common scenes (features), meet supporting characters (external services) and end (churn or abandon).
Again, these charts aren’t new. Tools like google analytics have versions of them, and you can make flowcharts, swimlanes, and diagrams in nearly every design too. But they’re always side features of the “main” tooling. They’re denigrated to the “oh you can also” parts of the tool.
The journey IS the product just as much as a character’s progression IS the movie.
I want my design tools to emphasize the journey in the same way. I want to be able to see the flow for each user, from beginning to end, and be able to determine where there’s overlap, shared UI, shared API calls, exceptions, prominent paths, and I want each of these “scenes” to be their own canvas.
I’m not calling for the death of the canvas, I’m calling for it to be put in its proper place and make the initial emphasis for product design to be about the narrative, not about the individual screen.
More than flowcharts
I know about flow charts. Trust me. I make them all the time. I’m well aware how to use them, the problem is that they’re made in addition to UI, and don’t serve to determine the UI.
Let’s zoom in a bit on the Star Wars section of that XKCD comic.
And imagine that you could see your product from the same perspective.
Nothing crazy there yet, but let’s now add some canvases to the mix.
The infinite canvas is important. It allows space to try new ideas, to bump things around, make mistakes, and go in wild directions.
But it’s too in the weeds. I want to design the story first, then work on the scenes after I know where everyone is going.
We need a way to bind together user flows so we can look at the features themselves, understand what was before, what’s after, what services connect, what users are participating, and what elements they’ll encounter next in their journey.
This bird’s eye view can be more than just a visualization. It can also be the mechanism by which we create working canvases.
If our design tools were more about the big picture, we could bring in researchers to help define and share insights about the users in a flow, bring in developers to map out their systems architecture so we can see what APIs are being called, what data services are brought in, we can bring in product managers to see the end-to-end experience, be able to see what KPIs might track success of a feature and be able to see tangential teams that are related to the work we’re working on.
Losing the forest for the trees
The bigger a product gets, the more difficult it is to see the end-to-end experience. Teams within the same company working on similar problems can often work for months or even years without even being aware of each other and how they overlap.
Communication, clarity, and context are as key to making great products as visual and technical skills. Knowing who to talk to, why you’re working on what you’re working on, how it fits within a bigger product, and what difference it makes to your business and end users helps individuals know that their work matters. I’ve been on teams where people started to mentally check out because their service wasn’t customer facing or they didn’t have good awareness of why they were building what they were.
Call it a failure of leadership, but I also call it a failure of tooling. We build ways of working that make us hyper focused on the detail that we lose the forest for the trees, we lose the character for the costume, the product for the sake of the button.
The details matter, but they don’t only matter. Design tools can help push a bigger view of the journey so we can make products in a way that gives us the birds eye view of every experience and can unify a team around an actual user story.
I’m ready for design tools to put the design of the product first in product design, and experience of the user as the main focus of user experience design.
I’m ready for a tool that helps me focus on the entire flow and narrative of a product and then helps me go deeper into the weeds.
I’m ready for what’s after the canvas.
I design Basedash. Live in Nashville. Check out my work on my website. I occasionally tweet, but most of the time I spend time with my wife. This article is not affiliated with any design products.
DALL·E Prompts and images:
