UXD General Assembly Week 4

Tool: Invision |  Sketch


It is good to start with paper prototyping of your user flows because you will get input from users and if it doesn’t work well, you can rework again because effort in paper prototyping is small(you wasted just a few papers!). It’s ok to start again at early stage rather than discover flaws when you are developing the real product.

In class, we used Invision for the paper prototyping (It’s free!). It is simple to use and it can be downloaded on real device.  It can be shared via sms too! (love this)



Rule No.1

Refrain yourself to explain everything to tester

It is better to clarify to user that you are not the one who build the prototype (in case they are shy to critique in front of owner). I found myself eager to show ways around or explaining to the tester which is a no-no, maybe believes in your product and let them speak for themselves?

Things to look for during usability test-THINK ALOUD testing:

  1. Ease of use – Try asking “What are you looking for?”, “What do you expect?” If tester paused to find what they want, it is something you can take note of. Is your button obvious? Is your text easy to be understand? Sometimes, jargons will confuse user as well
  2. Findability – Is your data in your product in the clear/common hierarchy stack? If your tester wants to find TV but their are two categories: Electronic devices and Home devices, they might need to try their luck to see which category TV falls into.
  3. Open for missing functionality – Sometime tester might suggest things that they think is important to them and it’s something that is good to be included in the product.
  4. Ignore design issue – If tester comments on issue on font size, colour background, “I think it looks nicer if you make this a orange button”..etc, you can ignore these comments at this stage because they are not solid yet so no need to go into that detailed yet.

More on THINK ALOUD testing

Class Demo:

Topic: An app that used when owner needs someone to take care of their pets if they are away for holidays or work.

Useful insight:

It was interesting to notice how things that doesn’t come off from the designer mind is a concern to the tester, like “I would like to have set the time for booking slot as well”or “I want to know if the caretaker has the same kind of dogs of his own so that he’s experienced in taking care my dogs too”.

Katia told us that notice on how the tester looked quiet and concerned when he suddenly got a pay page straight after care taker selection. Something to take note on. Maybe there should be more explanation?


When I interviewed my classmate on my language learning app, she made a statement on some of the word seems need extra interpretation on the meaning.(Etc: Placement test = Test to determine your level) which is a valid point because not every people knows what kind of placement did it meant.

During the usability process, I learned to try not to jump in quickly explain to the tester on what’s the screen does (it’s hard for me, believe me). I asked what did she thought of the page does to see if her understanding matched with my intention.


Invision practice:




Why do we need to pin down on feature even more?

Do one thing really well, not a bunch of things poorly.

Software always goes through iterations and a lot of changes. While you might attempted to show all the features all at one go, a product that comprises of everything does not make everyone happy. So it is better to focus and avoid screw up the whole design.


Dot Voting (preference vote)


image from here

It is better to have people from different background (Finance, Sales, Developer, Designer etc) to vote for the feature based on a goal because this can avoid biased result. Different people has different importance, such as finance people will think of the cost of the project while developer will think from the engineering possibility perspectives. Everyone should vote based on what they think is important.

More on dot voting




  • M: Must have this requirement to meet the business needs (if not failed)
  • S: Should have this requirement if possible, but project success does not rely on it (not a must but is it high value to user?)
  • C: Could have this requirement if it does not affect anything else in the project (Nice to have and to provide better UX)
  • W: Would like to have this requirement later, but it won’t be delivered this time (Low return of investment, need more efforts, less critical)

Based on my language learning app, I focused more on “reading” and “podcast” aspects, therefore some of the feature like self-audio recording and 1-1 support can leave out at this cycle of product design because it’s not the main core feature and it will need a set of flow for grading for audio as well (complicates the system more).

For language selection, on the first stage, it is better to focus on one language first then to expand to other language platform.

More on MoSCoW


Now Next Later


I felt that people might find this method easier to relate but it is even much easier to misuse it. During the class activity, in our group, we had a minimum viable product (MVP model) in mind so now will be the most needed in the project or else user cannot use it at all. We focused on cook and buy according to the list so the delivery service is not critical because the wife needs to settle what to cook and buy problem first.

More on NNL



Apple Magic motion (not bad)



Example of a Product Specification







Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s