20

Getting clear user feedback is great. But what do you do with the feedback when different people, or groups of people, want different things?

I have encountered this situation a few times recently.

One example, while testing a new product release: Some users liked the new separate input boxes for x and y coordinates, as the previous version of the software had a single box, with a comma separator. Now they didn't have to type the comma in.

But other users disliked the move to the dual boxes, because it increased the amount of work involved in copying/pasting co-ordinates between boxes.

I'm not asking for a design solution to this single box vs. dual boxes problem :) I'm asking, more generally, what methodology do you employ to arrive at solutions, where there are two or more opposing feature requests with seemingly equal merit?

|improve this question
  • 7
    UX isn't about wants. It's about needs. – DA01 Feb 11 '15 at 17:37
  • 1
    @DA01 - Yup ... users have a hard time differentiating between what a want is versus what a need is. That's our job. Under-promise and over-deliver! – Code Maverick Feb 11 '15 at 22:09
  • 4
    wasn't there an xkcd for that? – ratchet freak Feb 12 '15 at 11:28
  • 3
    See also: bikeshedding – msw Feb 12 '15 at 16:36
  • 1
    For the particular issue mentioned, have a small script that detects a comma, and transfers the string that comes after the coma to the 2nd box, thus allowing users to copy-paste stuff as before – user2813274 Feb 12 '15 at 18:34
16

You can't please everyone

Most changes or additions will leave some people behind. They may catch up later, they may hate you forever. Shoot for net gain in the experience. If you avoid negative feedback, you avoid progress.

It helps to keep a destination in your sights. Focus on an established list of goals for the long term vision of the product and the tactical changes of a sprint or release. Using something like the HEART framework is a good way to keep your UX on track.

Don't ignore the complainers

Take your inevitable complaints seriously and evaluate them for opportunities. Mapping complaints back to your goals will help you decide if you've missed the mark or just need to help bring a subset of users along to the new way.

When you see opportunities in feedback, do a little research. I've found that most complainers love to be heard: follow up with them and do an interview. If you find potential, develop a job story around it and add it to the backlog. When that item fits the goals of a design sprint, you'll roll it in and show that user that you're listening -- as long as you don't take too long ;)

Account for roles and personas when possible

You may notice clear distinctions in the responses that point to persona or role groups. If you can provide an altered view for this group, you may open up a whole new territory for your product. With the flexibility of software and power of hardware today, faceted UX isn't as prohibitive as it used to be.

|improve this answer
  • This is the answer that, in my gut, I felt was the right one based on the question I asked. I agree with the comments that the first thing is to distinguish users' wants from needs; also that there are often innovative ways to meet seemingly different needs. Ultimately, however, sometimes you will just have be decisive and make a call. I love the tip about not ignoring the complainers. Thanks. – Michael Heraghty Feb 12 '15 at 10:05
  • Glad to help, Michael. You're were right to struggle with the decision :) – plainclothes Feb 12 '15 at 16:54
21

Try to distinguish between what users want and how they want it done.

Taking your example above, users wanting one vs. two input boxes is all about the how. The what is being able to paste comma-separated coordinate pairs vs. not having to press comma. (Or, for some users, being able to simply press comma rather than having to click a second input box.)

In the above example you could resolve that in the following way:

  • Implement two separate boxes.
  • When a comma is entered in the first box, transfer focus to the second box
  • Implement copy and paste buttons that will copy the two values to the Clipboard (as comma-separated values) and paste a comma-separated pair from the clipboard, splitting it correctly between both boxes.

Implementations will, of course, vary heavily depending on the situation you're facing. However, many apparent conflicts between requirements will go away when you look at the what/why rather than the how.

|improve this answer
  • This is great advice, and useful (and popular!). I'm choosing a different answer because I was trying to learn (despite the specific example of the boxes) what designers do when they realise they simply can't please all of their users all of their time, no matter how innovative their implementations. – Michael Heraghty Feb 12 '15 at 10:01
3

Accommodate both! In this case, your users told you exactly what they were missing in the old version (in this example, easy copy/paste). So create a new way that meets both sets of requirements.

Generally speaking, say the old way offered Features A and B, and the new way still supported Feature B, lost feature A, but added feature C. Users said they like C but missed A. So design a widget that offers A, B, and C!

In this example, when the user pastes a comma-separated value, you could automatically transfer the part after the comma to the second box. Also, if they are typing in the first box and type a comma, automatically transfer focus to the second box as they continue typing. You can see this behavior in a lot of phone number entries on forms. Perhaps this would satisfy all your users.

