UX Designers Are Losing a Sprint Every Time They Ask "Is This Feasible?"

"We sent the designs over on Monday. Engineering came back Thursday and said the main interaction isn't possible with the current data model. We had to go back to the drawing board." This is not a rare story. It is the standard design-to-engineering handoff in teams that move fast. The designs are finished. The interactions are polished. The edge cases are handled. Then engineering opens the ticket and the scope negotiation begins — because the designs assumed a system behavior that does not exist.

Nobody made a mistake. The designer designed the right interaction for the user problem. The engineer correctly identified the constraint. The problem is the timing: the constraint was discovered after the design was done, after it had been reviewed, after the sprint that included it had been planned. By the time the answer arrived, the work attached to the wrong assumption had already compounded.

The "is this feasible?" question is not a sign of a bad process. It is a sign of an information gap — a designer making decisions without access to the system constraints that would change those decisions. The gap is real, it is structural, and every team that runs design ahead of engineering validation lives with it.

What "is this feasible?" actually costs

Not a small delay. A designer asking "is this feasible?" on Monday that gets answered Thursday — with a "no" — has just lost a full sprint. The design has to be revised. The revision goes back to engineering for another feasibility check. The sprint planning that already included the original design needs to be reopened. The estimate was wrong. The work goes in the backlog for another cycle.

That is the single-question cost. In practice, a non-trivial feature interaction generates multiple feasibility questions across its design lifecycle. Each one follows the same pattern: post the question, wait for an engineer to have a quiet window to investigate, receive a partial answer, ask a follow-up, wait again. A feature that requires three feasibility checks across its design process can easily consume two full sprint cycles before engineering writes a single line of implementation code.

The "is this possible?" question costs a week at the organizational level — not because the question is hard, but because answering it requires an engineer to stop active sprint work, rebuild the relevant system context in their head, investigate the answer, and translate it back into design language. That process takes an hour of engineering time and three to five days of calendar time. Multiplied across a design team running parallel tracks, it is a chronic throughput drain that does not show up anywhere on the sprint board.

Why the question takes a week to answer

Engineers are not slow to answer feasibility questions because they do not care. They are slow because answering a non-trivial question correctly requires genuine investigation work — and that work gets queued behind active sprint commitments.

"Can we add real-time collaboration cursors to the document editor?" is not a question an engineer can answer in five minutes. Answering it correctly requires understanding the current event store and whether it supports real-time per-session queries, the WebSocket infrastructure and what channels exist and at what granularity, the user session model and whether it tracks document-level context, and the existing collaboration patterns in the codebase that might accelerate or constrain the implementation. None of that is held in any single engineer's working memory. The answer has to be assembled from multiple parts of the codebase.

The investigation itself takes thirty to sixty minutes for a question of that scope. The calendar delay — waiting for the engineer to surface from sprint work, waiting for the response to be seen, waiting for the follow-up to land — adds two to four days on top. The designer waiting on that answer cannot finalize the spec, cannot write the handoff notes, cannot move the ticket forward. The question blocks the work downstream until it is resolved.

What designers are really asking

When a designer asks an engineering feasibility question, they are not asking for an opinion. They are asking for a fact about the current state of the system. The answer exists in the codebase already. It is not ambiguous. It is not a judgment call. It is a question about what is true right now — what the data model supports, what the API shape allows, what the infrastructure can do.

These are concrete questions with concrete answers: "Does the current user model support multiple simultaneous sessions?" — yes or no, the schema says so. "Is there a rate limit on this endpoint that would affect this interaction pattern?" — yes or no, the gateway config says so. "Does the file upload service support chunked uploads?" — yes or no, the service implementation says so. The answer is in the system. The only reason it takes a week is that there is no way for the designer to get there directly.

Designers are not asking engineers to make decisions for them. They are asking the system what it currently supports so they can make better design decisions themselves. The engineer is a proxy for that information — an intermediary between the designer and the codebase — not because that is the right structure, but because it is the only structure that currently exists.

