How to convince the leadership into taking designer decision with the designer

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.