If you’re starting in UI/UX or have been designing for a few years, the difference between average and exceptional often comes down to habits - not tricks. In this article I’ve distilled the seven habits Rohan Mishra shares in his video "The 7 Habits of Highly Effective Designers" into a practical guide you can apply immediately. Each habit includes examples, quick actions you can take, and common mistakes to avoid.

Table of Contents

• Why habits matter
• Quick overview
• 1. Start with why
• 2. Think in systems, not screens
• 3. Show your work early and get feedback
• 4. Always be capturing - build a swipe file
• 5. Ask better feedback questions
• 6. Use real content - not lorem ipsum
• 7. Connect your designs to outcomes
• Bonus habit: Document as you go
• How to adopt these habits (30-day plan)
• Common pitfalls to avoid
• Recap - the habits at a glance
• Who shared these habits
• FAQ
• Final thoughts

Why habits matter

Habits are muscle memory for how you make decisions, collaborate, and ship work. The habits below are not shortcuts - they are repeatable practices that help you design faster, reduce rework, and create impact that stakeholders can measure.

Quick overview

• Start with why
• Think in systems, not screens
• Show your work early and get feedback
• Always be capturing
• Ask better feedback questions
• Use real content, not lorem ipsum
• Connect your designs to outcomes
• Bonus: Document as you go

1. Start with why

Don’t design before you understand the problem. Before you open Figma, pause and ask:

• Why does this problem exist?
• Who has this problem?
• What happens if we do nothing?

Example: a stakeholder asks for a dashboard redesign. Instead of starting with visuals, ask whether users find it confusing, irrelevant, or slow to act on. You may discover the real issue: irrelevant data, not the UI style.

Actionable checklist:

• Write a one-sentence problem statement before any mockups.
• List assumptions and who will validate them (PM, researcher, analytics).
• Decide what "success" looks like for this change.

2. Think in systems, not screens

Design for consistency and reuse. Systems save time for designers and developers and keep products coherent as they scale.

Instead of creating multiple button visuals, build a single button component with:

• Size variations
• States: default, hover, loading, disabled
• Accessible color contrasts and spacing rules

Benefits: fewer design decisions, faster development, fewer UI bugs.

Actionable checklist:

• Create core components (buttons, inputs, cards) before page-level mocks.
• Define usage rules: when to use each variation.
• Document states and edge-cases in your design file.

3. Show your work early and get feedback

It’s tempting to polish before sharing, but early feedback prevents wasted effort. Share sketches, wireframes, or rough prototypes with teammates and users.

Example: while designing a payment flow, Rohan sketched on paper and found a developer-identified technical limitation early - saving hours of rework.

Actionable checklist:

• Share pencil sketches or low-fidelity wireframes with PMs and engineers.
• Use short feedback sessions (15–30 minutes) focused on one or two goals.
• Iterate based on the most critical blockers first.

4. Always be capturing - build a swipe file

Collect UI patterns, micro-interactions, onboarding flows, error messages, and layouts you like. Store screenshots or short recordings in one place so you can reuse and remix them later.

Example: while redesigning an e-commerce journey for an Indonesian startup, referencing patterns from Amazon, Blinkit, Zepto, and Zomato sped up the process and avoided reinventing the wheel.

Actionable checklist:

• Create a simple folder or board to save inspiring screens (categorize by pattern: onboarding, checkout, card, etc.).
• Add a one-line note: why it works and when to use it.
• Review your swipe file before starting a new project to set direction.

5. Ask better feedback questions

Aim for specific, actionable feedback. Avoid "What do you think?" which invites vague responses like "Looks good" or "I don't like it."

Instead, ask targeted questions such as:

• What is the one thing this landing page communicates in five seconds?
• Is the CTA clear and trustworthy?
• Would a first-time visitor know what to do next?

Actionable checklist:

• Prepare 3–5 focused questions before a design review.
• Control the conversation - keep it goal-oriented.
• Capture feedback as "issues" you can prioritize and address.

