The problem: Me and my teammates (medium level developers) are constantly rewriting interfaces, because leadership is not involving the company designer when making decisions about the UX. They are involved lastly in the process, only after the interface is already done. This causes not only visual changes, but many structure changes too.

I think this is very time and resource wasting as in the best case it takes 1 month to rewrite some interface. Isn't our time as developers the most expensive for the company?

My questions:

  1. Am I right to think the designer should be involved from the start - in the decision making stage?
  2. The leadership does not see a problem in our process. How to make them see it?

Actions by now: We tried to complain durring the process, but mostly we are getting ignored or answered with "Do it this way for now." or "We don't know what we want yet. Do it and we will see."

Additional info: The interfaces are usually very complex, because our company is providing enterprise products to the clients. Usually one UI contains tons of data, different tables, charts, custom views and all kinds of controls you can think of - all depending on each other and on many security rights.
Usually one developer (rarely 2) is assigned to create one UI.

Current process:

  1. Two-three leads/managers decide to create new interface.
  2. They explain the idea to the devs. They do not write specifications, best case is email with some details.
  3. Devs work on the new idea 2 weeks or more.
  4. Meeting - managers don't like what they see (their own decisions) and think of other versions.
  5. Devs work another 1-2 weeks.
  6. Meeting - managers don't like what they see even more and propose third version.
  7. Devs work.
  8. Meeting - managers gets to conclusion the first version was the best.
  9. This repeats and after all managers are satisifed with the interface - the designer is approached.
  10. The designer inspects the project and creates huge document with screenshots with corrections of the whole UI.
  11. Another version of the project is created.
  12. The designer checks it again and after all fixes it gets to production.

UPDATE: I just want to add that meanwhile we have other tasks, often with higher priority (bug fixes for clients, or other client requests). That is why we find this very frustrating as a process and we find it easy optimizable by just using the UX designer in the beginning.

  • 7
    It seems you are missing a prototyping step whern wire frames are prepared and discussed.
    – PM 77-1
    Aug 6, 2019 at 11:41
  • @MisterPositive By "devs work" I refer to everything: functionality + styling / backend + frontend. Also there is no requirements doc - as I said in the best case we have email with some basic instructions. I am not sure how things with the PM work. They appear in some point - sometimes is one of the decision makers, sometimes not.
    – zstefanova
    Aug 6, 2019 at 12:06
  • The craziest thing about this process is that you have a complete UI overhaul that is pushed to production without management sign-off.
    – Elle H
    Aug 6, 2019 at 14:35

3 Answers 3


Am I right to think the designer should be involved from the start - in the decision making stage?

Yes, you are. Most development environments I have worked in to include the designers input in the beginning. Furthermore, their opinion carries considerable weight.

The leadership does not see a problem in our process. How to make them see it?

Besides pointing it out to your manager there isn't much you can do. If your manager cannot convince leadership that there needs to be a change in the development process, you don't have much hope either.

You appear to be working in a very dysfunctional environment. And without a process and or a design document, you will always be aiming at a moving target. This will continue to be very frustrating.

There are some steps as a team you can take to mitigate this:

  1. Follow SOLID design principles. Separate the business logic from the UI in such a way that if a change is made, only the UI is effected.
  2. Document changes to the agreed upon UI yourself (as a team). This way you have some ammo when the Why did this take so long? questions come.

My other advise would be to start looking for another job, as your biggest problem won't be solved by a process or documentation. Your main problem appears that everyone in your chain of command seems to have an opinion on the UI. That by itself is okay, but it appears to over-ride the UI experts (you).

Too many cooks in the kitchen ruins the stew (application in this case) as they say. Especially if the cooks do not have any experience cooking.


We can all talk about what is "typical" or "best" in terms of process or who is involved in decision making, but what it all boils down to is the challenge you expressed here:

The leadership does not see a problem in our process. How to make them see it?

The thing many line-level staff fail to do is understand what motivates leadership. You may have many arguments about efficiency, cost, rework, supportability, or other factors that are important to you, but those things may (legitimately) not be important to your leadership. Or maybe they are, but the leaders are simply ignorant.

So, before you try to make any argument for changing your process, make sure you understand what motivates your leadership. Is it:

  • Ultimate flexibility in the product functionality?
  • Ultimate flexibility in the UI look and feel?
  • Matching the UI look and feel to a certain style, or a certain client's preferences?
  • Making a product that fits a certain client's functional needs?
  • Making a product at the lowest possible cost, no matter what?
  • Making a product that's sustainable for X number of decades, no matter what?

Your concerns about wasting time iterating through design and development may or may not be important factors depending on which of these (or other) things are important to your leaders. If the leaders don't care about "wasting" dev time, or you can't explicitly tie dev time to something they do care about, then you may just come off as whiny and stubborn - not an ideal situation!

So - before you try to come up with your pitch for changing the process, or decide you need to leave that employer, think carefully about how to relate your argument to something you know the leaders care about.

  • 1
    Perfect answer. There probably needs to be a wiki for these types of questions. "My boss is doing X but I don't like it / goes against standards / there is a better way / I have to do more work / costs the company more money" Aug 6, 2019 at 13:08
  • 1
    Also, I would just add, that sometimes leadership do do things that actually do go against their motivations, but to make a good argument, you still have to know what they are. Aug 6, 2019 at 13:09
  • That's a fair point, at the end of the day we're all human and we all contradict ourselves! That said, sometimes "inefficiency" is deliberate because it helps achieve some other goal. A developer is often going to have different motivations than a leader, which may result in a difference in terms of choosing "the best" way to do something. There really isn't a single "best" process, there are just different ways to optimize processes depending on the motivations and goals of the people making decisions. Understanding that is the key.
    – dwizum
    Aug 6, 2019 at 13:16

It sounds like your managers need you to follow an agile software development process, but nobody has actually said that.

There are several versions of "agile" but all are intended to work with incomplete specifications, and a "customer" who will review the product at intervals.

Agile processes generally work on repeated cycles. You produce the minimum product that can be demonstrated, and show it to the "customer". They come back with a list of improvements. You record them, prioritize them, and start working on the highest priority ones, to produce the next version to show the "customer". Repeat the process round and round until the "customer" says it's done.

Agile processes work on the assumption that you will frequently be tearing up old code and re-writing it. You need to follow the best practices to stop that becoming a nightmare.

If other priority fixes come in from outside, add then to the "to do" list.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .