DEV Community: Clara Hayes

Dark patterns aren't just a design problem — they're often implemented in code without anyone flagging it

Clara Hayes — Wed, 01 Jul 2026 10:25:51 +0000

Worth surfacing for engineering teams specifically: a lot of dark patterns get implemented as a string of small, individually reasonable-sounding tickets — a pre-checked checkbox here, a countdown timer there, a cancel flow that's "just" one extra confirmation step — without anyone stepping back to evaluate the cumulative manipulation across the whole flow.

Aufait UX's research on dark patterns in Indian apps is useful context for engineering teams because it documents how common these patterns have become locally, and ties them to measurable downstream costs: user trust erosion and increasing regulatory scrutiny, not just an abstract ethics concern that's easy to deprioritize under deadline pressure.
A checklist worth building into code review
The practical engineering takeaway: dark-pattern review deserves the same kind of structured checklist treatment as accessibility or security review — a defined step in the process, not a vague hope that someone notices during QA. Specific things worth flagging explicitly during implementation:

Pre-checked opt-ins for subscriptions, marketing emails, or upsells
Asymmetric friction — counting the number of taps/screens for sign-up versus cancellation and flagging any meaningful gap
Countdown timers or "limited stock" indicators that reset or aren't backed by real inventory/time data
Confirm shaming patterns — opt-out copy designed to guilt users ("No thanks, I don't want to save money")
Why this belongs in the engineering process, not just design review
Design reviews catch some of this, but plenty of dark patterns get introduced or amplified during implementation — a "small" engineering decision about default checkbox state, or how aggressively a modal re-appears after dismissal, can turn a borderline pattern into a clearly manipulative one without ever going back through design review.

Relevant for any technical team working with a UI/UX design company on a consumer product where conversion pressure and ethical UX occasionally pull in different directions — which is most consumer products at some point in their growth trajectory.

Read Full article: Dark Patterns in Indian Apps — UX Strategy

A Structured Framework for AI Tool Adoption Across the Design-to-Development Pipeline

Clara Hayes — Wed, 01 Jul 2026 10:07:33 +0000

Everyone Is Using AI. Few Teams Have a Strategy.

Over the past year, AI tools have become part of almost every design and development workflow.

Designers generate wireframes with AI.

Developers use AI to write code.

Product managers use AI to summarize meetings.

Researchers ask AI to analyze interview transcripts.

Yet many teams still face the same problem:

Everyone is using different AI tools in different ways, with no shared process.

The result?

Inconsistent outputs
Duplicate work
Confusion over ownership
Quality issues
Security and compliance concerns

The challenge isn't choosing the "best" AI tool.

It's deciding where AI should—and shouldn't—be part of your workflow.

Through our work at Aufait UX, we've found that successful AI adoption starts with a structured process rather than a growing collection of AI subscriptions.

The Biggest Mistake Teams Make

Many organizations adopt AI one tool at a time.

Someone discovers a new AI design tool.

Another team starts using ChatGPT.

Developers install GitHub Copilot.

Marketing experiments with image generators.

Individually, each decision makes sense.

Collectively, the workflow becomes fragmented.

Instead of improving collaboration, AI creates new silos.

A framework is what turns individual AI usage into a repeatable team process. Organizations that define where humans lead and where AI assists tend to achieve more consistent outcomes than those relying on ad hoc experimentation.

AI Should Support Decisions—Not Replace Them

One lesson became clear while evaluating AI tools across the UX lifecycle:

AI performs best on execution-heavy and repeatable tasks.

Humans perform best where judgment, context, and empathy matter.

*We Tested Several AI Design Tools
*
Instead of asking,

"Which AI tool is the best?"

we asked,

"Which part of the workflow does each tool improve?"

Here are a few observations:

Figma Make

Excellent for quickly generating editable interface concepts and exploring interaction flows.

Best suited for:

Early ideation
Rapid iterations
Collaborative exploration

Less effective when visual refinement or production-ready UI is required.

Uizard

Useful for transforming ideas into polished interface concepts.

Strengths include:

