18

More precisely: I work in a company that doesn't have any design culture. Some people tend to think a little more in a user-centered way but not the important ones. The Product Manager only cares about the development time, the CEO only cares about business strategy against competitors, and in the end we are never able to put the expected features (asked for by users) above the stategic & market oriented features (defined by CEO/PM).

Let's take an example: a few months ago it was reported to me that users want to see immediately when a message is read or unread. The proposed solution was: "we have to display in bold the name of the message in the list, and when you read it it turns back to regular, but just for you". But then the Lead Developer said that would need a lot of time to do, because we don't actually know when a message have been read and by whom. Since then, the Product Manager has just delayed the feature, again and again, saying that the impact was too low as compared with the time needed to do it. Ultimately, it even became: "we'll probably never do it at all".

So, as a UX designer, how am I supposed to defend users when these people are taking decisions and just look at me like what I'm saying is useless?

  • 4
    "CEO only cares about business strategy against competitors" try to argue that having a great design is a business strategy. Software is replete with examples of a competitor arriving that does nearly the same thing as something already on the market, but with a delightful experience. – msanford Nov 15 '17 at 14:02
7

tl;dr

Present user needs in the context of business outcomes.
If that doesn't work, it's time to find a new job before this one melts down.


Align user needs with business outcomes

Based on your description, it sounds like

  • You've done a good job of expressing the user's desire for the enhancement.
  • The rest of the organization has done a good job of expressing business outcomes.

Given the two in isolation, the business outcome will always win. Especially in an organization that hasn't kept up with the current state product design practices.

Keep the proper structure of product strategy in mind:

Product Vision ➝ Initiatives ➝ Epics ➝ Stories ➝ Tasks

The vision and resulting initiatives will drive everything downstream. If you can't impact things at that level, you'll fail.

Healthy product development roles

In a typical, healthy software organization:
The UX designer would focus on user needs and discovering opportunities in that domain.
The Executive team would focus on market and financial needs and define targets in that domain.
The Product Manager would be responsible for marrying the two, communicating the opportunity to leadership, and prioritizing the backlog accordingly.

In your case, the Product Manager either doesn't have the ability to understand how user and business come together or there's undue pressure to simply accept the Exec team's orders without modification. That's a very bad situation that will lead to failure.

Filling the gap

Before you throw in the towel, try to do the Product Manager's job. Reframe your priorities based on how they'll change your position in the market and provide real returns. Compare the current features to user expectations and how user frustration or lack of usability will cost your users, drive product abandonment, and negatively impact MRR (monthly recurring revenue).

Product decision making framework

I don't remember where I found this, but I've been using it for years and it's an incredibly helpful way to get everyone to understand priorities ...

Decision making framework formula

If you can get the product strategy correctly defined (which may be difficult in your case), the revenue calculation is your next biggest deciding factor. That's hard to estimate and it will certainly be a team effort. You might have to do the legwork to do market research, talk with other department heads (Sales and Ops come to mind), and chat with actual decision makers on the client end. It may not be your job, but it's good experience in the end and it may just save your company's product from impending doom.

Sidebar on the state of your software

If your product doesn't "know actually when a message have been read and by who" and will require "a lot of time to do" I'd venture a guess that it's ready to be rewritten. There's also a good chance you need a new engineering team, or at least a new leader to make that evaluation. Those are tough calls to make, but I've seen a lot of products fail because they were afraid to accept that reality.

Does the Kano model apply?

SPavel references the Kano model's view on satisfaction gains across the three basic feature types: basic, performer, and exciter/delighter. Kano tells us latter two will give you the biggest satisfaction gains, which is often true. Your organization is (knowingly or not) applying this theory. However, the Kano model assumes you already have the minimum requirements in place and your product provides the necessary features of basic usability and function. Application of the Kano model to defend avoiding the basics is gross misunderstanding.

IOW, Kano applies, but not like your organization thinks it does.

Reality check πŸ’” 😬

I think that's all great stuff and it would be smart of you to make the effort. On the other hand, it's incredibly optimistic to think the organization is going to be transformed when you show them the light.

While you're trying to change the world, also start looking for a new job. Changing jobs is often hard, unpleasant, and rarely solves all your problems. But it's not smart to keep sailing on a sinking boat either (read Joseph Conrad's Youth sometime).

|improve this answer|||||
  • 1
    "I believe application of the Kano model to defend avoiding the basics is gross misunderstanding." Absolutely! – Roger Attrill Nov 14 '17 at 19:24
  • 2
    But what if the sum is exactly 12? ;) – Joel Purra Nov 14 '17 at 23:07
  • 1
    @JoelPurra then you leave up to the poor Product Manager who takes the blame in the end anyway. – plainclothes Nov 14 '17 at 23:21
21

In terms of satisfaction, return on "expected features" is very low

Consider this from the PM's point of view - you want to tie up a large amount of engineering time to create a feature that does not make money. All it does is increase usability by some amount - important in principle, but the business outcomes are questionable according to the Kano model.

Chances are that your software is somewhere in the bottom-right quadrant along that green line. It's usable, but not award-winning, NN Group-level usable. This is good enough for the people in charge, and they want to move further along the red line instead because that's how they can make money to pay all your salaries.

enter image description here

Users are only one of your stakeholders