The feasibility question chain — from design to answer:

  Monday 9:00 AM
    Designer finishes the interaction design for the document collaboration feature.
    The key interaction: real-time cursor presence — each user sees where others are editing.
    The design is polished. Edge cases are handled. Prototype is ready.
    Designer posts in #design-eng: "Quick question — does our current data model
      support real-time session presence for document collaboration?"
    (Takes 90 seconds to ask.)

  Monday 2:30 PM
    Engineer reads the message between tasks.
    Mental note: need to look at the document service, the event store,
      WebSocket infrastructure, and the user session model.
    Cannot investigate now — mid-sprint on the notification refactor.
    Cost so far: ~2 minutes of engineer attention, zero answer.

  Wednesday 10:00 AM
    Engineer picks it up during a planning gap.
    Opens DocumentService, EventStore, SessionManager, WebSocketGateway.
    50 minutes of investigation.
    Finds: the event store does not support per-session querying in real time.
      Events are flushed in 5-second batches, not streamed.
      No existing WebSocket channel for document-level presence.
      User session model does not track active document context — only auth state.
    Engineer responds: "Not with the current setup — it would need significant
      infrastructure work, probably 3–4 weeks minimum."

  Wednesday 11:30 AM
    Designer receives the answer. Four days after finishing the design.
    The main interaction is not possible.
    Design has to go back to the drawing board.
    New design will need a new feasibility check.
    Sprint planning that already included this feature must be reopened.
    The estimate was wrong. The work goes in the backlog for another cycle.

  Total elapsed time: 3.5 business days
  Engineering time consumed: ~1 hour
  Design work invalidated: 2–3 days of polished interaction design
  Sprint impact: replanning, re-estimation, cycle slip

The redesign cycle that should not exist

The full loop looks like this: design complete → feasibility question posted → wait three to five days → answer is "no" or "not without significant work" → design revised → new feasibility question → wait two to four days → partial "yes, but with constraints you need to know about" → sprint planning with the revised design → sprint starts → engineer begins implementation and discovers a constraint the feasibility check did not surface → scope change mid-sprint → feature ships different from what was designed.

This cycle is the primary reason features ship differently from what was designed. Not because designers are poor at their craft or engineers are poor at theirs — but because the two disciplines are working with different information at different times. The designer has the user problem and the interaction solution. The engineer has the system constraints. The information never fully aligns before implementation begins, so implementation produces the alignment — by force, mid-sprint, with all the schedule and quality costs that entails.

The redesign cycle that follows a "no" answer is not a small thing. It is not a one-hour revision. A polished interaction design that assumed a real-time event stream and discovers the event store is batch-only has to be rethought from its behavioral foundation. What does the interaction look like when updates are delayed by five seconds? What does the empty state look like? What does conflict resolution look like? These are not cosmetic questions. They require a materially different design — which means another round of feasibility checks before that design can go to engineering.

Types of feasibility questions designers ask that require engineering now:

  QUESTION                               WHAT IT REQUIRES TO ANSWER            CURRENT ANSWER TIME
  ─────────────────────────────────────────────────────────────────────────────────────────────
  "Does the user model support           Check session model schema,            2–4 days
   multiple simultaneous sessions?"      auth service, token handling

  "Is there a rate limit on this         Check API gateway config,              1–3 days
   endpoint that would affect            rate limit middleware,
   this interaction pattern?"            per-endpoint overrides

  "Does the file upload service          Check upload service internals,        2–5 days
   support chunked uploads?"             S3/storage adapter, client SDK

  "Can we add real-time cursor           Check event store query API,           3–5 days
   presence to the document editor?"     WebSocket infrastructure,
                                         session model, flush intervals

  "Is there a notification limit         Check notification service config,     1–3 days
   that would throttle this?"            per-user caps, delivery queue

  "Does the search index update          Check indexing pipeline,               2–4 days
   in real time or with a delay?"        event sourcing lag, cache TTL

  "Can we deep-link to this state        Check routing architecture,            1–3 days
   from a notification?"                 serializable state model,
                                         URL param handling

  Every row: a concrete question with a concrete answer in the codebase.
  Every row: currently routed through engineering as a manual investigation.
  Every row: delaying a design decision that was otherwise ready to ship.

What changes with direct system access

If the designer can query the system directly — in plain language, before the design leaves the design tool — the feasibility check happens during design, not during sprint planning. The question gets answered in minutes instead of days. The constraint is discovered while there is still room to adjust the design without invalidating completed work.

