{20} Atomic Design, Standups & Cognitive Biases
{20} Atomic Design, Standups & Cognitive Biases
Featuring UI Adrian, Tibo, Justin Welsh, Amos, and Matthijs R. Koot
Design: Atomic Design
UI Adrian
I’ve always gravitated to systems that take inspiration from science and biology. It got my attention when Brad Frost started writing about Atomic Design nearly a decade ago. The idea of taking atoms which are your base unit of design, and combining them with other atoms to create more complex design elements resonates with me.
I’ve dabbled with the idea of incorporating Atomic Design a few times. The sticking point has often been determining if something is a molecule, organism, template, or page.
Here’s how I’d simplify Atomic Design:
Atoms - Basic unit of design. (buttons, inputs, toggles, etc.)
Molecules - Reusable combinations of 2+ atoms.
Organisms - Layouts that “come to life” as you insert molecules into slots.
This would reduce the number of concepts a team of designers, developers, marketers, etc. would have to think about from 5 to 3. With that simplification, you make the design more approachable to the broader team and invite cross-functional collaboration.
For some teams, my approach might be overly simplified. For other teams, the original concept might be overly complex. Do what works for you.
Development: Standups
Tibo
I’m happy for the developer who quit her job over daily standups. It’s a manager-friendly practice that sucks the life out of contributors.
The first thing you face in the morning is the potential humiliation of explaining why you didn’t complete an ambitious task list filled with uncertainty because you had the audacity to help a teammate overcome their challenges. Facing that daily incentivizes selfishness, risk aversion, and sandbagging. These are not traits compatible with innovation.
I agree with Tibo, embrace asynchronous work. Build a process that allows people to work when and how they want without forcing regular accountability to a rigid assigned task list. Trust people to shift priorities as their understanding of the problem evolves. Encourage people to put their projects on hold to help work on critical issues or promising opportunities.
Marketing: Strategy
Justin Welsh
My plan today was to share a tweet on multitouch attribution. After scrolling through 50+ tweets repeating, “MTA is the future, but it’s too hard” I decided to abandon that topic for the day.
Seeing Justin’s simple approach to marketing was refreshing.
Solid foundation:
Awareness ☞ Interest ☞ Action
You could break down these steps into a more complex user journey map. But that’s not very useful. You know users will take a winding path from awareness to action. Analyze those paths for insights later. Don’t let complexity block you from taking the first step.
All you really need is a basic framework laying out the path from A to B and a few theories about how you’ll get users through each step. Then start executing. Maybe you’ll find your awareness assumptions were wrong. No problem. Develop new theories and adjust your execution.
Allow complexity to evolve through experimentation. It doesn’t need to be a part of the initial assumptions.
Feedback: Product Tour
Amos
Product tours are always a challenge to get right. Some people are so excited to use your interface that they’ll skip through everything and figure it out on their own. Others will systematically read every word before taking the leap.
I often bias towards minimal intervention because that’s what I prefer when using apps. It’s very easy to project your preferences onto your users. So my approach isn’t always the best.
I avoid immediately showing off every feature and think about the minimal amount of information necessary to help a user along the “happy path”. Ideally, the “value add” features are intuitive enough for people actively looking for that functionality. If not, I’d consider iterating on the design rather than injecting additional messaging.
With this interface, maybe there is a little too much feature hopping and not enough to help the user get from A to B. But it’s hard to tell from a short screencast.
Wildcard: Cognitive Biases
Matthijs R. Koot
Building a product requires you to continually make and test assumptions about how people think. Here are a few examples:
You’re building a game mechanic and need to understand how positive habits are formed.
You’re designing an interface and need to understand how much information to display and how to organize it to maximize retention.
You want to make a compelling argument for someone to buy your product.
No matter what you build, psychology and cognitive biases determine how people perceive and use your creation. This Cognitive Bias Codex shared by Matthijs is worth exploring and periodically revisiting.