12

How do you handle this?

almost 2 years ago from

I am a novice designer in a small software/app development company. My team uses Adobe XD for interactive prototyping, and after we created a version of the prototype, the sharing link will be sent to the client for the client and his/her teammates/testers/potential users to give feedbacks.

I've ran into the following kind of situation for quite a lot of times. Suppose that there is a P2P transaction app which allows users to send/ask for money to/from others; use cases would be splitting expenses and etc. For both SEND MONEY TO and ASK FOR MONEY FROM function, the users can select people that are already users of this app, or aren't users of this app yet. For the latter, the user will have to input the person's phone number, and the system will tell the user that this person you are trying to send money to/ask money from is not a user yet, then a built-in Share modal will show up and the user should select a method through with the invitation link to the app is sent. In a word, both SEND MONEY TO and ASK FOR MONEY FROM function supports creating transactions between existing users AND non-users, making altogether 4 different user flows.

The time we have for creating the prototype is quite limited, so what we did was we demonstrated only two out of the 4 different user flows: for SEND MONEY TO, we showed the user flow of "designate amount - select a contact (who is already a user of this app) - add some notes - send money" while for ASK FOR MONEY FROM we showed "designate amount - input phone number and selects the user who is not yet a user of this app - select a method from the Share window - request sent".

Feedbacks from testers were incredibly bad - a lot of them were complaining that the Share window is very confusing, they didn't understand why they have to use the Share function to send requests to others and so on.

My question is that, for this kind of situation, should I create every screen that should be there in the prototype in order to provide full interactivity and make testers less confused(which means I have to work overtime to deliver on time)? If not, what would you suggest that I do?

A big Thank You to everyone of you who shares his/her idea.

9 comments

  • Frederick AndersenFrederick Andersen, almost 2 years ago

    When it comes to prototyping ideas with actual users I prefer going the extra mile and sculping out additional pages and micro-interactions, which I typically wouldn't spend time on when presenting layouts, components, and interactions for clients or front-enders.

    As you've already experienced; lack of context and awareness kneecaps the legitimateness of your tests. When dealing with unknowing users map out the entire—or at least the primary—user journey.

    10 points
    • Aizo Shimomi, almost 2 years ago

      Thank you for your comment. Yes, I believe your comment has already covered almost everything I want to say - that is (1) I should present the interactive prototype as detailed and all-covering as possible [because testers won't know if the screens they see are all the screens in the design or part fo them only]; and (2) whatever that's not presented may result in incredible impact on how the users experience the prototype.

      To draw a conclusion from the two points above, a user test prototype has to be detailed, full-interactive and all-covering as possible, or there's no point in running a user test.

      And to draw a conclusion from the above conclusion, I think I should quit this job. This team is just not the right place where people do the real "design".

      0 points
  • Patryk ZabielskiPatryk Zabielski, almost 2 years ago

    If you don't fill the gaps, users will - and it might completely change the context and results.

    7 points
    • Aizo Shimomi, almost 2 years ago

      Thank you. Well said and very precise. Your idea answered my question as a support to the point of view that I already have.

      0 points
  • Cristian MoiseiCristian Moisei, almost 2 years ago

    I'm no expert on the matter but I'll try to share what I know and maybe help point you in the right direction.

    First of all, when doing user research (which is what you're doing), there is no fixed methodology, and it is really up to you and your team to figure out the basics such as:

    1. what is the goal of this research session (what are you trying to learn)
    2. what research methods will get you this information most easily and how do you go about it

    It may seem like common sense but it makes a big difference to have everyone agree on a clear goal and the optimal methods to achieve it. In your case.

    It looks like you were running usability testing (which is a quantitative method, i.e. something dealing with numbers: can users achieve the actions we want them to achieve: 81% could, 19% couldn't, the experience is solid), trying to learn if your UX is solid, and ran into problems that should have been addressed at the quantitative stage (i.e. the stage where you try and learn about the needs of your users, what problems they have and what sort of solution would make sense to them). It sounds like they had concerns about inviting their friends and this should have been identified long before making any prototypes.

    As far as the fidelity of the prototype is concerned, that is again something you need to determine based on what the goal is. If you are going to test for usability, you don't need high fidelity, it could be a bunch of rectangles and text made in Balsamiq or XD, but it has to have all the functionality, because the minute a user clicks on a button that doesn't work, their flow is interrupted and the info they give you becomes infinitely less valuable. I second Frederick's point though, I prefer to go as high fidelity as time allows to have as realistic an experience for the user.

    If you'd like to learn more about research, I recommend: https://www.linkedin.com/learning/paths/advance-your-skills-as-a-user-experience-researcher or, though not as good: Erica Hall's Just Enough Research

    If you'd like to learn more about figuring out design: Mike Monteiro is your man.

    I hope this helps.

    1 point
  • Alex Hazel, almost 2 years ago

    "I want amazing design fast and cheap!" That's not how this works.

    Good design takes money and time. Re-evaluate your business goals and timelines and spend the time to do it right.

    What's more important? Getting a ROI or getting it done?

    https://www.dropbox.com/s/q20gmxm3zsnut8u/2017-12-29.jpg

    1 point
    • Aizo Shimomi, almost 2 years ago

      Well, things I want to clarify first: 1. it's not OUR product. It's our client's product. So it should be the client's business goals - and I believe they are basically wanting to include everything in a MVP. 2. To the client getting a ROI might be more important. They are working on the idea of a product that already has a whole bunch of great competitors and precursors. Personally I don't even think this plan of launching an app is going to success.

      And thank you for the upgraded version of "FAST GOOD CHEAP PICK TWO" diagram. Very useful and confirmed that I should go to look for another job already.

      0 points
  • Surjith S MSurjith S M, almost 2 years ago

    You need a help on a prototype but you did not share any screen. If you provide screenshots (hide sensitive info if any), you will get more response on how you can tackle this.

    1 point
  • Harper Lieblich, almost 2 years ago

    It's hard to tell exactly what went wrong without seeing some examples, but there's a handful of things that might have happened that have nothing to do with the number of supported user flows in your prototype.

    Your test may have worked perfectly. You may have just gotten a bad result because you're design didn't do a good enough job explaining to users why they have to use a share function.

    Your test might be missing some steps Is there a step where the user will realize that the user they're requesting from is not already on the app? They may be confused because you left that step out.

    You may need to give the user more context. You're not always starting a user at first-use. Sometimes your use case assumes the user has been using the app for a while, and they understand the context. You may need to do a better job of describing the situation to the user. "You want to get money from your friend Kate, but you're not sure she already has the app. Can you show me what you might do in that situation?

    I don't believe that usability testing prototypes need to be particularly comprehensive in order to be useful. Most usability issues will present themselves in just a few screens of UI.

    0 points