Putting People Before Product

A lot of times, while building products, designers, developers & product managers tend to think of the product before the people they are building it for. In short?—?they are building for their convenience and not the user’s.

Almost 2 years into working on software products, here is the most important lesson I have learnt:

Do not blame people when they fail to use your product properly

What we call an error could be bad communication and interaction?—?There is always a reason why the user is reacting to your product in a certain manner.

Introspect, talk to users, test and figure out what could be the reason of the error. This is a simple formula we use at SHEROES, deep diving into problems users face. Here is an example:

86% of our users reported that they never received a response to the jobs that they were applying to. Now, this is clearly a problem arising because of lack of communication from a company’s end. But to think of it?—?the user reported this issue because they expected a reply. Why did they expect this reply? They were making an effort in filling their profile and applying to jobs.

Nowhere did the product communicate to them that they will receive a reply only if their profile is shortlisted or liked by a company. On the other hand, companies aren’t obliged to respond to the candidates who aren’t suitable.

The result?—?lack of replies from companies frustrated users looking for jobs and question the platform’s credibility.

Simple fix?—?A notification to the user when they applied, they will hear from the company only if their profile is relevant. And giving an option to companies to shortlist or reject application. While this is a very ad-hoc solution and we are experimenting with better ways to improve the interaction and communication for this particular solution.

Difficulties people face are signifiers of where you can improve. What might seem like a simple task to a developer or designer, can be a cumbersome task to perform for the user. Another example from SHEROES –

We designed a system to upload events in our backend. Everytime someone uploaded an event, they got confused and lost. The developers assumed it was fairly simple and easy to navigate. We designed it according to what we thought was the correct method whereas it was not a simple to use system for the users. Based on feedback from everyone, it was concluded, what we had earlier accomplished in five screens was possible in one.

Interaction between product and a person can be a collaboration.Machines are machines and human are humans. But behind machines there are humans?—?if building a product think human not machine. A small example?—?replace error messages and warnings with help text. Error and warnings can put down the user. Build a product that understands your user and not the other way round.

While this is something we are working on at SHEROES and still feel we are far from building a product that fully understands our user. But the only way to get there is?—?research your user.