6. Use real content - not lorem ipsum

Design with realistic data. Dummy text hides real layout problems like long product names, long error messages, or large numbers.

Example: a product card designed with lorem ipsum broke when a real title like "Noise ColorFit Pulse Grand Smartwatch" was used. The card didn't allow for long names.

Why it matters:

• Real content exposes constraints you must design for.
• It avoids last-minute developer fixes or awkward truncation.

Actionable checklist:

• Collect representative data samples (titles, descriptions, numbers) from the product team.
• Design for extremes: very short and very long content.
• Use "realistic" placeholder text when real data isn't available.

7. Connect your designs to outcomes

You’re solving problems - tie design decisions to measurable goals. Each screen should contribute to a metric tied to user success or business impact.

Example: redesigning an onboarding flow increased conversion from 38% to 70%, directly reducing churn and turning interested users into active users.

How to practice outcome-driven design:

• Define 1–2 KPIs for each feature (conversion rate, retention, time to complete task).
• Plan how you’ll measure impact (A/B test, analytics events, cohort tracking).
• Share expected outcomes with stakeholders before implementation.

Bonus habit: Document as you go

Capture decisions, feedback, and iterations during the project - not later. Your brain is for generating ideas, not remembering every detail.

What to capture:

• Design decisions and why they were made
• Feedback summaries and who suggested them
• Rejected options and the reasons for removing them

Why it helps: when you write a case study or explain a decision to stakeholders, you’ll have context and rationale ready.

How to adopt these habits (30-day plan)

1. Week 1: Start with Why - practice framing problem statements for every task.
2. Week 2: Systems & Capture - create 3 core components and start a swipe file.
3. Week 3: Feedback & Real Content - run two early feedback sessions and swap lorem ipsum for real samples.
4. Week 4: Outcomes & Documentation - define KPIs for a small experiment and keep a decision log.

Common pitfalls to avoid

• Jumping straight to UI without clarifying the problem.
• Designing many one-off elements instead of components.
• Waiting to get feedback until the design is polished.
• Using lorem ipsum that hides layout failures.
• Not linking work to measurable user or business outcomes.

Recap - the habits at a glance

• Start with why - define the problem first.
• Think in systems - build reusable components.
• Show your work early - get feedback from teammates and users.
• Always be capturing - build a swipe file.
• Ask better questions - make feedback actionable.
• Use real content - design for real data.
• Connect to outcomes - measure impact.
• Document as you go - keep a record for case studies and context.

Who shared these habits

These habits are from Rohan Mishra (uxcoach). He describes these practices as habits he used to go from junior designer to mentoring and leading other designers.

FAQ

Q: I’m a solo designer - which habit should I start with?

A: Start with "Start with why" and "Use real content." Defining the problem and designing with real data will save you the most time and reduce surprises during development.

Q: How do I get engineers to review early sketches?

A: Schedule short, focused syncs and present one concrete question (e.g., “Can this flow support token-based payments?”). Engineers are more likely to engage when feedback sessions are time-boxed and goal-oriented.

Q: What tool should I use for a swipe file?

A: Use anything that’s easy to update: a shared folder, a Notion board, or the "Community" section of your design tool. The key is consistency, not the tool.

Q: How do I connect designs to outcomes if I don’t have analytics access?

A: Work with your PM or data team to instrument a few events or run a lightweight usability test. Even simple click-through rates or completion-time measurements can show impact.

Q: How often should I document design decisions?

A: Whenever you make a trade-off or receive feedback that changes direction. Daily notes during active projects are ideal; even short bullet points are valuable later.

Final thoughts

Great design is not just about aesthetics - it’s a repeatable practice. The habits above are practical and scalable. Practice them consistently and they’ll become your muscle memory: clearer problems, fewer revisions, faster delivery, and measurable impact.

If you found this helpful, check out the original video from Rohan Mishra for more context and examples.