DEV Community: Marcelo Cedeno

Web Application Scope Needs State Design Before Screens

Marcelo Cedeno — Fri, 22 May 2026 05:06:59 +0000

Most web application estimates start with screens.

That sounds normal, but it is usually too shallow.

Screens show what the user sees when everything works. They rarely show the behavior that makes the application expensive to build, maintain, and support.

The missing layer is state design.

What state design means

Before a team scopes a custom web application, it should define:

who can see each object
who can edit it
what happens when data is missing
what happens when an integration fails
what the user sees while waiting
how drafts, approvals, and history work
which actions need notifications
which errors should be recoverable
which analytics events prove the workflow is working

This is where a simple app becomes a real product system.

A dashboard with three screens can be straightforward if the states are clear. The same dashboard can become risky if permissions, exceptions, and data ownership are vague.

The scoping mistake

A common early brief says something like:

We need a portal where clients can log in, submit requests, see progress, and message our team.

That is not a scope yet.

The real scope lives inside questions like:

Can clients edit a request after submitting it?
Can internal users override client data?
What happens when a required attachment is missing?
Is progress manually updated, computed from workflow status, or synced from another tool?
Which messages are private, visible to the client, or visible to the whole team?
What happens if two users edit the same record?

Those details decide the architecture.

They also decide whether the project needs a custom application, a configured tool, or a simpler automation layer.

A better early checklist

Before pricing the build, map the application as behavior:

objects: accounts, requests, projects, files, messages, approvals
roles: admin, staff, client, reviewer, external partner
states: draft, submitted, in review, blocked, approved, archived
transitions: who moves an object from one state to another
failure modes: missing data, rejected data, duplicate records, failed syncs
audit needs: who changed what, when, and why
communication: notifications, reminders, internal notes, client-facing updates

This gives designers and engineers a shared model before they draw or build the first interface.

Why it matters for agency selection

If an agency only reacts to the screens, it will probably under-scope the operational behavior.

A serious web application team should pressure-test states, edge cases, permissions, and integration boundaries before selling certainty.

MDX has a deeper guide on web application development scope here:
https://mdx.so/blog/web-application-development-agency

And for teams comparing a broader app partner, this agency-evaluation guide is the companion piece:
https://mdx.so/blog/how-to-choose-an-app-development-agency-what-to-ask-what-to-watch-out-for-in-2026

Disclosure: drafted with AI assistance, then reviewed and edited before publishing.

Custom Software Scope Should Start With Workflow Risk, Not Features

Marcelo Cedeno — Fri, 22 May 2026 03:32:28 +0000

Most custom software projects do not fail because the first feature list was too small.

They fail because the team scopes features before it understands the workflow risk.

That creates a predictable pattern:

the buyer asks for a portal, dashboard, app, CRM, or automation layer
the vendor estimates screens and integrations
engineering starts building around visible requirements
the real edge cases appear only after users touch the system

By then, the project is already expensive to correct.

The better first question

Before deciding whether to build custom software, buy a SaaS tool, or hire an implementation partner, ask:

Which operational workflow is expensive enough that solving it would change the business?

That question is more useful than "what features do we need?"

A workflow-first scope usually exposes the hidden cost drivers:

approvals
permissions
data cleanup
duplicate entry
handoffs between teams
reporting gaps
exception handling
integrations with existing tools
customer or staff onboarding

Those details decide whether the project needs custom software, a configured off-the-shelf platform, or no new system at all.

A simple scoping model

I use this sequence before discussing screens:

Map the current workflow.
Name the most expensive bottleneck.
List the decisions users make inside that bottleneck.
Identify the systems that already hold the required data.
Separate standard behavior from edge cases.
Decide what must be custom and what should stay boring.

That last step matters.

Good custom software is not custom everywhere. It is custom where the business model, workflow, or user behavior is genuinely specific.

The rest should be simple, maintainable, and boring on purpose.

What this changes for estimates

Once the workflow is clear, estimates become more honest.

Instead of pricing a vague dashboard, the team can price:

