0

So we had a change in client's request, and we need to make userflow changes as well as UI changes. I'm in charge of the UX stuff in the team, including userflow, structure, and design system management. I made wireframe how the new interface would looks like. I used another component that is already in the system, in order to explain the information to user more clearly. However tech team including project manager insisted to use the previous UI component and they think it is sufficient to show information to users. (Which, is confusing at least for me, because the new request from client needs the UI to show more information to user) So I argued that the previous UI component used here were for the old request, but since the new request is different we need to use another component so that there is less chance for users to misunderstand. Well, nobody listened and everybody said I was thinking too much.

Things like this happened so many times, and every time the client went back to us and wanted a better UI for user. (Turned out I was right every time)

I started to think about if I am really bad at this field. I tried to analyze the problem and provide solution in an easy way for both the tech team and the user, but it seems like nobody believes that I am right.

Have you ever met any situation like this? If yes, how do you make sure that everybody listens to you on the point?

1
  • 2
    have you attempted to discuss this issue with your team lead or manager? Mar 24, 2022 at 11:37

6 Answers 6

3

Sounds like you should just describe and design the interface the user needs, and leave the decision making process on how that should be implemented to the tech lead.

Sometimes it may make more sense to modify an existing component than integrate a new component into the structure. There can be compelling technical reasons why this is so.

Also, some people may actually resent being told what to do with someone that has no authority over the situation. You may get better results in just clearly specifying the spec, and allow them to arrive at their own decisions.

1
  • 1
    +1 - I've lost count of the number of times someone has come to my team, who are responsible for the technical design, with a solution rather than a requirement. By all means add a note to the requirement "possibly we could meet this requirement by doing X".
    – deep64blue
    Mar 25, 2022 at 17:14
2

You haven't said if the customer is paying for the change or agreeing to a later delivery.

In the absence of both of those, the engineering team will want to do the least possible work that meets the stated requirement (and nothing else).

That means tacking on a bit of functionality somewhere, not redesigning the user interface.

2

Well, nobody listened and everybody said I was thinking too much.

This is the nub of the problem: who are these nobodies and everybodies? Does everyone in the building really disagree with your proposals, or does it just feel that way?

I think it'd really help to find out what really happens to your ideas, and the only way to do that would be to talk to those in the know, on an informal basis. Reach out to a few people, and in a very low-key way, ask what happened, saying that you'd just like to know for future reference.

You might be surprised at the answers you get; maybe they were concerned (rightly or wrongly) that your approach would result in a lot of additional work using techniques they didn't really understand, or maybe they thought your ideas had a lot of merit, but a senior manager just said "we're not doing that".

If you can get to understand the decision-making process in your workplace, you'll be better placed to influence that process.

1

With the information you provide, the main recommendation is simple, but it will take time: you have to get them to trust your judgment.

To do this, perhaps the following advice can be useful: everything you propose must leave a trail, for example, of emails. In this way, when the client demands corrections that you have already proposed, you resend your previous proposal emails, not saying "I already told you so", but saying "I'm attaching a proposal that was made to solve this problem".

You have to take yourself seriously to be taken seriously.

1

"NO" is a complete sentence. How the heck is it that the project manager and developers are making UI decisions? I'd say that you're more concerned with people liking you than respecting you and your position.

The second that you make a decision and someone else says "i think X is better," and you cave in for not wanting to seem like a jerk, that person has lost respect for you. Don't get me wrong. There are reasons to compromise, but being liked isn't one of them when you prioritize it over delivering a solid product.

Consider taking some courses on being more assertive.

0

but since the new request is different we need to use another component so that there is less chance for users to misunderstand

Stepping into the specifics of development for a brief moment: this does not logically follow.

You don't give the baby a new name because it needs a haircut and because it would be confusing for people to use the original name to refer to a baby with a different haircut. Or, more comically if you're into cars, Porsche has in no way been forced to come up with brand new designs for the 911 just because the engine specs have been upgraded over literal decades. They look the same and no one's getting confused over that.

Based on the quoted snippet, it sounds like you're arguing that changes must be dramatic enough to be blatantly noticeable so as to avoid confusion as to why something would otherwise be subtly different from its previous incarnation.

There are cases where this is a relevant consideration. For example if a company rebrands itself you want to make it visually obvious that this is a new company; even if most of the content remains unchanged.
However, the context of your problem does not seem to warrant explicitly branding itself as different and new.

However tech team including project manager insisted to use the previous UI component and they think it is sufficient to show information to users.

I'm hard-pressed to believe that your entire team is somehow glossing over the existence of the change request. Given the amount of communication there has been on this topic between you, its existence should be blindingly obvious to every involved party; so I'm looking for alternate explanations for this disagreement.
If this is a matter of the entire team being unaware of this change request, that's a much bigger organisational issue than we can solve based on your current question.

Is it possible that there is some confusion here where they think you're saying "we must reuse this exact component" but you in fact mean to say "we can take inspiration from this existing component when redesigning our component"; and similarly that you think they're saying "we should keep the original component exactly as it is", but they in fact mean to say "we should stick with the overall style of the original component when we add some more fields to it"?

Because this would render the disagreement makes much more sense: you want to innovate the style and they don't. Here, you're actually talking about the same topic; whereas in your original description of the disagreement it seems like you're on completely different tracks.

Things like this happened so many times, and every time the client went back to us and wanted a better UI for user. (Turned out I was right every time)

it seems like nobody believes that I am right.

Documentatively, what does the customer do to indicate that they want to make some changes? Is this officially registered? Do they tell you verbally during a meeting?

There is something at odds here. If you are not intended to be the source of the customer's wishes (since your input is allegedly being dismissed); then who is responsible for that? Are they informed of the requested changes? Should they be kept in the loop more? How did they weigh into the conversation where your wireframe was being dismissed by the rest of the team?

I cannot conclude who is to blame here. It's possible that the company is skipping an important administrative step in this process; but it is just as possible that you (in your well-intended eagerness to work for the customer) end up bypassing the necessary administrative steps that the company expects you to take.
For example, the customer may have mentioned this change to you during a meeting, expecting that you would take it up the chain to the PO (or whoever's responsibility it is to coordinate the customer's wishes), but you simply started working on this without keeping others in the loop. This is just an example, since you didn't give us any specifics on how this change was requested.

So how do you approach this kind of disagreement?

When you suspect that you and your team members are disagreeing on a basic principle, it's often hard (if not impossible) for one member to singlehandedly figure out who has misunderstood whom. You need to sit together on this to work through the confusion.

In this case, you could've brought an actual record of the customer requesting the changes that you claim your wireframe incorporates. When and if your team members dispute that claim, don't just balk at it. Ask them for concrete points on which they disagree. What part of your work does not comply with the request of the customer? Could you have achieved the same goal with less effort? How would they go about it?
Based on their answer, both you and them can slowly build up an understanding of each other's understanding, and eventually you will hit upon the key element which you didn't agree on.

Once you know what that key element is; the next step is looking for confirmation on what the correct interpretation is. This can come from documentation (e.g. analysis), or could require direct input from the customer when there is no clear answer available.

You must log in to answer this question.

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