Balancing stakeholder needs for UX rookies

Start to end, UX can be a tiring job when designing a quality product. The entire process can involve different people with multiple agendas. It’s all about satisfying your client, your developers and the users, all at the same time.

You must have seen many memes and posts or even experienced the quarrel of a developer and a tester, where they argue over a bug/(supposed)feature. Well, I’d like to break it to them that in such cases, the UX designer is their referee.

A bug decorated by a developer to be seen as a feature

The engagement of a UX designer in a project/product is ideally from the start to the end. Major stakeholders for your project will be:

Clients

It’s their business, their idea too probably and they will want it to work in a particular fashion. The initial aim would be to get accustomed to their brand and fit into their language. Now this is pretty basic, but important that the client needs to have good amount of trust in you as a UX designer so where they try to put in some absurd feature/service, they do take your opinion and expertise in consideration. Or you will have to be strongly convincing them to not put pineapples on a perfect cheese Pizza (nobody would like that!)

There are cases when some clients are not sure enough of what they want. To avoid constant & unnecessary iterations, the UX designer has to act like the staff in Sephora helping to choose just the right concealer for your complexion. Before taking any further steps, you will need to help them make their minds by figuring out what’s the best for them. What is the clutter that you need to clean? and What are the misconceptions they are carrying. Basically, educating the client for the best possible scenario.

YOU?!

That is right. You too are a stakeholder in the project. The most consistent one in fact. When designing, you need to know what technology (and its version) is it going to be developed in. Know your devices. And then all systems go! Inspiration and copying are two different things.

That’s I, when a boring project suddenly turned happening by the use of creative maps!

Developers

Believe it or not, but they are your most precious resource. If they’re done, YOU are done. Because they are the ones making most of the action happen. There isn’t much scope for a problem here unless they haven’t worked with the given programming language before. When making your project timeline, this is the most critical thing you will need to note down.

Note down your developers’ preferences before hand. For instance, some front end devs prefer .svg icons instead of .png. Also, your wireframes and prototypes should be very self-explanatory to avoid miscommunication. For example: If you do not have some content from client side, say an image. Specify a legend for empty content in the design hand off. Now this is not the complete recipe for Developer satisfaction, but effective communication and KPIs are the key to ensure they are getting the right environment, learning experience and resources to achieve the tasks. They would want to work on innovative products that are out there contributing meaningfully to a number of users. When developers say it, it is legitimately not a brag. That they have worked for Uber or Netflix, they might have written a 4 line script (now most non-technical people will think that it is petty) but what it took for them to come up with that 4 lines of script: Deadline in 3 days and that includes weekends, so sleepless nights until we fix that bug that appeared from nowhere and they probably didn’t even initially write that buggy code. Bottom line: your devs rock!

Users

It is the age of User Centred Design. The user is the ultimate goal you, your client and your developers are trying to reach and satisfy. Human Computer Interaction is no more a new field and hence not even very difficult to achieve excellence in. It is always asked not to reinvent the wheel which is very important. We can use the existing cognitive behaviour of people in the way they interact with technology. However, that shouldn’t stop us from taking calculated risks either. User Psychology can be easily understood through personas which can be created even through a simple survey.

Users are the centre point of your entire work. Everything revolves around them.

Now what user preferences are, might sometimes clash with your/your devs’ inconvenience or the client’s budget. So here I shall quote Peggy Carter:

Where you can compromise, you move. And where you can’t, it’s your duty to plant yourself like a tree and say “No, you move”

Elaborating that, you need to know how & how much of an impact each feature has on your users. That will tell you if it’s worth fighting for. The very basic line to convince your clients would be “They will stop using it if don’t find it easy to use”

So it all comes down to them. Adjusting every other stakeholder with keeping the user needs in mind. If there is no way out of it, you can adopt different methods/techniques to achieve the same thing. Alternatives are only a will away.