Skip to content

1601-mma2013/template

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 

Repository files navigation

**You are required to complete Section I. Analysis by 2nd September. **

Goal; Observe & describe in informative in simple and precise way.

the

This document is written markdown syntax. To edit this document teach yourself how to use markdown. You can use any existing markdown editors (1, 2) from your local machine and then sync through Github desktop.

Project Name

I. Analysis

1. Research

a. Scope

Define project goals and schedule

  1. objectives In which way will your project solve user’s problem?

b. Audit

Review existing work and product

  1. Field (market) research

  2. competitors / alternatives / replacement

  3. relevant technologies

c. Stakeholder Interviews (internal / external)

Understand product vision and constraints

  1. product{project} vision

  2. risk 3. What is the worst result?

  3. Obstacles

    1. external threats
  4. constraints

    1. Internal limitations 2. viable technologies 2. cost
  5. opportunities

    1. In spite of the obstacles we have this project has strength from a), b), c), ….
    2. Persisting problem
  6. users

d. User observations

Understand user needs and behavior and describe it. Find various aspect of audience/customer

  1. Users

  2. potential users

  3. (user’s) behaviors

  4. (user’s) attitudes

  5. (user’s) aptitudes

    • users’s ability to learn something quickly and do it well
  6. (user’s) motivations

  7. (user’s) environments

  8. (user’s) tools

  9. (user’s) challenges

2. Modeling

a. Personas

user and customer archetypes

  1. goals

  2. Patterns in user and customer behaviors

  3. attitudes

  4. aptitudes

  5. environments

  6. tools

  7. challenges

b. Other Models

Represent domain factors beyond individual users and customers

  1. Workflows among multiple people

  2. environments

  3. artifacts

II. Synthesis

1. Requirements Definition

a. Context Scenarios

A sample context scenario

The following is the first iteration of a context scenario for a primary persona for a personal digital assistant (PDA) type phone, including both the device and its service. Our persona is Vivien Strong, a real-estate agent in Indianapolis, whose goals are to balance work and home life, close the deal, and make each client feel like he or she is her only client.

Here is Vivien’s context scenario:

  1. While getting ready in the morning, Vivien uses her phone to check her e-mail. Because it has a relatively large screen and quick connection time, it’s more convenient than booting up a computer as she rushes to make her daughter, Alice, a sandwich for school.
  2. Vivien sees an e-mail from her newest client, Frank, who wants to look at a house this afternoon. The device has his contact info, so she can call him with a simple action right from the e-mail.
  3. While on the phone with Frank, Vivien switches to speakerphone so she can view the screen while talking. She looks at her appointments to see when she’s free. When she creates a new appointment, the phone automatically makes it an appointment with Frank, because it knows with whom she is talking. She quickly enters the address of the property into the appointment as she finishes her conversation.
  4. After sending Alice to school, Vivien heads into the real-estate office to gather some papers for another appointment. Her phone has already updated her Outlook appointments, so the rest of the office knows where she’ll be in the afternoon.
  5. The day goes by quickly, and eventually Vivien is running a bit late. As she heads toward the property she’ll be showing Frank, the phone alerts her that her appointment is in 15 minutes. When she flips open the phone, she sees not only the appointment, but also a list of all documents related to Frank, including e-mails, memos, phone messages, and call logs to Frank’s number. Vivien initiates a call, and the phone automatically connects to Frank because it knows her appointment with him is soon. She lets him know she’ll be there in 20 minutes.
  6. Vivien knows the address of the property but is unsure exactly where it is. She pulls over and taps the address she put into the appointment. The phone downloads directions along with a thumbnail map showing her location relative to the destination.
  7. Vivien gets to the property on time and starts showing it to Frank. She hears the phone ring from her purse. Normally while she is in an appointment, the phone automatically goes to voicemail, but Alice has a code she can press to get through. The phone knows it’s Alice calling, so it uses a distinctive ringtone.
  8. Vivien takes the call. Alice missed the bus and needs to be picked up. Vivien calls her husband to see if he can do it. She gets his voicemail; he must be out of service range. She tells him she’s with a client and asks if he can get Alice. Five minutes later the phone sounds a brief tone. Vivien recognizes it as her husband’s; she sees he’s sent her an instant message: “I’ll get Alice; good luck on the deal!”

Notice how the scenario remains at a fairly high level, without getting too specific about interfaces or technologies. It’s important to create scenarios that are within the realm of technical possibility, but at this stage the details of reality are unimportant. We want to leave the door open for truly novel solutions, and it’s always possible to scale back; we are ultimately trying to describe an optimal, yet still feasible, experience. Also notice how the activities in the scenario tie back to Vivien’s goals and try to eliminate as many tasks as possible.

b. Requirements

Describe necessary capabilities of the product

  • Functional and data needs
  • user mental models
  • design imperatives
  • product vision
  • business requirements
  • technology

2. Design Framework

a. Elements

Define manifestations of information and functionality

  1. Information 2. form factor 3. posture 4. input method

  2. functional and data elements

    • information
    • functions
    • mechanisms
    • actions
    • domain object models

b. Framework

Design overall structure of user experience

  1. Sketch
    1. if your project is a design product
      1. Your sketch must be a wireframe.
    2. if your project is a installation project
      1. Your sketch must be a installation sketch.
    3. Must have
      1. groupings and hierarchy
      2. Territories of each functional & design elements
      3. Arrangements of containers & components
  2. Key path Scenario

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published