Fast UI generation
Editable mockups
Early usability predictions

Great for visual exploration before detailed design begins.

Mokkup.ai

Purpose-built for dashboard design.

Especially useful when working with:

Data-heavy interfaces
Business intelligence dashboards
Enterprise reporting systems

Its focused approach makes it more effective for dashboards than general-purpose design tools.

Why We Created a Framework Instead of a Tool List

The problem isn't having too many AI tools.

The problem is not knowing who owns what during the product lifecycle.

That's why we developed the HAID Framework a structured approach that maps AI assistance and human expertise across every stage of the UX process
Rather than asking,

"Can AI do this?"

the framework encourages teams to ask,

"Should AI do this, or is human judgment more valuable here?"

*Where Humans Still Matter Most
*
AI can generate screens.

AI can summarize meetings.

AI can write code.

What it still struggles with is understanding context that isn't explicitly available in data.

Examples include:

Why users abandon a checkout flow
Political dynamics inside organizations
Cultural expectations
Accessibility nuances
Business priorities that change over time

These require observation, conversation, and critical thinking.

That's why discovery and validation remain fundamentally human-led activities.

Organizations adopting AI successfully often pair automation with clear human ownership rather than treating AI as a replacement for decision-making.

*Practical Advice Before Adopting Another AI Tool
*
Before introducing another AI platform into your workflow, ask:

Which problem are we solving?
Which stage of our process needs support?
Can the output be trusted without review?
Who is responsible for quality?
Does this reduce work—or simply shift it elsewhere?

Answering these questions first prevents tool overload and encourages more sustainable adoption.

If your team is evaluating how AI fits into product design and engineering, a structured UI Design Services approach can help define where automation adds value without compromising quality.

Final Thoughts
AI is changing how digital products are designed and built.

But successful adoption isn't about collecting the newest tools.

It's about creating a repeatable workflow where people and AI each contribute where they're strongest.

A framework provides that structure.

Without one, AI becomes another collection of disconnected tools.

With one, it becomes part of a scalable design-to-development process.

Why "We'll Figure It Out During Development" Is One of the Most Expensive Mistakes in Software Projects

Clara Hayes — Wed, 01 Jul 2026 09:31:23 +0000

*Every Development Team Has Heard This Before...
*
"Let's just start building."

"We'll figure out the requirements as we go."

On paper, it sounds agile.

In reality, it's often one of the fastest ways to increase development costs.

I've seen projects where a single assumption changed halfway through development. What looked like a small update quickly turned into redesigning screens, rewriting APIs, updating documentation, retesting features, and pushing release dates further away.

The developers weren't the problem.

The code wasn't the problem.

The problem was that the team started building before they fully understood what users actually needed.

Teams that invest time in product discovery before development often avoid this cycle by validating assumptions early. At Aufait UX we've seen how early research and stakeholder alignment reduce costly rework later in the project.

*Why Requirements Change Midway
*
Requirements rarely change because developers suddenly forget how to build software.

Most changes happen because teams discover new information after development has already started.

For example:

A stakeholder forgot an important business rule.
User interviews reveal unexpected behavior.
Compliance requirements appear late.
Edge cases weren't discussed.
Different departments expected different outcomes.

None of these are coding problems.

They're discovery problems.

When these issues appear during development, every change affects multiple teams—design, engineering, QA, documentation, and project management.

That's why late changes are expensive.

*The Hidden Cost Nobody Calculates
*
Imagine your team has already completed:

✅ UI Design

✅ Frontend Development

✅ Backend APIs

✅ Testing

Then someone says,

"Users actually need multiple accounts."

Suddenly you need to redesign:

Authentication
Database structure
User permissions
Dashboard
Notifications
Testing
Documentation

What seemed like a "small requirement" becomes weeks of additional work.

This isn't unusual.

It's what happens when assumptions replace validation.

*Discovery Isn't About More Meetings
*
Some people think discovery means endless workshops and documentation.

Good discovery is actually about reducing unnecessary work.

Instead of asking:

"What features should we build?"

