Design

Dribbble Broke UX Design

Andres Max

· 11 min read

More flows, less coats of paint.

Back when I started my career as a designer (and founded @ideaware) I remember working countless hours with customers iterating through use cases, personas and flows. What we used to call back in the day User Experience (not sure what that applies to anymore).

The output from those exercises led to clearly defined user interactions that met the desired outcome in the product. Only after this, did we “skin” the product creating visual proposals and ultimately a design system.

I saw this slowly change with the advent of Dribbble.

Dribbble basically became a pissing contest between seasoned and junior designers (I’m guilty of this) on who would create the most popular piece of screenshot.

Screenshots that mean nothing in terms of UX.

So while many experienced agencies and designers have kept digging away in the trenches thinking about how an interface should work, a whole new generation of designers began skipping all of this, focusing on just the visual aspect.

This is why I think Dribbble broke UX design as a practice.

The Evolution: Pre-Dribbble vs. Post-Dribbble Design

When I started in design back in 2006, the process was methodical and user-centric. We’d spend weeks before opening Photoshop or Sketch. The workflow looked like this:

Pre-Dribbble Era (2000-2010):

User research and stakeholder interviews
Persona development based on real user data
User journey mapping
Information architecture
Wireframing and flow diagrams
Usability testing with lo-fi prototypes
Visual design (finally!)
Design systems and component libraries

This process took time. It was unglamorous. You couldn’t screenshot a user flow diagram and get 5,000 likes on it.

Post-Dribbble Era (2010-Present):

Dribbble launched in 2009 and within a few years fundamentally changed how designers worked—and more importantly, how they showcased their work. Suddenly, the most visible designers weren’t the ones solving complex user problems. They were the ones creating the most aesthetically pleasing single screens.

The new workflow became:

Jump straight into visual design
Create pixel-perfect mockups of individual screens
Add trendy elements: glassmorphism, gradients, micro-interactions
Post to Dribbble, collect likes
Skip user testing, flows, and architecture
Wonder why the product doesn’t work in production

The incentive structure changed. Designers were rewarded for beauty, not usability. For individual screens, not complete systems. For following trends, not solving problems.

The Problem: Visual-First Design Thinking

Here’s what happens when you start with visual design instead of user flows:

1. You Solve the Wrong Problems

A designer sees a beautiful banking app on Dribbble with innovative card layouts and glassmorphic elements. They replicate this aesthetic for their own banking app. But they never ask: “What are my users actually trying to accomplish?”

Real user need: “I need to quickly check if my paycheck deposited and pay my rent”

Visual-first solution: “Here’s a beautiful animated dashboard with your spending insights and 12 different card variations”

The visual solution is impressive. It’s portfolio-worthy. It’s utterly useless for the core user need.

2. You Create Frankenstein Products

When you design screen-by-screen instead of flow-by-flow, you end up with disjointed experiences. The signup screen uses one interaction pattern. The dashboard uses another. Settings use a third.

Each screen looks great in isolation. Together, they’re incoherent.

I’ve reviewed hundreds of product designs over the years. The visual-first ones are immediately obvious: beautiful screenshots with no connecting tissue. No thought given to how users move between states, handle errors, or accomplish multi-step tasks.

3. You Ignore Edge Cases

Dribbble-style design encourages “happy path” thinking. Every screen shows perfect data:

Exactly 3 notifications (never 0, never 147)
Profile pictures for every user (never broken images or initials)
Text that fits perfectly (never truncated or overflowing)
Beautiful placeholder content (never real, messy data)

Real products have edge cases. Empty states. Error states. Loading states. These aren’t portfolio-worthy, so visual-first designers ignore them until development.

4. You Can’t Hire Effectively

This is where it really hurts businesses. When I help companies hire product designers, I see the same pattern:

Portfolio: Stunning Dribbble shots, every pixel perfect, trendy aesthetics

Interview question: “Walk me through how you’d design a checkout flow for our product”

Answer: Starts describing button styles, color palettes, and micro-interactions. Never mentions user research, cart abandonment data, or payment method validation flows.

Companies hire these designers expecting UX expertise. They get visual decorators.

The Framework: How UX Design Should Work

Let me walk you through the actual UX design process—the one that produces products people actually use and love.

Phase 1: Understand the Problem (Before Any Design)

Research:

User interviews with 5-10 target users
Competitive analysis (not to copy, but to understand expectations)
Analytics review if updating existing product
Business goals and constraints documentation

Deliverable: Problem statement and user needs document

Example: “Users abandon our checkout 67% of the time on mobile. Interviews reveal they don’t trust entering payment info on mobile, prefer Apple/Google Pay, and get confused by our multi-step process.”

Phase 2: Map the User Journey

Activities:

Map current state (if product exists)
Identify pain points and opportunities
Define desired future state
Create user flows for key tasks

Deliverable: User journey maps and task flows

This is the foundation everything else builds on. If you skip this, you’re building on sand.

Phase 3: Information Architecture

Activities:

Content audit
Card sorting exercises with users
Sitemap creation
Navigation structure definition

Deliverable: IA documentation and navigation flows

Phase 4: Wireframing and Prototyping

Activities:

Lo-fi wireframes (boxes and text, no visual design)
Interactive prototypes in Figma/Adobe XD
Usability testing with 5-8 users
Iteration based on feedback

Deliverable: Validated wireframes and interaction patterns

Notice we’re still not doing visual design. We’re still in black and white, focusing purely on “does this work for users?”

Phase 5: Visual Design (Finally!)

Now—and only now—do we open the paint can.

Activities:

Mood boards and visual direction exploration
Design system creation (colors, typography, components)
High-fidelity mockups applying visual design to validated wireframes
Interaction and animation specifications

Deliverable: Visual design system and production-ready mockups

The key difference: the visual design is applied to flows and structures we’ve already validated. We’re not guessing if it works—we know it works. Now we’re making it beautiful.

Phase 6: Design QA and Developer Handoff

Activities:

Design specifications and annotations
Component library documentation
Developer collaboration on implementation
Design QA during development

Deliverable: Shipped product that matches design intent

Real-World Application: A Case Study

Let me share a specific example from my work at Qrvey, where we were building an analytics dashboard for embedded use.

The Dribbble Approach (What We Almost Did):

Our initial designer came from an agency that prioritized portfolio pieces. They showed us gorgeous dashboard concepts:

Innovative data visualizations with custom animations
Dark mode with vibrant color gradients
Card-based layouts with glassmorphic effects
Beautiful for screenshots, impressive for portfolios

We almost approved it.

The UX-First Approach (What We Actually Did):

Before finalizing, I pushed for user research. We interviewed 12 customers who would embed our dashboards. Here’s what we learned:

They needed white-label capabilities (custom branding)
Their end-users were often non-technical executives
Speed mattered more than visual innovation
They needed export capabilities we hadn’t considered
Mobile responsiveness was critical (not in original design)

We threw out the beautiful Dribbble-worthy designs and started over:

User Research: Interviewed 12 customers, analyzed usage data from beta
Journey Mapping: Mapped out how end-users would access, customize, and export dashboards
Wireframing: Created lo-fi prototypes focusing on white-label customization flows
Testing: Tested with 8 non-technical users (the actual audience, not our customers)
Visual Design: Applied clean, minimal visual design that could be easily re-branded

The final product wasn’t as impressive in a screenshot. But it:

Reduced time-to-value from 2 weeks to 2 days for customers
Achieved 40% higher adoption rate among end-users
Generated 3x more expansion revenue from existing customers

The Dribbble version would have looked better in my portfolio. The UX version actually worked.

How to Evaluate UX Designers in the Dribbble Era

If you’re hiring, here’s how to separate visual designers from UX designers:

Portfolio Red Flags:

Only polished, final screens (no process work)
Everything looks trendy/similar to Dribbble top shots
No user flows, wireframes, or research documentation
No mention of business outcomes or metrics
Perfect placeholder content in every screen

Portfolio Green Flags:

Process documentation showing research through delivery
Before/after comparisons with metrics
Wireframes and flow diagrams
Discussion of design decisions and trade-offs
Evidence of iteration based on user feedback

Interview Questions That Reveal Truth:

Bad Question: “Walk me through this design in your portfolio” (Allows them to rehearse their visual decisions)

Good Question: “How did you validate this design solved user problems?” (Forces them to discuss research and testing)

Bad Question: “What design tools do you use?” (Tools don’t matter)

Good Question: “Walk me through how you’d approach designing [specific feature] for our product. Don’t worry about visuals—just talk through your process.” (Reveals if they think flows-first or visuals-first)

