15

We do iterative releases, and thus I see a good number of user UI/UX requirements come in. Which is great so we can focus on the key areas.

Naturally these requests are in the format "The system should have button at place Y that does X". Occasionally this is spot on, but often the suggestion would be a poor way to achieve their actual goal.

I currently resolve this with a conversation where I talk user through context and goals. This works, but has two problems, firstly "unwinding" the user from their fixed idea "But I WANT a BUTTON" and secondly they are being requested to think on the spot about something that is out of the current context which is naturally error prone and also think abstractly which makes a few people slightly uncomfortable.

A search did not find any recommended questions. I have not yet tried a format yet, but want to start with a reasonably high quality set.

So the question is what is a known effective format to prompt users for more insightful UX requirements requests.

I am making the assumption that to affect the changes I want I need to prompt them when they are making the initial report. Our current user base is reasonably well educated white collar office workers.

Some ideas of issue logging form that they would initiate a UI enhancement request with:

Questions or Paragraph

Q. What Goal do you need to achieve?

Q. How are you currently reaching this goal?

Q. How frequently do you do this job?

Q. What change would help you achieve your goal?

Q. Describe impact the change make to you and others?

vs.

Hi, to help us make the best possible UI for you, please take 
a moment to tell us about the Goal you need to achieve. Describe 
what it is, and how you are achieving it today.  What is the 
impact of the current UI on your daily work.

Clarification: Thanks for the genuinely useful responses in having that "unwinding and analysis" conversation. Will use them.

However what I'm trying to encourage is quite narrow, namely get the user thinking more expansively and abstractly about their goals in the first report that they log, before I make contact with them (reading between the lines this may be unrealistic)

  • 6
    Waterboarding sometimes works. – DA01 Apr 29 '15 at 16:12
  • Note: There's probably a reason the user wants the button in that specific place, so make sure to figure out that reason and take it into account. (Most likely, it's where they happen to be when they need to use that feature) – user253751 Apr 30 '15 at 1:01
  • @immibis more likely than where it used to be in the previous application? (no sarcasm, I'm actually asking) – bigstones Apr 30 '15 at 5:56
  • @bigstones No idea, but user familiarity isn't a terrible reason to do things either. (Restated: put things in the places users look for them, if it makes sense) – user253751 Apr 30 '15 at 8:27
  • @immibis True, in a specific case it may be reported where user is when they realise some work is needed. Useful information, agreed. However it may be removed in terms or roles, time or optimal workflow from how (note not necessarily where) it should be handled. – Jason A. Apr 30 '15 at 8:31
9

I've tried to solve this same question in the past. Here's my solution.

Keep it short. Direct them to activities.

  1. Focus the issue with a choice:
    "I'm trying to do something that's not currently possible"
    OR "I'm doing something and the app isn't doing what I expected"
  2. Ask about activities:
    "What were you trying to do when things went wrong?"
    This changes based on the first point and the tone of your app, but you get the idea.
  3. Ask about expectations:
    "What do you want the app to do for you?"
    Same caveats as above.

For example …

enter image description here

13

Resolve the behavioral stumbling block

You make a key observation that it's hard to get users to backtrack from a specific suggestion ("I want this button!") that they are psychologically anchored on.

I agree. You can use reason and charm to get a user off a fixation on a specific UX suggestion, but the effort involved in doing that can result in emotional fatigue, loss of confidence, or at worst, conflict with you as a designer and hatred for the product if the process backfires.

How can we avoid this?

  • A simple observation is, for every problem and its optimal solution, there are a LOT of possible suggestions: enter image description here
  • Therefore, it's simpler to avoid starting with suggestions/requirements and instead start user engagement directly around problems and goals.

    • Starting with suggestions/requirements means you need to backtrack users (right-to-left) back to the problem before progressing with them towards a solution, which is psychologically unintuitive to white-collar workers because their reasonable instinct is to move forward towards a solution, not backwards towards a problem.

    enter image description here

  • This is true even if you are ultimately looking for user suggestions, because if you are able to start users with a problem or goal first, the quality of their resulting suggestions will be better.

What questions provide this starting point?

Here are some that I have used in the past:

  • Does this interface help you work slower or faster? With more accuracy or more errors? With more frustration or less frustration?
  • Where are you wasting the most time with the system?
  • Where are you accidentally creating the most errors?
  • What do you hate most about this interface?
  • What do you like most about this interface?
  • What process would you like us to redesign for you to make it [faster/less painful/less error-prone]?

There are lots of potential questions here, but hopefully the behavioral model may help you tailor a set that suits your situation.

  • 3
    So…UX design is the electric field of a dipole? – wchargin Apr 29 '15 at 15:23
  • That's right! Nice catch, was too lazy to scan in the actual illustration – tohster Apr 29 '15 at 18:43
  • 1
    +1 this is the same thing we learn in game design: users are excellent at finding problems, but terrible at suggesting specific solutions – ashes999 Apr 30 '15 at 13:36
9

This won't fully answer your question since you already included part of the answer in your question :)

For the part where the user (or the client in some cases) insists on "But I WANT a BUTTON", I have some useful techniques:

  • I re-confirm the user/client problem. I shift him/her from proposing solution to identifying the problem. This may require a lot of whys to reach the original problem.
  • I remind the user/client that I am fully responsible for the design solution (after all I studied design for 5 years now to be capable to do that. Sometimes I said these words to him/her).
  • Finally, I remind the user/client that I design for different types of users with different needs. I cannot satisfy every need and doing that will ruin the whole design (if you create personas, you can show him/her how personas will make you focused on the required features). Assure him that you will solve his/her problem regardless the type and look of the solution.

Note: you can always redesign what seems to be a big bug in your design :)

  • 2
    +1 for repeating "Why?" and doing root cause analysis. – Nathan Rabe Apr 29 '15 at 14:30