Teams ask:

Who are the users?
What problem are we solving?
How do they complete this task today?
Which assumptions can we validate before writing code?

Answering these questions early usually saves much more time than fixing misunderstandings later.

Organizations that follow a structured UX Design Services approach often uncover these insights before development begins, helping engineering teams work with greater clarity.

A Simple Real-World Example

Suppose you're building an appointment booking system.

Everyone assumes users only schedule appointments for themselves.

Development begins.

Weeks later, user interviews reveal that:

Parents book appointments for children.
Caregivers manage bookings for elderly family members.
Office assistants schedule appointments for executives.

Now the application needs:

Multiple user profiles
Role-based permissions
Shared calendars
New booking flows
Additional notifications

The original design no longer fits real user behavior.

A handful of interviews during discovery could have identified this before a single sprint started.

What Good Discovery Looks Like

Effective discovery doesn't need months.

It simply means reducing uncertainty before investing heavily in development.

A practical discovery process often includes:

Talking to real users
Mapping user journeys
Identifying business goals
Validating assumptions
Prioritizing features based on evidence
Creating low-fidelity prototypes
Testing ideas before implementation

The goal isn't to eliminate every risk.

The goal is to avoid predictable mistakes.

Discovery Helps Everyone

When discovery is done well:

Developers write fewer unnecessary features.
Designers solve validated problems.
QA teams encounter fewer surprises.
Product managers prioritize with confidence.
Stakeholders make decisions based on evidence instead of assumptions.

The result isn't just better software.

It's a smoother development process for everyone involved.

Final Thoughts

Agile doesn't mean skipping discovery.

It means learning continuously while still making informed decisions before investing significant development effort.

Starting development without validated requirements may feel faster during the first sprint.

But the cost usually appears later—in rework, delays, frustration, and technical debt.

Spending time understanding users before writing code is rarely wasted effort.

It's often the reason successful products stay on schedule.

If you'd like to dive deeper into discovery techniques, stakeholder alignment, and requirement validation, this Product Discovery Process Guide explores the process in greater detail.

Why engineering needs to be in the room for UX audit prioritization

Clara Hayes — Wed, 01 Jul 2026 06:57:36 +0000

A pattern worth flagging for eng leads: UX audits frequently fail not because the findings are wrong, but because they get prioritized in a vacuum — without input from the team that has to actually build the fixes.

Aufait UX's piece on enterprise UX audit implementation makes a useful distinction between three problem categories: visibility issues (ambiguous signals, needs more investigation before action), experience issues (clear, observable friction points), and system issues (structural mismatch between the product and how the business runs today). Only the third category typically requires significant engineering investment — meaning audits that don't separate these categories tend to either underwhelm leadership with "minor fixes" or overwhelm engineering with an undifferentiated backlog that's impossible to estimate.

The practical fix

Tie every audit finding to feasibility and business KPI impact before it goes into a roadmap, which requires engineering input at the prioritization stage — not after the roadmap's already locked and stakeholders are expecting delivery dates. The article also notes that a proper enterprise audit goes beyond heuristic evaluation into design system audits and accessibility/compliance review (WCAG, ADA, ISO 9241), which surface different categories of technical debt that a quick UI review won't catch.

What this means for sprint planning

If your team has inherited a UX audit document and is trying to translate it into actual tickets, the visibility/experience/system framework is a genuinely useful first pass: visibility issues probably need a research spike before they're even ticket-able; experience issues can likely go straight into a normal sprint as defined bugs or small features; system issues need to be scoped as their own initiative with proper estimation, not squeezed into a sprint alongside unrelated work.

Relevant for any technical team working alongside a ui ux design agency or user experience design agency on a product that's been live long enough to accumulate real usage data and real friction — which is most products past their first year.
Read Full article Enterprise UX Audit Implementation Strategy

The technical side of ADA compliance that design alone won't fix

Clara Hayes — Tue, 30 Jun 2026 12:37:00 +0000