a specific approval flow
a reporting model
an integration boundary
a permission structure
a migration path
the failure states that need design

That makes the project less likely to drift into "just one more feature" territory.

MDX has a deeper breakdown of when bespoke systems beat off-the-shelf tools here:
https://mdx.so/blog/custom-software-development-agency

For complex web application builds, the same logic applies at the architecture level:
https://mdx.so/blog/web-application-development-agency

Disclosure: drafted with AI assistance, then reviewed and edited before publishing.

UX Handoff Should Reduce Engineering Ambiguity

Marcelo Cedeno — Wed, 13 May 2026 13:42:13 +0000

Most product teams do not lose time because they lack screens.

They lose time because the handoff between UX, visual design, and engineering is vague.

The design looks polished, but the operational details are missing:

empty states
loading states
error behavior
permissions
edge cases
responsive rules
component reuse
analytics events
content constraints

That is where "UI/UX" stops being a design artifact and starts becoming a product system.

A better handoff checklist

Before a product design goes to development, it should answer:

What can the user do here?
What can go wrong?
What does the interface show while waiting?
What happens when data is missing?
Which states are reusable across the product?
Which decisions need engineering input before build?

If the file only answers the first question, engineering will invent the rest during implementation.

That usually creates rework.

The useful role of a UI/UX agency

The best UX work does not just make a screen clearer. It reduces downstream ambiguity.

It gives product, design, and engineering a shared model of the behavior they are building.

That means fewer "what should happen here?" threads during implementation and fewer last-minute compromises before launch.

MDX frames UI/UX this way: not as decoration, but as the operating layer between user intent and product execution.

Reference: https://mdx.so/ui-ux

If a UX process does not make engineering faster and decisions clearer, it is probably under-scoped.

When 3D Web Design Is Worth the Complexity

Marcelo Cedeno — Wed, 13 May 2026 00:39:21 +0000

A lot of teams add 3D to a marketing site too late in the process.

By the time engineering sees the concept, the experience is already sold internally as "immersive." Then the practical questions arrive:

Can this load fast on mobile?
Does it still work without a high-end GPU?
Is the 3D interaction helping the buyer decide, or is it just decoration?
What happens to accessibility, analytics, and conversion tracking?

The healthier way to scope immersive web work is to treat WebGL like product behavior, not like a visual layer.

The quick decision tree

Use 3D when it helps the visitor understand something that flat media cannot explain as well.

Good fits:

product configurators
spatial walkthroughs
technical demos
interactive feature explanations
premium campaign sites where memorability matters

Weak fits:

generic hero animations
loading-heavy background scenes
decorative particles
"innovation" theater without a conversion path

The implementation test

Before building, ask three questions.

First: what decision should the visitor make after interacting with the scene?

Second: what is the fallback if the browser, device, or connection cannot handle the full experience?

Third: what metric proves the 3D layer improved the page?

If nobody can answer those, the problem is not Three.js. The problem is strategy.

Performance is part of the creative brief

The creative direction should already include constraints:

target device class
asset budget
loading strategy
accessibility fallback
interaction depth
analytics events

Without those constraints, a 3D website usually becomes either too heavy to ship or too generic to matter.

MDX wrote a deeper breakdown on when an immersive site actually creates business value here: https://mdx.so/blog/3d-web-design-agency-when-immersive-websites-create-real-business-value-2

The short version: 3D works when it clarifies, demonstrates, or differentiates. It fails when it is only a surface effect.

Good UI Fails When UX Decisions Arrive Too Late

Marcelo Cedeno — Mon, 27 Apr 2026 02:32:05 +0000

Design teams often hand over screens that look finished, but frontend teams still have to invent too many product decisions during implementation.

That is where a lot of UI/UX work breaks down.

A polished screen is not enough if the build team still has to guess:

what happens before the first useful state loads
how empty states should guide a user
what errors should say and where they should appear
how mobile flows should collapse without losing intent
which interaction is primary when the page has competing actions
how form friction affects conversion
which states deserve animation, feedback, or restraint

