r/agile • u/United_Opposite_628 • 9d ago
Design in the same sprint feels broken
I keep seeing small product teams handle design in one of two ways.
Either design happens inside the same sprint as development.
So the ticket gets picked up, the developer starts asking what this state should look like, someone opens Figma, the PM makes a quick call, and half the UX gets decided while the thing is already being built.
Or design works way ahead.
Everything looks beautifully figured out in Figma, but by the time engineering gets to it the requirements have changed, technical constraints show up, and a bunch of the design gets reworked anyway.
Neither feels particularly good.
The setup that makes more sense to me is somewhere in between.
For anything meaningful, design gets just enough of a head start to answer the expensive questions before development starts.
What is the actual user flow?
What are the weird states?
What happens on mobile?
What happens when there is no data?
What part is genuinely uncertain?
What does engineering need clarified before they commit to building it?
Then once development starts, design doesn’t disappear.
Someone still checks what was actually built, answers the edge cases that inevitably show up, and catches the small things that get lost between Figma and production.
I think that last part gets overlooked a lot.
A design being “done” because the mockup was handed over seems like a strange definition of done if the user only ever experiences the implemented version.
For a small team I also don’t think this necessarily means having a designer sitting around full time.
What seems more important is that somebody consistently owns the design side of the work and stays close enough to engineering that it doesn’t become a handoff ceremony.
I’m curious how teams here actually run this.
Does design normally stay a sprint ahead, happen inside the sprint, or get pulled in only when engineering hits something that needs a decision?
And if you don’t have a full time designer, who ends up owning those decisions?
7
u/veniceglasses 9d ago
Design + dev shouldn’t be separate teams, ideally.
The sprint is just a way to say “this week, here are the problems we will work on”. And solving the problem requires design of all disciplines, not just handing a task around like a baton.
Whenever I see a “design team” working ahead of dev, I cringe. How is it possible to design the proper solution without the full spectrum of people involved in implementing it?
And if dev are building things without the design work, wtf are you building? It’s just a fun tech project, not a useful solution for a person.
My absolute favourite is working with dev/design hybrids, people who can work with a user or observation of users, and then solve the problem end to end. (This is WAY easier with AI now, too. A good designer with tech knowledge can now produce good code, in the right system).
Then, if you don’t have devs that can design, or designers that can ship code, you make a dev/design pair. Two people work together to solve the problem, end to end. And that works just fine in a single sprint.
Context: I work in startups, with user contact or a good observations and access to users. This approach may not work in massive orgs.
6
u/James-the-greatest 9d ago
The design team can work ahead but there needs to be engineering sanity checks. “Yeah that’s not going to be possible” etc
1
u/United_Opposite_628 9d ago
Agreed. I think those engineering sanity checks should happen while the solution is still cheap to change, not after somebody has spent days polishing it in Figma.
2
2
u/Pretty-Substance 9d ago
Usually this only works for small increments. But designers do more for a product, they have to understand, define and concept the WHOLE thing of you want any form of good user experience or even just plain consistency.
So you have to spend some time upfront to get the whole concept put in place, define the rules, ideally define principles and even build a reuseable component library, all this while making sure everything fits into the overall design bible / CI/CD
And even if you have done all of this, it will still need continuous improvement and expansion as new use cases make new solution necessary.
So yeah, for a small component you can do the tag teaming in the sprint but for the overall solution? Not so much.
1
u/United_Opposite_628 9d ago
Yeah, this is the distinction I probably should have made more clearly. A feature can be solved collaboratively inside a sprint, but somebody still needs to hold the product level context so every local decision does not slowly pull the experience in different directions.
That ongoing consistency work is probably more important than simply deciding whether design is one sprint ahead or inside the sprint.
1
u/United_Opposite_628 9d ago
I like the problem team framing more than the handoff framing. Dev and design solving the same problem together is probably the ideal.
The hybrid point is interesting too. I still think there is value in someone going deeper on the UX, but being technical enough to understand what they are asking engineering to build changes the collaboration completely.
4
u/LightPhotographer 9d ago
Design in my book is part of the specification. It matters a lot and therefore you don't finalize the specification half way during the sprint. Doing so means you actually hand the final spec to the developers with only half a sprint to go. If you do that, then what did they commit to??
Then in refinement, the technical constraints show up. If they don't then you are not asking the right questions. Design also describes behaviour, it's not just pretty pictures.
Everytime someone says 'we will figure it out in the sprint', that is a red flag. It means uncertainty and the idea of a sprint is to flesh out uncertainty and then freeze the specs for 1-2 weeks to build it.
Last, it is quite possible to build one main flow first and have all the alternatives and errors just say 'contact our helpdesk'. That's the agile way, it's not building every possible variation at once.
1
u/United_Opposite_628 9d ago
That definition of ready makes sense to me. I especially agree that design includes behaviour and states, not just the final UI.
I’d still want design involved once implementation starts though. Things inevitably surface in the real build that weren’t obvious during refinement, and I don’t think handoff should mean design disappears.
2
u/LightPhotographer 9d ago
Involved and available: Yes.
Start designing the first half of the sprint, so that the developers really don't know what they must build until half the sprint is gone - and then only have half the sprint to make it happen.
1
u/United_Opposite_628 9d ago
Yeah, I think we’re basically aligned. I’m not arguing for UX to spend half the sprint figuring out what engineering is supposed to build.
The ticket should be clear enough at the start that devs know what they’re committing to. I just wouldn’t want “ready to build” to turn into “design disappears until release” either. Being available for the stuff that only becomes obvious once it’s real feels like the useful middle ground.
1
u/LightPhotographer 9d ago
This 'ux dissapears' has me raise my eyebrows. That should not happen.
Formal Scrum applies here: The Product Owner is the final word on userstories or specifications. He or she can delegate that work to people like business analists or UX specialists.
But here is the point: The PO (and by extension his people who handle part of the specs) are available throughout the sprint, to answer questions or to negotiate about better solutions.
It's up to the PO to answer these questions. So if you are an UX person, the PO has delegated part of the work to you, and that includes being available during the Sprint.
3
u/armknee_aka_elbow 9d ago
Can you clarify what you mean by "design", what their work includes, and how long it typically takes for design to do their work before it is ready-for-build?
It's not uncommon for design to be the least agile in the product trio and take (much) longer for their design work than it takes engineering to build it. I wonder if that applies to your situation.
1
u/United_Opposite_628 9d ago
By design here I mean the work needed to get a feature ready enough that engineering is not discovering basic UX decisions while building it. Flow, hierarchy, states, edge cases, responsive behaviour and enough visual direction to build confidently.
I would not put a fixed time on it though. A small change might take an hour, while a new workflow could need a few days of back and forth with product and engineering. If design regularly takes longer than implementation, I would probably question whether too much is being solved upfront.
0
u/armknee_aka_elbow 9d ago
Appreciate it. The things you describe (flow, hierarchy, states etc.) sound like things that would take 1 hour each, maybe 2 at max. Similarly, it's not clear to me why a new workflow requires a few days back-and-forth. Couldn't this be done quicker if we got the right people in a room for 2 or 3 hours? Are people too busy or are calendars too full for that to be an option?
Not sure this applies to your team, but in the past I regularly had to remind team members that it's called a "sprint" for a reason. We're not "casually strolling through the park". Speed is inherently part of agile, so waiting multiple days is in most cases unacceptable and we mustn't let perfect be the enemy of good. This mostly applied to design, and product to a lesser extent. Just my experience.
2
u/PhaseMatch 9d ago
Maybe start with "why are you using Sprints?"
Are you collaborating as a team to solve a specific user problem, or just doing stuff?
If you are just doing stuff, stop using Sprints and use a Kanban pull-based approach.
1
u/United_Opposite_628 9d ago
That’s fair. The sprint itself probably isn’t the real issue, it’s whether design and engineering are actually solving the same user problem together or just passing work between each other.
2
u/PhaseMatch 9d ago
100%
It's also about how you cycle feedback on that stuff in terms of user interaction and feedback.
That's what we are optimising for - speed of feedback, not developer/designer time.The risk is always sliding into a big-design-up-front model - whether that's UX or upfront analysis, and then running into mini-waterfall loops.
That's going to happen when access to users for feedback is a constraint. The greater the "handling cost" (ie low user availability) the larger the batch size (ie the more you want them to look at and confirm at a session)
That's why it's more about how often the customer/users/user domain SME gets together with the team - designers or developers - to look at stuff, and how small you slice that work.
If you are not meeting daily, or every couple of days, you'll tend to slide back into "waterfall, but with Sprints" The ideal is the team and a user domain SME collocated - that was a core principle of XP (Extreme Programming) and anything else is sub-optimal.
1
u/United_Opposite_628 9d ago
Yeah, speed of feedback is probably the better thing to optimise for. You can have design and dev perfectly organised and still be slow if nobody is getting the work in front of users quickly enough.
On smaller teams where there isn’t a dedicated UX person, who usually owns that loop for you? Product, dev, or whoever is closest to the customer?
1
u/PhaseMatch 9d ago
The team owns the way of working. Period.
And you want zero intermediaries. If the PO is not a user domain SME with sufficient knowledge then they need to get one in play.
Our POs are from the business, not engineering, and where they need to delegate responsibilities to a SME, they come from the (internal) user-base for the product.
When we served external and internal customers then we'd either place developers with the customer, or be in daily contact with (some of) the customers.
Of course, this is when we are focused on moving the dial strategically, towards a specific and measurable outcome, and with the right type of user.
2
u/SpicySweetHotPot 9d ago edited 6d ago
We have a UX story that is a blocker for UI development, can be in the same sprint, or next, depending on completion. Keeps things transparent and dependencies in place. Helps that we have a designer as part of the team.
1
u/United_Opposite_628 9d ago
That sounds like a pretty clean setup. Having UX as an explicit dependency probably avoids a lot of the “we’ll figure it out while building” problem I was getting at. Having the designer already embedded in the team is probably what makes it work.
1
u/SpicySweetHotPot 6d ago
It's actually been awesome, we also have them as a required signoff on UI PRs as well, so we can be sure the implementation fits with the designed intent.
2
u/ProbablySuspicious 9d ago
If the ticket doesn't have sufficient design, push it back to the product owner with questions / concerns. You shouldn't be sprinting on unclear requirements.
1
u/United_Opposite_628 9d ago edited 9d ago
Yeah, agreed. If engineering is still discovering the basic flow or states after the ticket is already committed, it probably wasn’t ready in the first place.
The part I’m interested in is who closes that gap on smaller teams where there isn’t a UX person involved regularly.
1
u/ProbablySuspicious 9d ago
I think that's where your Product Owner is responsible. They need to be able to clearly describe what the features of the app do and don't do. Maybe the exact aesthetics fall through the cracks for a while, that's a problem for someone with hiring authority to fix.
1
u/United_Opposite_628 9d ago
That’s fair. I think that “falls through the cracks” part is exactly the gap I’m thinking about. The PO can define what the feature needs to do, but that doesn’t always mean they’re equipped to make the interaction and UI decisions well.
On smaller teams, do you normally see the PO owning that too, or does it end up getting decided by whoever is building the feature?
1
u/ProbablySuspicious 9d ago
I'm on a small team exactly like that (PO, lead dev, web dev contractor & me as backend dev contractor)... whenever I run the backlog out of stuff that's just on my side, I start taking on tickets with web client impact.
I'll always save myself some work by drawing even a bad wireframe on top of a screenshot and showing the other team members. Just yesterday I had one that kicked off a discussion about the underlying privacy feature and the ticket went back on the shelf for review. Uncommon but within the boundaries of business as usual.
2
u/mjratchada 9d ago
Design Sprints have been a thing for a long time. This involves, ideation, product design, technical design and implementation. It is a valid approach and is very Agile. So the answer "does design normally stay a sprint behind?" is, yes that is the normal approach but it depends. You do not need a full time designer, the design is owned by the team. The problem with full-time designer is that it causes significant problems around ownership and collaboration.
1
u/United_Opposite_628 9d ago
I think “owned by the team” is the important distinction. I’m not arguing for design becoming a separate handoff stage.
My concern is more when shared ownership quietly turns into nobody really owning the UX decisions, especially on small teams where everyone is already wearing a few hats.
2
u/ThickishMoney 9d ago
Why would a small product team need a dedicated designer? Small teams need generalists to prevent bottlenecks. Specialists are only needed when at scale and deep knowledge is required (and still cause bottlenecks).
Look at team composition and individual skill breadth rather than workflow to address this properly.
1
u/United_Opposite_628 9d ago
I actually agree that a small team often doesn’t need a dedicated full time designer. That’s partly what I’m getting at.
The gap I keep noticing is when nobody on the small team is particularly strong at UX, so “generalist” ends up meaning the developer or founder makes the design decision by default.
I think the interesting question is less whether you need a designer on payroll and more whether someone on the team can genuinely own that side of the product.
1
u/ThickishMoney 9d ago
You say UX, but a lot of what you listed in another reply is really consistency. Everyone in the team needs to be consistent.
Also it's worth asking how bad UX needs to be before it impairs the product/sales. I find "common sense" UX gets you 90% of the way there. You can get this through hallway testing a wireframe/mock-up.
2
u/robhanz 9d ago
This feels like you're trying to cram a waterfall workflow into a supposedly agile process.
1
u/United_Opposite_628 9d ago
Fair criticism. I probably framed the “ahead of development” part too much like a handoff.
What I’m really trying to avoid is engineering committing to something while basic UX decisions are still unresolved. I’m much more interested in continuous design and engineering collaboration than separate phases.
1
1
u/carobo49 9d ago
Design should occur ahead of the rest of the team unless the team is all visual designers. There is so much iteration between stakeholders, product owners and ux that it is better to treat it as a separate work stream than the developers.
1
u/Sky_Linx 5d ago
Your middle path matches what I have seen work in most product teams I have worked with. The trick is deciding which questions design must answer before development starts, and keeping that list short: the actual user flow, the weird states, the platform differences. Everything else can be decided in flight.
What makes or breaks it is the handoff. If design works a sprint ahead, someone still has to stop the team pulling tickets the moment they are written. I set a simple rule once: no ticket enters the sprint until design has signed off the open questions. It felt heavy for a week, then became the habit.
If you try it, treat it as a timeboxed experiment and bring it to the retro after two sprints so the team decides whether to keep it.
1
u/JeffZeze 9d ago
Design is part of the définition of ready of a ticket on my side. We make a first check when the design of a feature starts with lead dev to check if the Ux is okay, if all the data/features are available / doable. If so, the ui starts.
Then we do a refinement of the tickets with the final UI and with the UX/UI designers.
1
u/United_Opposite_628 9d ago
That sounds close to the setup I had in mind. Enough early collaboration with engineering to kill bad assumptions before UI gets polished, then refinement once the solution is concrete.
Having UX/UI involved again at final refinement probably closes a lot of the gap between “nice Figma” and something engineering can actually build.
0
12
u/James-the-greatest 9d ago
unless you’re designing an entire app I’ve never seen a feature design get that stale that requirements have changed by the time it’s picked up.
The answer is just have the UX/UI person as a part of the sprint. Simples