0

I am a Front-end developer. I am thinking to make prototype for User Testing of time tracking application.The software has many cases(if/else) like when user import/don't import, skip forms/not,................. hundreds of them. Now I am badly confused. If I try to cover all those cases, then I need help of back-end developer which is ridiculous. That is why it is called prototype.

Please HELP!

Added: Should I implement/include all cases/interactions as mentioned in the UI design. Here is an example of search result: enter image description here

closed as primarily opinion-based by DA01, SteveD, JonW Dec 2 '16 at 11:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Prototype the 20% of the functionality that is going to be used 80% of the time – Andy Dec 1 '16 at 11:14
  • Voting to close this as opinion based as it pretty much is. How much fidelity to put into a prototype depends on dozens of particular factors within your project that we can't possibly know. Furthermore, even the definition of 'prototype' can vary wildly. – DA01 Dec 2 '16 at 6:59
  • @DA01 please have a look at updated question. – Paliza Dec 2 '16 at 7:35
  • @Paliza by cases you mean the names? – UX Labs Dec 2 '16 at 7:36
  • @Paliza user testing would be one of the factors you have control over. What aspects do you specifically have questions about in terms of usability? What are the core functions? I'd start with writing a test script and then have the prototype accommodate the test script. – DA01 Dec 2 '16 at 13:26
1

I do agree, it does not make lots of sense to reach the back-end. In the end, it is a prototype rather than the functioning product.

Remember the main focus is evaluating the experience and the interaction of the product, not the content itself.

If the content plays a major role in the experience of using your product, you have a couple of options:

  1. You can ask your testers to assume that the data is whatever is relevant to their context at the time of the test.

  2. You can produce static content that simulates the real scenarios, which should be sufficient.

From the other hand, if the prototype you are developing is capable of taking the user's input and processing as the real product would, it will increase the accuracy of the user tests, but should not come at a high cost of resources, otherwise, it will defeat the purpose of prototyping.

Good Luck

  • you are right, thanks for answering. Please have a look at updated question. I wrote in panic before. really sorry – Paliza Dec 2 '16 at 6:31
  • I apologize as well @Paliza, your updated question relates to more of internal management decision, there is no right and wrong from UX perspective, you will have to communicate with the UX team and find what is reasonable to do. – UX Labs Dec 2 '16 at 7:31
  • Well, it looks I'm not asking right question. So the question is slightly modified. Please have a look. – Paliza Dec 2 '16 at 7:38
  • @Paliza the cases/interactions you are referring to are the list of names? – UX Labs Dec 2 '16 at 7:39
0

Typically functional prototypes shouldn't be complex at all, and they shouldn't cover all cases, only the most major case(s). There reason is for exactly what you said: complex applications take time to build and unless they want a finished version, there prototype shouldn't be coded whatsoever. Instead something like Axure should be used to include the functional pieces. Otherwise you're doing too much and missing the point.

  • you are right, we've already gone through wireframe phase. Please have a look at updated question. I wrote in panic before. really sorry – Paliza Dec 2 '16 at 6:28
0

This is a problem with the original design brief and the definition of the test rather than the prototype.

You say that you have hundreds of use-cases - you can't possibly test all of them.

At the outset of any UX project, you need to define the problems you are trying to solve - this will dictate the design and the testing. If, for example you find that users are having problems finding point 'B' from point 'A', you would design a solution and then test that journey only.

If you are at the stage where you are building a prototype then I would assume that you have (or have access to) the issue that the design is trying to solve. This should enable you to script your test and, therefore, what you need to build into your prototype.

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