A lot of accessibility content stops at the design layer — contrast ratios, font sizing, layout. Aufait UX's ADA compliance guide is a useful reminder that a meaningful chunk of WCAG 2.1 AA conformance is implementation-level, not visual.

What needs to hold up in the actual build

Semantic HTML and ARIA roles — screen readers depend on correct structure, not just correct appearance. A visually perfect component built on generic soup will still fail accessibility testing.
Keyboard operability — every interactive element needs to be reachable and usable without a mouse, which often surfaces gaps in custom components (custom dropdowns, modals, date pickers) that look fine but trap focus or break tab order.
Accessible PDFs — frequently shipped as flat scanned documents with zero structure for assistive tech, a compliance gap that's easy to miss because PDFs don't get the same QA attention as the main site.
Video captions and audio descriptions — required for both Section 508 and ADA-aligned compliance, not optional polish, and easy to deprioritize under deadline pressure.

Why automated testing isn't enough

One stat from the piece worth internalizing: automated accessibility scanners typically catch only 30–40% of real barriers. The rest requires manual testing — actually navigating the product with a screen reader, actually tabbing through every interactive flow. Teams that rely solely on a Lighthouse score or an automated scanner are shipping with a false sense of compliance.

Where this fits into the dev workflow

For dev teams working alongside web ui design services, this is a good reminder that accessibility QA needs to happen at the code review level, not just the design review stage — a beautifully accessible Figma file can still ship a non-compliant build if implementation details (focus order, ARIA labeling, semantic structure) get missed during development. Building an accessibility checklist into PR review, the same way teams handle security or performance review, is the practical fix the guide points toward implicitly.

Also worth noting for teams offering ui design solutions to clients: litigation volume around ADA Title III continues to climb year over year, which makes accessibility increasingly a risk-management conversation for clients, not just a design preference.
Read Full guide Website ADA Compliance Guidelines

How an AI design tool stack actually fits into a real product workflow

Clara Hayes — Tue, 30 Jun 2026 10:06:10 +0000

Most "AI in design" content stays at the surface — screenshots of a chat prompt generating a UI. Aufait UX's writeup goes further into the parts that matter for anyone shipping product: how AI output integrates with the actual handoff to engineering.

A few technical details worth flagging for builders:

Output format matters more than the demo Figma Make outputs editable frames, not flattened screenshots — meaning design output stays inside the working file rather than needing to be redrawn from an image. It also generates component code and style references, which speeds up dev handoff considerably compared to tools that only produce static comps.

Model selection isn't a footnote The team uses Gemini 2.5 Pro for complex reasoning-heavy flows, Flash models for fast iteration cycles, and Claude Sonnet when they need a balance of structural logic and creative output quality. Worth remembering that "AI design tool" isn't one undifferentiated category — the underlying model choice changes what you get.

Mokkup.ai exports only as JPEG/PNG — no conversational refinement, no editable component output. Good for early wireframe-level thinking on interactive ui design for data-heavy dashboards specifically, not for anything downstream in the pipeline.

The part most relevant to engineering teams

The case study that stands out: a health-tech R&D platform needing a custom report-generation flow, where the team had already studied Salesforce and Power BI for reference but kept producing designs that either borrowed too heavily from existing patterns or didn't actually reduce interaction load. A prompt synthesizing their research plus design thinking got Figma Make to a structural thread they hadn't considered — which then became the basis for the actual build.

That's a meaningfully different use case than "AI generates a landing page," and it's the kind of example worth referencing when your team is evaluating whether a given AI tool earns its place in a real ux design services pipeline or just adds another revision loop nobody asked for.
The piece also covers a finding that matters for how teams scope AI use generally: a community platform project where field research overturned assumptions an AI personalization model would have shipped on by default — specifically around device ownership patterns in smaller Indian cities. No model flagged it. A researcher in the field did.

For dev and design teams collaborating around ui ux design services, this kind of tool-by-tool, output-format-aware breakdown is more useful than the usual "AI will change everything" framing — it actually tells you where in the pipeline each tool belongs and where it doesn't.
Full breakdown AI in UI/UX Design — Hype vs. Reality