|improve this answer
  • 3
    "Accommodate both!" - Sounds like a fast track towards feature creep and bloat! Where is the line drawn in accommodating A-thru-Z? – Evil Closet Monkey Feb 11 '15 at 17:15
  • It certainly can be, but I was assuming that implementing A, B, and C would be governed by requirements planning and might not happen (i.e. you can't please everyone as @plainclothes said) – J. Dimeo Feb 11 '15 at 17:52
  • I like this idea, though it is helkpful only for the paste part, not for copy. Then again, a copy from the OP's interface may be more advisabl efrom other places than the input form ... – Hagen von Eitzen Feb 11 '15 at 21:11
1

I am programmer learning a bit of UX so I may get beat up by UX purest but I capture metrics on user productivity. If a top performing user asks for a tweak I will take that over a low performing user. I am in an environment where contract data entry use more than one product. Too often a low performing user will state the (my) product is the problem. I will show the customer paying the bill that the top 1/4 users are doing over 1/2 work (and they always are) and those are not the people complaining. I am not saying don't accommodate the low end users. But don't sacrifice the high end users. A user that has performed a task twice is going to have in uninformed opinion. Yes make it more intuitive. But the top performer that says it saves me a key stroke is who wins in my book (as that is what the people footing the bill care about with my product).

|improve this answer
  • 1
    How do you define productivity? What if the "top end users" are only "top end" because they have been using it longer and are used to the idiosyncrasies of your system? – user31914 Feb 11 '15 at 23:20
  • 1
    More importantly, there are more "low end" users than "high end" users, and they are the ones more likely to leave. By focusing on the long-standing "top end" you are leaving new users high and dry and they will look for a better tool. – user31914 Feb 11 '15 at 23:21
  • @LegoStormtroopr Come on you have not basis for "idiosyncrasies". As I stated this is "contract data entry". X,Y versus two boxes is two valid paths. I was very clear my contract users are NOT the decision makers - they perform or find another job. The decision makers care about productivity and accuracy and it is very easy to measure. When top performers have more productivity on my product than another that is what counts. – paparazzo Feb 11 '15 at 23:37
  • 1
    So if anyone has has "poor productivity" with your product, you blame the user? – user31914 Feb 11 '15 at 23:38
  • 1
    @LegoStormtroopr It is data entry - one less keystroke is real and measurable. So if you were a football coach and had several players trying out for linebacker that ran the 40 under 4.8 seconds. And three ran it in over 8.0 seconds. If the three blamed it on bad grass would get rid of the players or the ground keeper? – paparazzo Feb 11 '15 at 23:53
0

User Experience isn't about taking exclusive decisions, is about make the overall experience for the majority of users, the best as possible. I will use your use case as an example.

Previous version Single text field, coordinates separated by comma.

Advantages: copy/paste is smooth

Disadvantages: readability

New version Two text fields, one per coordinate.

Advantages: Easy to read, UI cleaner

Disadvantages: copy/paste is trivial and duplicate steps

What is the solution?

The union of the advantages and the exclusion of the disadvantages. You keep two fields, on each field you intercept the JavaScript event "copy" and "paste" and whenever it happens, you "tweak it".

For example, let's call the fields, "field X" and "field Y", if someone select field X and copy it, with JavaScript you create a string that join the value of "field X" and "field Y" and put that in the clipboard, so when user paste it, it would be pasted the coordinates X,Y rather than the single one.

For paste the same, if he paste on X, you split the string if contains an comma and accommodate. So in this case everybody wins.

I could think in more use cases and this could grow, but my point is that you should not focus in solutions as one way, you should focus in have something that satisfied most of the common cases.

|improve this answer
  • I think you've nailed the appropriate guiding principle; one difficulty I can see is distinguishing actions which are intended to select text within one box from those which select text in both. If you drew the boxes in such a way that they appeared as a pair of side-by-side spreadsheet cells and could handle click-drag between, control-right-arrow from the last character of the leftmost cell, control-click in the right cell when the left cell is active, or various other actions as "selecting" both cells, that might work quite nicely, but making that work smoothly on every machine... – supercat Feb 11 '15 at 19:33
  • ...might be hard, especially if some platforms might use different ways of showing that an action is supposed to extend a selection. – supercat Feb 11 '15 at 19:33
  • @supercat I agree with this use case "distinguishing actions which are intended to select text within one box from those which select text in both" but that does not "kill" my suggestion, just means you need to define a component that clearly define that it is not a "normal text input" it is a "coordinates input". That is the way how components are introduced. Numeric stepper started as input, then someone identify common patterns like increase count, etc. and create a component. – Daniel Aranda Feb 11 '15 at 19:53
  • The way your suggestion was worded, it sounded as though if X and Y were 12 and 34, someone who tried to select the text "12" and copy it would receive "12,34". Defining a new type of component rather than using a text input would be good, but can often be deceptively tricky. – supercat Feb 11 '15 at 20:51

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.