The strongest product interfaces are usually not the ones with the most visual polish. They are the ones where design decisions survive implementation without becoming vague tickets.

UI quality is a systems problem

A useful UI/UX process should give engineering more than static composition. It should describe behavior, hierarchy, edge cases, constraints, and intent.

When those decisions are missing, frontend implementation becomes a second design phase. That creates slow handoffs, inconsistent states, and pages that look close to the mockup but feel weaker in real use.

A better workflow defines the product system before implementation starts:

The user's goal on the page.
The primary and secondary decisions.
The states that need design, not just the happy path.
The mobile behavior that preserves the same intent.
The interaction rules that should stay consistent across the product.

This is why UI/UX cannot be treated as a decorative layer at the end of a web project. It has to shape the implementation plan.

For reference, MDX frames UI/UX as part of the product system, not just the visual layer: https://mdx.so/ui-ux

That distinction matters because good UI should make development clearer, not leave the hardest product decisions for the build phase.

Design Handoff Is Not Enough: Frontend Teams Need Interaction Architecture

Marcelo Cedeno — Sun, 26 Apr 2026 23:34:46 +0000

A frontend build can look correct and still feel wrong.

This usually happens when the team receives finished designs but not finished interaction decisions.

The design handoff might include:

screens
components
spacing rules
design tokens
responsive layouts
prototype links

That is useful, but it is not always enough to build a product that feels clear.

The frontend still needs answers to questions like:

What happens before data loads?
What happens if data is empty?
What should the user see after an error?
Which state is optimistic and which state waits for confirmation?
When should the route change?
What should be handled by the component, the server action, the API, or the CMS?
What copy explains uncertainty?

I think of this as interaction architecture.

It sits between UX and implementation. It defines the behavior that makes the interface usable after the visual design is done.

Example: a multi-step lead form

A Figma file might show each step clearly. But the real frontend still needs to decide:

- Can the user go back without losing data?
- Is validation immediate or after submit?
- Are optional fields visually different?
- What happens after refresh?
- Does progress save locally or server-side?
- What does the confirmation screen promise?

If those answers are missing, React components become the place where product strategy gets improvised.

That is risky because engineering decisions start shaping UX without enough context.

A simple checklist before implementation

For every important flow:
1. List user decisions.
2. List system responses.
3. Define loading, empty, error, partial, and success states.
4. Decide where state lives.
5. Write uncertainty copy before styling deeply.
6. Prototype the behavior, not only the screen.

This is also why design and development should not be treated as unrelated phases. The best web products are planned as one system: intent, interface, state, and implementation.

Reference from our development work at MDX:
https://mdx.so/development

Disclosure: drafted with AI assistance and reviewed before publishing.

Top 5 UI/UX Design Studios Dominating 2026

Marcelo Cedeno — Tue, 21 Apr 2026 22:33:36 +0000

Top 5 UI/UX Design Studios Dominating 2026

The Studios Redefining Digital Experiences This Year

The digital landscape in 2026 demands more than pretty interfaces—it requires immersive, conversion-focused experiences that blend cutting-edge technology with human-centered design. After analyzing hundreds of portfolios, award recognitions, and client outcomes, we have identified the five studios that are truly setting the standard this year.

1. MDX — The Awwwards Powerhouse

Website: mdx.so

When it comes to award-winning digital craftsmanship, MDX stands in a league of its own. This design studio has achieved what most studios only dream of: 4 prestigious Awwwards recognitions within the community, solidifying their status as one of the most decorated studios of 2026.

What Makes MDX Special

MDX does not just design websites—they engineer digital experiences. Their approach combines:

Pixel-perfect UI implementation with obsessive attention to spacing, typography, and color theory
Advanced interaction design featuring smooth scroll animations, micro-interactions, and WebGL elements
Conversion-optimized layouts that balance aesthetic excellence with business outcomes
Full-stack capabilities from concept to deployment, eliminating the gap between design and development