Designer opens a plain-language interface, types: "Does our current event store support querying events by user session in real time?" Gets back: the event model, the flush interval, the query API shape, the existing WebSocket channels, and what would need to change to support real-time presence. That is not a guess. It is grounded in the actual codebase. The designer reads it, adjusts the interaction to use async presence rather than real-time cursors, notes the real-time version as a future milestone with the infrastructure dependency documented, and posts a spec that engineering can actually implement without scope changes.

The sprint that was going to contain the wrong design now contains the right one. Engineering never got interrupted. The feasibility question never entered the queue. Product teams do not need raw access to the codebase — they need answers grounded in it, and they need those answers early enough to act on them without unraveling completed work.

What changes when the designer can query the system directly:

  Monday 9:00 AM
    Designer finishes the interaction design for document collaboration.
    Before posting in Slack, opens Kognita.

  Monday 9:05 AM
    Query: "Does our current event store support querying events by user
      session in real time?"

    Kognita response:
      EventStore: events are written in 5-second flush batches via EventBuffer.flush().
        No streaming API. Real-time per-session queries are not currently supported.
        The query API (EventStore.query()) supports historical lookups by document ID
        and user ID, but not live cursors.

      WebSocketGateway: exists for the notification system. No document-level
        presence channels. Adding document presence would require a new channel type.

      SessionManager: tracks auth state and last-active timestamp only.
        Active document context (which doc, which position) is not stored per session.

      Existing patterns: CollaborationService (in /services/collab/) has a stub
        for multi-user locking — not presence, but similar infrastructure.
        Could be extended rather than built from scratch.

    Designer reads the response.
    The real-time cursor interaction is not feasible as designed.
    Designer revises the interaction before it leaves the design tool:
      - Uses a "last edited by" indicator instead of live cursors
      - Or scopes the real-time version as a future milestone with a clear
        infrastructure dependency noted in the spec

  Monday 9:20 AM
    Designer posts in #design-eng with a scoped spec:
      "Designed the doc collab feature with async presence (not real-time cursors)
       based on the current event store constraints. Real-time version noted as
       a future milestone — would need streaming events + session context tracking."

    Engineering sees a spec that fits the current system.
    No feasibility back-and-forth.
    Sprint planning proceeds with accurate scope.
    No cycle wasted on the wrong design.

  Total elapsed time: 20 minutes
  Engineering time consumed: zero
  Design validated before leaving the design tool

What Kognita gives designers

Kognita is a plain-language dashboard built for non-technical roles. No SQL. No API calls. No reading source code. A designer types a question about system behavior the way they would ask an engineer — and gets an answer grounded in the actual codebase, not in documentation that may be out of date or in an engineer's working memory that may be incomplete.

The Jira integration adds a layer that is specifically useful for designers validating feasibility before sprint planning. A designer can ask what is currently in progress that touches the document service — and see which active tickets might affect what they are designing. If two in-progress tickets both touch the collaboration layer, the designer knows the constraint before the design is finished. Not after the sprint starts. Not after the conflict is discovered mid-implementation.

Non-technical roles across the product team all share the same underlying problem: they are making decisions that depend on system reality, and they have no direct access to it. For designers, the cost is measured in invalidated work and redesign cycles. Kognita gives them the access without the technical overhead — no engineering interruption required, no waiting for a quiet window in someone else's sprint.

The answer time is the key shift. A question that currently takes three to five days because it has to queue behind engineering work takes under two minutes when the system model is already loaded and queryable. That difference — from three days to two minutes — is the difference between a feasibility check that happens during design and one that happens during sprint planning. The first kind prevents wasted work. The second kind discovers it.

Final take

The sprint wasted on the wrong design is not a communication failure. The designer communicated clearly. The engineer answered honestly. The problem was timing and access: the designer needed information that lived in the system, and the only path to that information ran through a person who had other things to do. By the time the answer arrived, the work built on the wrong assumption had already compounded into a sprint-level problem.

This is an access failure, not a process failure. Designers making decisions blind to system constraints will always create friction at the handoff. Give them visibility into what the system actually supports and the friction goes away — not because designers become engineers, but because the right information reaches the right person at the right time.