Designing for the Busy
How many times do you need to repeat something before you look for a way to hack it?
I sit at my desk with a wide-screen monitor split between a browser window on the right and DevTools on the left. Below the monitor, I swipe back and forth between desktops on my 13” MacBook Pro, often several times a minute, switching between my programming IDE, Sketch, documentation and occasionally Slack. If you were to watch me start my workday, you’d catch me doing this five minutes in.
For years, I’ve worked on refining my personal workflow. Last year, I setup hot-loading which helped me shave off the extra second it took to hit cmd-refresh to preview the latest changes on my browser. It doesn’t seem like much, but if this is a task I repeat every four minutes for a chunk of my day, hot-loading saves me 5 hours a year!
1 reload every 4 minutes, taking on average 1 second -> 1 minute per day, assuming 4 hours of work that need to be previewed -> 5 hours a year.That’s just one example.
I don’t go around doing the math for every wasted second, but I think it’s useful to point out that small improvements cumulate to non-negligible results.
What excites me most as a product designer is that every minute I shave off someone’s routine, they gain one extra minute of freedom — they can use it to do anything…or absolutely nothing.
In the early days of any product, you’re working off educated assumptions. Without real-world feedback, there’s a subtle line between the things that make a process better and the ones that add unneeded complexity. It’s a challenge product designers face all the time. You can easily spend all day questioning your ideas, and sometimes, your entire product.
What gives you the confidence to think what you’re building is worth it?
When designing new experiences, it’s easy to start chasing the wrong ideas. With limited resources, you need to prioritize the right features and set up strict criteria for judging when something is good enough for the public eye. That’s not something anyone should take lightly, especially when what you’re building could affect someone’s paycheck. Here’s the one guiding principle that keeps me in check:
Keep things obvious.
As simple as that sounds, obvious things save time. It’s a fundamental pillar of any good product. If you need to explain a feature, it’s probably a dud.
For your user, the solution should feel as obvious as the problem you’re trying to solve.
Should we be building this?
Is the solution solving for a clearly defined problem? If so, does the solution (or feature) fit into the current experience? If not, what would you have to change to make it fit? Is it worth it?
When is it ready to ship?
Would someone need to explain the feature to the end user? If yes, then there’s more work to be done.
How you answer these questions is highly subjective, but putting yourself in the shoes of the user and simply asking yourself “is this obvious?” is a framework that’s helped me drill down to a clear yes or no answer every time.
Noticing opportunities for marginal improvement keeps the designer in me alive. I’m driven to build things that save people time. It was also our primary motivation when Haishan and I founded Clew.
Both of us are product designers who’ve worked at companies that took different approaches to organize their teams and knowledge, but they both fundamentally wanted to achieve the same thing: Having the right information, available to the right people, at the right time. In practice, this is a time-consuming task that takes coordination from everyone on the team. Our mission was to create an experience that optimized this process from the bottom up.
Here’s one example; most teams use a combination of different SAAS tools like Invision for design, Google Drive and Dropbox for documents, GitHub and Jira for managing code and tasks, and Google analytics and Intercom for analytics and user feedback.
When I work on a project I repeatedly find myself having multiple tabs open; looking at (and for) information from all the different tools we used. Some research suggests employees spend as much as 20% of their time at work looking for information.
What’s the best way to connect all these different tools to one central repository? And if so, how many “Hey can you send me a link to *that* file?” messages can we save? or in other words… when re-engineering this daily task, how many everyday interruptions can we get rid of?
That’s a very abstract definition of the problem. But, the challenge lies within the nitty-gritty of designing a magical interface that hides the complexity and solves the problem in the simplest way possible. The most obvious solution is to build a search tool that lets you search across all these tools at once.
Sticking to the basics and asking ourselves “is this obvious?” about every feature we decide to add has been a fundamental part of our process and we like where it’s taking us. Maybe you will too.
If you enjoyed this read do hit the recommend button and go checkout Clew at https://onclew.com. 😸