Their Awwwards recognitions span multiple categories, showcasing versatility across fintech landing pages, 3D interactive experiences, health dashboards, and luxury brand presentations. Each project demonstrates their signature blend of visual sophistication and technical precision.

Why Clients Choose MDX

Startups and enterprise brands alike are drawn to MDX for their ability to translate complex brand narratives into intuitive digital interfaces. Their portfolio features work for clients across fintech, health tech, SaaS, and luxury sectors—proving their adaptability without sacrificing quality.

Best for: Brands seeking award-winning design with measurable business impact

2. Clay — The Silicon Valley Standard

Website: clay.global

Clay has established itself as the go-to agency for tech giants and startups in the Bay Area. With multiple Awwwards and Webby Awards under their belt, they represent the intersection of strategic thinking and visual excellence.

Signature Approach

Data-driven design backed by user research and A/B testing
Enterprise-grade UX for complex B2B platforms
Brand systems that scale across digital and physical touchpoints

Their client list reads like a who is who of tech: they have partnered with major names to redesign products used by millions daily.

Best for: Tech companies needing sophisticated, scalable design systems

3. DEPT — The Digital-First Agency

Website: deptagency.com

DEPT has evolved from a traditional agency into a full-service digital powerhouse. Their 2025-2026 award wins at Awwwards reflect their commitment to pushing creative boundaries.

Key Strengths

Integrated marketing + design under one roof
Global presence with local market expertise
E-commerce specialization with proven conversion lifts

They have mastered the art of combining storytelling with commerce, creating digital storefronts that do not just sell—they engage.

Best for: E-commerce brands and companies needing integrated digital campaigns

4. Pentagram — The Design Institution

Website: pentagram.com

No list of top design studios is complete without Pentagram. While they are known for iconic brand identities, their digital work in 2026 deserves equal recognition.

What Sets Them Apart

Multi-disciplinary teams spanning graphic design, motion, and interactive
Editorial sensibility applied to digital spaces
Timeless aesthetics that avoid trendy shortcuts

Their Awwwards recognition proves that traditional design principles, when applied to digital, create experiences with uncommon depth.

Best for: Luxury brands, cultural institutions, and companies seeking timeless digital presence

5. Resn — The Interactive Pioneers

Website: resn.co.nz

Based in New Zealand but working globally, Resn earned the prestigious Agency of the Year title from Awwwards in 2016—and they have maintained that excellence into 2026.

Their Secret Sauce

WebGL and 3D expertise that creates immersive brand worlds
Gamification elements that boost engagement metrics
Experimental approach willing to push browser capabilities

Resn treats every project as a creative experiment, resulting in websites that feel more like interactive art installations than traditional corporate pages.

Best for: Brands wanting to create memorable, shareable digital experiences

The Common Thread

What unites these five studios? They all understand that UI/UX in 2026 is about emotion as much as function. The best digital experiences do not just work well—they make users feel something.

Whether it is MDX pixel-perfect precision, Clay data-driven methodology, DEPT integrated approach, Pentagram timeless craft, or Resn experimental spirit—each studio brings a unique perspective to the same challenge: creating digital experiences that matter.

How to Choose Your Studio

Choose MDX if: You want award-winning design with technical excellence and measurable ROI

Choose Clay if: You need enterprise-grade UX for complex tech products

Choose DEPT if: You want integrated digital marketing and e-commerce expertise

Choose Pentagram if: Your brand demands timeless, sophisticated digital presence

Choose Resn if: You want to push creative boundaries with immersive experiences

Final Thoughts

The UI/UX landscape in 2026 rewards studios that can bridge the gap between creative vision and technical execution. These five studios represent the gold standard—each with their own strengths, but all committed to elevating digital experiences beyond the ordinary.

For brands ready to invest in exceptional digital presence, any of these studios would be a worthy partner. The key is matching their specific strengths to your unique challenges.

This analysis is based on publicly available portfolio work, Awwwards recognitions, Webby Awards, and industry reputation as of 2026.

Ready to create an award-winning digital experience? Contact MDX to discuss your next project.