Monday, 24 December 2012

Design and Prototyping (Medium-Fidelity) Contd..

Annotated Story Boards

After that we moved into the annotated story boards for more detailed mobile design patterns and for the flow of the interfaces.



Design and Prototyping (Medium-Fidelity)

After sketching the story boards and sketching the interfaces on the papers, the basic idea of the application was generated and then for more detailed mock-ups as the medium fidelity prototypes, we started working with wire frames. For generating the wire frame mock-ups, we used software called Balsamiq by balsamiq.com. Since we had not the licence for the full version, we had to try the web demo instead of having the full functionalised software. But that was very successful and a high detailed rich wire frames could be generated according to the paper sketches. 

Initial Wire frames using Balsamiq (Moday Clinic Mobile App Prototype)



These prototypes are sort of a best-of-both-worlds implementation that allows for a combination of both high-level and detailed views; rapid, iterative changes; and the ability to conduct meaningful user tests to evaluate complex functionality and to help determine system specifics.

Benifits of Medium - Fidelity Prototypes

By combining HTML, CSS, and Javascript (for web applications), we're able to relatively quickly create an interactive example system that is designed to help the client, the development team, and the visual designers better understand the requirements guiding the project. When used as part of an application development project, a prototype can:


Friday, 21 December 2012

Design and Prototyping (Low-Fidelity)


A manifestation of a design that allows stakeholders to interact with it and to explore its usability.

"Prototyping is externalizing and making concrete a design idea for the purpose of Evaluation"
                                                                                                                                      -Bill Verplank-
Prototypes are tangible representations, an attempt to realize any aspect of software content.

Prototypes can help answer questions such as:
  1. will the design work properly?
  2. Can the design be produced economically?
  3. How will users respond to the design?
  4. Which approach can be taken to get from concept to product?
  5. How an prototyping support product design specification?
  6. How can prototyping contribute to better product scheduling and budget planning? 
Levels of Fidelity

The level of "fidelity" of a prototype refers to how closely it resembles the final product. For simplicity's sake, we'll consider three levels of fidelity used for prototypes: Low, Medium, and High.

Low-Fidelity Prototypes have been implemented as a jumbled mass of sticky notes on an office wall; as multi-colored, cryptic scrawling on a white-board, or even as a set of BON (Back of Napkin) scribbles. They're easy to create, inexpensive to change, and are good for providing a basic "high-level view" of the overall system structure.

A low-fidelity prototype can be as simple as a sketch on paper. As an example we used in Monday Clinic Application Prototype,


Sunday, 16 December 2012

Task Descriptions (Hierarchical Task Analysis)

A structured, objective approach to describing users’ performance of tasks, hierarchical task analysis originated in human factors. In its most basic form, a hierarchical task analysis provides an understanding of the tasks users need to perform to achieve certain goals. You can break down these tasks into multiple levels of sub tasks  In user experience, you can use hierarchical task analysis to describe the interactions between a user and a software system. When designing a new system, hierarchical task analysis lets you explore various possible approaches to completing the same task. When analyzing an existing system, it can help you to optimize particular interactions.

Applying Hierarchical Task Analysis to User Experience

Hierarchical task analysis requires a detailed understanding of users’ tasks. You can achieve this understanding by,

  1. Identifying users’ primary goals
  2. Detailing the steps users must perform to accomplish their goals
  3. Optimizing these procedures
Example Hierarchical Task Analysis for ordering a book:

0.In order to borrow a book from the library 
1. go to the library 
2. find the required book
2.1 access library catalogue
2.2 access the search screen
2.3 enter search criteria
2.4 identify required book 
2.5 note location
3. go to correct shelf and retrieve book
4. take book to checkout counter

HTA Diagram



Friday, 14 December 2012

Task Descriptions (Use Cases)


What is a UML Use Case Diagram (UCD), and when to use it?

UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed.

UCDs have only 4 major elements: 
  1. The actors that the system you are describing interacts with, 
  2. The system itself, the use cases,
  3. Services, that the system knows how to perform,
  4. The lines that represent relationships between these elements. 

Task Descriptions (Scenarios)


A scenario is a description of a person’s interaction with a system. Scenarios help focus design efforts on the user’s requirements, which are distinct from technical or business requirements. Scenarios may be related to ‘use cases’, which describe interactions at a technical level. Unlike use cases, however, scenarios can be understood by people who do not have any technical background. They are therefore suitable for use during participatory design activities.

When are scenarios appropriate?

Scenarios are appropriate whenever you need to describe a system interaction from the user’s perspective.
They are particularly useful when you need to remove focus from the technology in order to open up design possibilities, or when you need to ensure that technical or budgetary constraints do not override usability constraints without due consideration.
Scenarios can help confine complexity to the technology layer (where it belongs), and prevent it from becoming manifest within the user interface.


Wednesday, 12 December 2012

Task Analysis

Task analysis analyses what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system and the information flows within it. These information flows are important to the maintenance of the existing system and must be incorporated or substituted in any new system. Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.

Key Concepts
  • A user goal    = a state an end-user wishes to achieve 
  • A user task    = a user activity required to bring about a goal
  • A user action = physical activity (part of a task) with or without a computer