The Working Session Test

Give candidates a real problem from your product:

60 minutes
Whiteboard or Figma
Don’t ask for visual design
Ask them to map the user flow and create lo-fi wireframes

Watch how they work:

Do they ask questions about users and business goals?
Do they start with user needs or visual ideas?
Do they consider edge cases and error states?
Do they think in systems or isolated screens?

This single exercise reveals more than 10 portfolio reviews.

Tools and Techniques for Proper UX

Here are the practical tools I use to keep UX design focused on users, not beauty contests:

For User Research:

Dovetail for organizing research data
Calendly + Loom for async user interviews
Hotjar or FullStory for session recordings
Amplitude or Mixpanel for behavioral analytics

For Flows and IA:

Whimsical or Miro for user flows and journey maps
FigJam for collaborative workshops
Excel/Notion for feature prioritization matrices

For Wireframing:

Figma (use wireframe kits, not high-fidelity components)
Paper and pen (still undefeated for rapid iteration)
Balsamiq for lo-fi mockups if clients need “real” deliverables

For Prototyping and Testing:

Figma for interactive prototypes
Useberry or Maze for remote usability testing
Lookback for moderated testing sessions

For Visual Design:

Figma (only after flows are validated)
Component libraries aligned to design thinking about flows, not decoration

The Path Forward: Reclaiming UX

I’m not anti-Dribbble. Visual design matters. Beautiful interfaces delight users and build brand value.

But beauty without strategy is decoration, not design.

Here’s how we reclaim UX as an industry:

For Individual Designers:

Showcase your process, not just your pixels
Include user flows, wireframes, and research in portfolios
Discuss outcomes and metrics, not just aesthetics
Learn to say “I need to research this” instead of jumping to solutions

For Design Leaders:

Hire for process, not portfolio beauty
Create design systems that prevent one-off visual explorations
Require user research and testing for significant features
Reward outcomes, not Dribbble likes

For Founders and PMs:

Understand that good UX is invisible—it just works
Budget time and money for proper research
Don’t hire designers based on visual portfolios alone
Measure design success by user outcomes, not stakeholder opinions

A nice building needs a structure behind it. Same applies to software products. As designers, we must think first about how a user will interact with a product, and most importantly what outcomes do we want to encourage from using the product.

Apply a nice coat of paint later.

Think user flows first. Understand your users’ goals. Map their journeys. Validate your assumptions with real people. Then—and only then—make it beautiful.

This is how we build products that don’t just look good in screenshots, but actually work in the real world. Products that solve real problems. Products that users love not because they’re pretty, but because they help them accomplish their goals effortlessly.

The next time you see a gorgeous design on Dribbble, ask yourself: “But does it work?”

Because in product design, that’s the only question that matters.

Frequently Asked Questions

How do I evaluate a UX designer’s portfolio if they only show visual designs?

Ask to see their process work. Request wireframes, user flows, research documentation, or case studies that show how they arrived at the final design. If they can’t provide this, they’re likely a visual designer, not a UX designer. In interviews, ask them to walk through their design process for a specific project, focusing on the “why” behind decisions.

What’s the difference between UX design and UI design?

UX design focuses on how a product works—user research, information architecture, user flows, and solving user problems. UI design focuses on how it looks—visual aesthetics, typography, colors, and visual hierarchy. Great product designers do both, but UX must come first. You can’t polish a broken user experience.

Should I hire a designer who specializes in visual design or UX research?

For early-stage products, hire a generalist product designer who can do both UX research and visual design. Specialists make sense at scale (50+ people), but early teams need people who can own the entire design process from user interviews to final pixels.

How long should the UX research and wireframing phase take before visual design?

For a new feature: 1-2 weeks for research and wireframes, then 1 week for visual design. For a new product: 4-6 weeks for research, flows, and wireframes, then 2-3 weeks for visual design. If you’re spending more time on visuals than on understanding user needs, you’re doing it backwards.

What tools should UX designers use for the research and wireframing phase?

Research: Dovetail, Notion, or Miro for organizing findings. Flows: Whimsical, FigJam, or Miro. Wireframes: Figma (low-fidelity mode), Balsamiq, or even pen and paper. The tool matters less than the process. Avoid jumping into high-fidelity design tools too early.

I publish on YouTube and andresmax.com, you can also get my latest posts every tuesday in your inbox by subscribing below 👇