I am a team leader with decent programming background. I learned basics of basics of UI design during my studies, however I am far from being experienced in this field. So please forgive me my ignorance and/or wrong understanding of how things works:)

I am struggling with designing best work flow for my team. Currently we have one sprint where UI/UX designer, who is working on the same feature as rest of the team.

However it seems that this flow is not efficient - planning phase take way to long (and by long I mean it is taking about 1.5-2 days to plan 1 week sprint), and i have feeling that technical talk of developer influences design.

I was thinking about moving to "do the UI/UX work one sprint earlier" approach, however I cannot resolve one issue: On one hand I would like to not influence creative process of UI/UX design by technical details, but on the other hand I am afraid that the designer will end up with things that are too costly to develop (i.e. we currently do not store X in our system, and adding that would add N weeks of additional work) and in the end will be forced to do the work again (=wasted effort).

  • Should UI/UX know about tech details or will they disturb creative process to much?
  • How do you handle that in your environments? Do you have some kind of meeting where UI/UX design discuss proposed solutions with developers?

Best Regards

  • Is the team using a front-end development framework? If so then the technical limitations should be more or less defined already.
    – Michael Lai
    Commented Feb 18, 2020 at 23:07
  • Have a look at Dual-Track Agile. I think that the discovery-track and delivery-track would be the foundation for solving your issue here.
    – Kish
    Commented Feb 19 at 6:06

6 Answers 6


You could always place both the UI/UX designer and a member of the programming team onto the design sprint and keep the rest of the development team on the development sprint. The designer and programmer can work together to develop designs which work within the constraints of your system and can create prototypes and initial versions to test out designs. Those prototypes can then be used in the next development sprint as a starting point to develop from.

It's probably worth rotating which developer is on the design sprint so that the developer is always in the loop regarding the development. You don't want to always use the same developer as they are eventually going to fall behind the rest of the team. If a developer is on the design sprint, they should then be on the development sprint that implements that design so knowledge is shared between both teams.


We find that the solution is an iterative approach.

Yes, UI/UX need to know tech details. They need to know what are the limits there are working within. Does this restrict/influence the creative process? Maybe, a bit, but good designers learn to work and be creative within their restrictions.

So how to handle the tech input without disturbing the creative process?

Approach it iteratively. Have the designers, before tech get hold of it, work to produce some very high level ideas based on investigation/project specs etc. Deliverables on this can be some outlines, some flows, etc; if the designer has some tech knowledge this a good time to make note of possible issues the design may cause to tech.

Once this very high level is completed it is presented to tech along side the project spec requirements. Allow tech to go over it and see what is possible and what is not. Take their feedback and pushback that is based on the designers ideas as well as the project specs and have the designers incorporate that into a more robust design (wireframes etc).

If necessary rinse and repeat. Hope this helps.


This is a very complex question. I don't think there is a "right" answer. Most teams I work with who succeed in this area find their own way that works for their context. However, here are some things every one of them has in common:

  • A painter who doesn't understand paint isn't a painter. You need to understand the medium you are working in. Some designers I've worked with are new to how application design works and they have to learn, others just need to understand the specifics of that app platform, but as a designer you always need to understand your medium

  • Collaboration is key. In some contexts, I can have a UI/UX expert with a little technical knowledge and that is all I need. Other places a good programming who knows enough not to make a terrible looking app is fine. Those places don't have this problem. Where this challenge comes up is when I need a high level of expertise in both and I am very unlikely to find that in one person. And when I need multiple people to work together, I want to chop down as many obstacles between them as possible. So, teams that succeed here, focus on creating a work environment where it is easy and fast for those people to collaborate.

  • UI/UX isn't magic. Just like the designer should know their medium, the technical expert can understand basic design principles. Having a bit of overlap both ways really helps.

  • Design in a dynamic medium is fluid and the techniques the designer uses have to be also. In a magazine or a TV spot, once you create the product, it will always look exactly like you designed it, so get it right the first time. This is untrue for anything electronic. The same website can look many different ways on different screens and browsers. The design you made last week will have to include 2 new elements next week. Successful teams come up with solutions on both the technical and UI/UX side that allow for and embrace this sort of dynamic behavior.


From my experience, I feel that the UI/UX process should be started as the business requirements of the feature are being drafted. In this way, the designer is involved in the process early enough to work in any changes in the requirements and to have the first wireframes ready for review, to head off any unfeasible ideas. This also allows time to explore ideas and solutions.

By the time the feature is ready for the developers to work on, it's too late for design work since the developers are also working on implementation and any changes will only eat into development time.

I feel that the UI/UX team is involved too late in the project and the work we do appears to take up precious sprint time when we only have 2 days to churn out a UI.


As a designer, I have struggled a lot to integrate myself in the idea of a Development Sprint.

In my opinion, in design, a definition of done is much more loose or subjective, while in development it is very precise (does what the story says it should).

That's why I've tried to keep myself outside of the developers' sprints. But my workflow has changed to interact with developers (mostly frontend engineers) on a daily basis, and I will present and discuss with them and a product manager the designs, to make sure that it keeps in mind the technical limitations and it's on the roadmap.

We'll usually try to have design be a couple of weeks ahead of time. We also use design to validate our ideas and see if it's what we want to allow the user to do. So in this regard, the designers take the biggest hit, since there's a lot of back-and-forth and a lot of iterations of the same problem but with multiple solutions. But others (devs + product) seem to appreciate the effort put into unblocking the work of the engineers as much as possible.

In many situations, you might have as well, a designer shared across multiple products (which is the case at my workplace). In that case, it becomes too time consuming to attend all the sprint plannings, retros and stand-ups.


The original Agile manifesto doesnt mention UX, it wasn't really a thing back then, no wonder so many teams struggle to put them together.

From my own experience (10 years UX) it doesn't work to do the UX work within the sprint. What I do instead is work on projects in advance (might take some effort to get to that position) so I have the time to come up with a good design that I have validated. This allows me to design not just a single feature, but look at how different features that are planned will interact and what the best path forward is.

Based on that ideal plan I then sit down with engineers and product owners to figure out how we will deliver that. Usually there are multiple phases and steps involved. Knowing what the end goal is allows us to deliver features faster with less refactoring in the process.

The additional benefit for the business is that we are essentially building version 3 straight off the bat as I will have gone through a number of iterations without using engineering resources. Hence getting to a high quality product faster and cheaper.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.