2

I'm sure this is going to upset several people but here it goes.

I personally believe that this is not a user issue. A user is not going to have insightful UX requirements and this is the reason that there is a need for your expertise.

Even the most educated people, which have used computers for 20+ years, struggle with computers and the internet as a whole so it is a huge first step to even submit a request to you.

When the average computer user raises a question or an issue, you need to be able to hold their hand and observe what they are trying to accomplish. Get them to reveal their problem rather than their perceived solution and then you can calmly say "let me see what I can do". You are essentially experiencing an XY Problem initiated by the user.

Yes, I know you are amazing at what you do from a technical perspective but if you want to hit a home-run then you will need to foster the relationship with your client/user.

  • You just restated the question in your own words. Did you have answer? – plainclothes Apr 29 '15 at 20:49
  • Agree with broad point in answer, and I'm not expecting them to do UX work my terminology may have been misleading. So put another way "How much should I expect the user to self-describe their activities and end products." and indeed, even this seems to be trending to "hardly at all" – Jason A. Apr 30 '15 at 8:38
2

There's two issues here to address: getting a proper understanding of what the suggested change is supposed to accomplish, and avoiding resistance or frustration from the customer because "why are you asking me about the problem, when I've already told you what you need to do to fix it?".

In my experience it is extremely difficult to resolve this well through email. A face-to-face meeting is far more effective for these types of discussions, but a call is still better than asynchronous communication via email.

My general approach to both aspects is to frame it as "I'm looking to clarify the context of this request, so I get it right."

During the conversation, if it is pretty clear what the user thinks this will accomplish, I start with: "To make sure that I understand, I think the problem this would resolve is... insert my guess... and you're looking to try and fix it by... doing something that might work, but which might not be the best way to accomplish it. Is that right?"

This invites discussion, and frequently results in a more natural conversation on the topic.

Try to avoid discussing the proposed solution, and keep the conversation focused on the problem. Make sure you understand what is prompting the request, and how it is negatively impacting their work. Avoid discussing how you are going to address it, unless you can come up with something on the spot that you think might provide some immediate and obvious benefits to the user over their proposed solution (e.g. "A thought just occurred to me... I know we've been talking about adding a 'disable this' button so that you can avoid [situation that causes a problem], but if I could automatically disable the widget so you didn't have to click, would that work, too?"). You may still get a "no", but the chances are much higher that you'll get a detailed explanation as to why that won't work, and therefore gain more context.

After the call, decide how you think the solution should be addressed. If you've decided that you've got a better way than the customer's proposal, you (or the project manager) should draft a brief explanation as to what you plan to do, with a list of the reasons why you chose your solution over the customer's proposal.

It doesn't guarantee that the customer won't come back and say "no, do it my way", but it does significantly decrease the chances of that (especially if the customer proposing the solution isn't the final say in the customer's decision making process).

  • Thanks. Appreciate the specific guidance and will use this. What I'm trying to do is get the user thinking more expansively with the first report that they log, before I make contact them. – Jason A. Apr 29 '15 at 20:24
1

I completely agree with tohster on this issue. What a great response. I'd post this as a comment, but I don't have enough reputation yet.

I've used the "S-T-P" approach, which I see as the core of tohster's solution.