It's a mistake to think that your only responsibility is to the user. It's one of your responsibilities - and you may be the only person in the company with this responsibility - but if you don't learn how to work with all your stakeholders, all features you suggest will be doomed to languish on your hard drive.

For your internal stakeholders, it's not worth it to devote engineering time to marking messages unread...by itself. But there could be a lot of value in knowing which user has read which message. Analytics are a big one. User segmentation is another. If you pitch the engineering effort as "so we can track our users" (huge benefit to the company) instead of "so our users can see what they've read" (dubious benefit to the company) then the bean-counters will look much more kindly upon you.

|improve this answer|||||
  • 15
    I don't think that's quite how the Kano model is meant to be interpreted! The point is that without meeting those basic expectations, users won't even be satisfied, let alone delighted. You can't make a product out of delighters only. The Kano model doesn't suggest that the business outcomes of including basic expectations are questionable! On the contrary, it indicates that the basic expectations are a prerequisite before you can start considering the delighters. They are the 'must-be' qualities that make up a viable product. – Roger Attrill Nov 14 '17 at 19:22
  • πŸ‘† Ditto what @RogerAttrill said – plainclothes Nov 14 '17 at 19:41
  • 3
    @RogerAttrill You can't make a product out of delighters only, but that's not what I'm saying. I'm saying that, if the product has a lot of basic needs satisfied, it may increase user delight more to build more delighters rather than hammer away at the diminishing returns of the few remaining basic needs. – SPavel Nov 14 '17 at 22:00
  • 3
    OK, I exaggerated the 'delighters only' aspect, but the green line on the chart is not a place that the product sits as a whole. You say the software might be in the bottom right quadrant, but the green line is not an accumulation of features. Individual product attributes sit at different places. Even one required basic need, if not implemented can still lead to high dissatisfaction, but if implemented well only leads to satisfaction. It's the greatest points of dissatisfaction that need to be addressed first. Apologies if I'm still mismatching what you want to say & the words I'm reading :) – Roger Attrill Nov 15 '17 at 8:03
7

While this is probably a losing battle and nothing you do will change the outcome, I think you should consider having a conversation with your PM and ask what are the scope of your responsibilities and his/her expectations regarding your work. Obviously, all in a very respectful way and explaining that your question is to optimize the time of the company and not do things that may not be necessary.

That way, s/he will be forced to give you a concrete answer. If s/he tells you that your responsibility is to generate the best possible user experience, then you can document what you want to do, explaining the pros and cons of your decision, and how this change will result in an improvement of the experience of those users. It is very important that you consider your company's competition: if the competition does not do it, you can "sell" it as an exclusive and differential feature.

Now, the user case that you mention seems pretty trivial and in fact it is default in almost any application of messages, so either there is a lack of data in your description, or the problem is another. And unfortunately, if the problem is interpersonal relationships, egos or jealousy, I doubt very much that you can do anything.

In short

Document everything and do your best to explain the cost-benefit differential, talk to your PM, set the scope of your responsibilities. You really can't do much more than this, but this is the least you should do.

|improve this answer|||||
  • 3
    "document everything" is a great rule of thumb - especially if they come back later and say 'our users are leaving us for product x because that product shows when messages are read' – Andrew Martin Nov 14 '17 at 16:15
  • As I understood situation, this is more about priorities than responsibilities. If there was nothing else to do, OPs solution would get implemented – Piro says Reinstate Monica Nov 15 '17 at 5:45
1

I feel the pain, I really do, but in the real world there are many many things that affect the decisions made. Some you can affect, some you can't.

There are two things that can help.

  1. Talk to your colleagues and build relationships. Understand why the decisions are made the way they are. Accept that the lead developer is right about the length of time to implement, but ask her/him if to explain why (I mean really, meaningfully why) so that you can also be better informed around related or similar features. Accept that the PM is making a call on this feature given all the information they have to hand, but find out what that information consists of. Not with a defensive posturing, but seeking to understand the decision process so that you can work with that process effectively for both of you.

  2. Generate evidence. The impact of a feature may have been marked arbitrarily as low, or low for the effort, but what evidence do you have for the contrary. Don't think of it as trying to prove anyone right, just as a presentation of evidence. How many users are asking for the feature. What impact is it having on using the product? How are users venting their frustration? In what context are users asking for this feature. How much time are users wasting looking at already read messages. What impact is it having on the perception of the business or the brand? What are the benefits of this feature other than pleasing these particular users? If you truly believe in this feature (on behalf of your users), you need to collect robust evidence and sell it on. Remember to research that evidence back to credible reliable sources.

In the end you have to choose your battles, but if you're finding every conversation indeed feels like a battle, then you have to consider whether you're in the right place.

--

There is another way for this sort of thing - get the decision makers to use the product themselves. If there really is an unprioritized weak point in the system that is frustrating users, then having the decision makers themselves get frustrated with it might soon get its priority raised!

|improve this answer|||||
0

In such a case, you can increase the value of the feature, by using synergies.

The requested feature is highlighting unread messages, which would be trivial, if you had a way to know which messages are unread. You don't, that's why the feature is expensive.

Is there another feature that benefits from knowing which messages are read by whom and when? Say, internal analytics? Targeted ads? Spam/Bot detection? Debugging?

|improve this answer|||||

Your Answer

By clicking β€œPost Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.