That is, Situation Target Proposal

Situation Start with the current situation. What are you doing today? How are you doing it? What works well that we don't want to lose? What problems are caused and what's the fallout?

Target What does success look like? If we do everything right, what will the process look like when we're done? Does our system give the users autonomy and instant feedback? How are errors caught and identified? What're the sunny day and rainy day scenarios?

Proposal This comes last, and if the first two are done, this should be easier. Usually the hardest of the three. Prioritization happens here. Risk Reward analysis and discussion happens here, too.

Take a look at this article: http://dailykaizen.org/2007/06/19/situation-target-proposal-stp/

0

There are a variety of user interview techniques to extract more insightful requirements.

I am a big fan of Contextual Inquiry in my opinion this is a great way to extract requirements and insight into the users needs that you may not get from a typical Q/A session.

The core premise of Contextual Inquiry is very simple: go where the customer works, observe the customer as he or she works, and talk to the customer about the work. Do that, and you can’t help but gain a better understanding of your customer. You can read more about that from this Contextual Design book

A key concept is building rapport with users. Heres some ways to do it.

  • Tell the users up front that all data collected is de-identified and they are 100% anonymous.
  • Tell them that they will see all the data that you may publish
  • Go to their day to day work environment (dont make them come to your lab or leave their comfort zone)
  • Convince them that they are the expert and you are looking to learn how their workflows take place. I like to say its like a Apprentice Master relationship
  • Remove the formlessness, ie no formal reviews you are just observing and letting them talk while they perform the actions they currently do , or describe what they wish they could do but cant currently.
  • There are different ways to observe , You can try to actually do the task with them (they teach you to see if you understand what they are doing and what they wish they could do), or you can passively sit back and just watch them and take notes. Certain ones are more applicable for different situations.
  • See if you cant observe differences in what people say and what they actually do to find hidden requirements.
  • Try to limit it to 2 hours or so. This makes it less formal and they in general will be less guarded.
  • Be personable, thank them for their time, act grateful even if it could have gone better

After you have requirements

  • Make a flow or sequence diagram. Connect the pieces in order of their workflow.
  • If there seems to be a gap see if you missed something, you may get a oh yeah we have to do xyzzy but i forgot to mention it because its so tedious

Gotchas with User Requirements

  • Be aware when they describe this is what we do as opposed to this is what we normally do. Even though something is a part of the general process do they normally follow all of the pieces or are there missing pieces that they are not describing.

This is a powerful way to extract user requirements but it definitely takes a bit of effort to master, streamline and perfect. Lastly see this article from uxmatters.com in regards to difficulties of contextual interviews.

  • Thanks. I'm a huge fan of Contextual Inquiry. And I'd agree it's a great technique when there is a particularly tricky issue report I can't get high confidence on easily. I don't have bandwidth do a in depth examination of every issue report, thus I trying to get in great information to "triage" reports as effectively as possible. – Jason A. Apr 29 '15 at 17:50
0

(what to ask to get the needs?): As some other experts previously discussed, I also believe in asking 'why'. This is not unique to UX and has been used decades ago in problem solving in general. Requirement books also highlight this and encourage practitioners to ask at least five whys in order to get to the roots of the issue (for which the customer suggested a solution of having a button). This helps you to understand the needs/requirements better and gives the customer/user a chance to realize the actual need behind what he/she is suggesting.

(from potential solution back to the problem): Generic problem solving techniques such as A3 also emphasise a need to understand the problem in depth before suggesting any solutions, which I see in the answer by Tohster. Here the user/customer is focused on the solution but needs to be guided back to the problem area, in order to make more creative and potentially better design solutions possible.

(questionnaire/interviews/observations: Data gathering approaches): I personally am a fan of observations and open-ended interviews in which I can explore the users'/customer's view better. I believe keeping it as a dialog will help both parties to have a better communication, and prevents misunderstandings. Also, I do not suggest using abstract and high-level terms such as 'goals' in such interviews or questions. This might be hard to digest for some people and prevent having a fruitful discussion. Instead, I would go by asking 'why do you think you need a button here?'
If you are forced to use questionnaires then I would suggest using likert scale questions along with open questions to make users think about what they feel about the system now e.g the system supports me in performing all the tasks I need to do every day : strongly disagree --> strongly agree this can then be followed by an open question.

(whose responsibility is this?): I agree that this is the job of the UX expert to hold the customer/user hands and help them explore their needs, instead of wanting them to come up with 'needs' instead of 'solutions'.

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.