Prototyping Weekly (Process Blog)

I am currently pursuing Masters degree in Human Computer Interaction + Design at University of Washington. During Winter quarter I have registered for a protopying class. We are exploring a new protoyping style every week learning the tools and exercising their practical use. Some projects are worked through in class and some after class, some individually and some in teams, but mostly they are all a lot of fun. This blog is a window into my work through this course.

I hope you find some inspiration through some of my work.

March 7, 2014
Brief: http://blogs.uw.edu/hcid521/assignments/a8
Prototyping Tool: Rhinoceros

The GOAL of this week was to learn about physical protoyping techniques using a 3D printer. The main thing for me to learn was using modeling tools. Professor gave us an open playing field to select the tool any protyotype we could build.
Process:
- Conceptualize the design
- Choose the prototyping tool
- Get cranking

I understood that it has to be a single contigous design when it comes to producing these designs using a 3D printer.

PainPoint: I own the Nokia Lumia 1020. I love the phone. I dont like the lack of phone case options for it. I set out to create a Lumia 1020 case that I can use on my phone. I created the initial design using the dimensions.

The END PRODUCT!

Learnings

- Visualization and Perspective from differnt angles.

- Learning a new tool can be frustrating. You are using to working super efficiently and executing at an expected speed. Book extra time

- Bringing things to live and realizing the designs are LOVED.

Feburary 27, 2014
Brief: http://blogs.uw.edu/hcid521/assignments/a7
Prototyping Tool: Arduino
Inspiration: Nest https://nest.com/thermostat/life-with-nest-thermostat/#meet-the-nest-learning-thermostat

This week I learnt I played with Arduino to build a thermostat. Idea was to build a thermostat with features of NEST.

Process:

Like always the first step was to understand the inspiration. I read some blogs and the company website to figure out what were the most useful and necessary features of their thermostat. I scoped my goals to

Goals:

- Sense current temperature

- Display current temperature

- Allow ability to increase/decrease temperature

- Energy saving (turn on thermostat as motion is detected)

- User preset's (adjust preset temperature as particular individuals are detected)

Next steps

- Parts needed to develop prototype for each goal

- Write pseudo code learning from code samples and examples.

- Develop code and working system for each goal.

- Create a cohesive working system bringing together individually developed prototypes

- Test, Test and again Test

Goal 2: Display Temperature. (You got to start with Hello World!)

I used the LiquidCrystal and Wire libraries to interact with and format the display.

Goal 3: Increase/Decrease the temperature
I added a button to allow users to interact with the thermostat. Here you can see one button (early view of the ping sensor motion detector) which was used to increase the temperature by 1 degree. During testing I found the button connectivity with bread board was highly unreliable, so I added a LED which will serve as feedback to users - when lit their button press was recorded and temperature increased - if not TRY AGAIN!

Goal 4: Energy Saving
Energy saving will require me to monitor time of the day. I borrowed the clock module from Prof. Andy and integrated it with a mobile bread board and another Arduino. It will be used to change the temperature per the time of day.

Goal 5: User Presets
I needed to regonize when particular users are in range and adjust temperature to their presets accordingly. I would need to use some kind of wireless technology and individual detection system here. I decided on using a set of XBee's - they use wireless technology to communicate to each other. They could be easily packaged as a wearable technology and held by the subject for testing. Later on they could be easily replaced by any other wireless communication technology.
I programmed both XBee's on the same baud rate so they can communicate. I configured the subject XBee to transmit a C. I configured the thermostat XBee to detect transmission of a C. When successfully detected it means subject is in range. I played with the transmission power on subject XBee to configure the range.

Knowning my audience, I decided to let go of the switching to Celcius feature in the final version.

After lot of successfully testing and integration efforts, here you can see the entire system with

- Temperature Sensor: Measure Current Temperature

- Display: Display temperature

- Buttons: Increase/Decrease Temperature

- Ping Sensor: Detec motion and presence of people in the vicinity and save energy when no motion detected

- XBee's: Detect specific person

Inclass Demo!

Learnings

- It was great to see a working prototype built by myself. I coded, I put together an electrical system

- Coding is easy when you are pulling from a directory of examples.

- Integration is super difficult (I spent 4 hours just integrating all systems when they worked like a charm individually)

- Its important to think through the end system requirements before integrating individual systems. Just taking out the nice to have feature of celcius from the code took almost an hour.

- Connections between components and bread board were very flaky and needed additional care.

Feburary 21, 2014
Android Mobile App Prototype

Tweak the Tweet
Brief: http://blogs.uw.edu/hcid521/assignments/a6
Prototyping Tools: App Inventor 2 (Beta)

This week I learnt building an Android mobile app building prototype using App Inventor 2 Beta.

Inspiration: Tweak the Tweet (TtT) http://faculty.washington.edu/kstarbi/tweak-the-tweet.html. It is an idea for utilizing the Twitter platform as a two-way communication channel for information during emergencies, crises, and disasters

Process
Began this exercise by mapping out the following work process:
- Understanding the inspiration http://faculty.washington.edu/kstarbi/tweak-the-tweet.html
- Review the Mobile development spec https://dl.dropboxusercontent.com/u/17697907/hcid/hcid521/Materials/TtT%20Design%20Spec.pdf
- Reviewing current available tooling options and choosing one.
- Scoping
- Building an interactive and functional prototype

Prototyping Tools

Off the below prototying tools, I chose App Inventor since it was focused mainly on building Andriod apps, provides exposure to learning writing pseudo code and the fact that I haven't worked with it in the past.
- POP (Prototyping on Paper): popapp.in
- Balsamiq: balsamiq.com
- Axure: axure.com
- AppInventor: appinventor.mit.edu

Scoping

Due to limited time I decided to focus on the key points to touch on and show end to end app flow. The app will walk the user through

- Twitter login

- Location

- Event

- Landmark

- Category

Out of Scope

- Back navigation

- About Us/More Info Page

- Tooling dependency

Building the Prototype

- I started with choosing all the available imagery I was going to use per screen and fitting them to resolution.

- Divide the work flow into screens.

- I looked at a few tutorials available online and learning how they had built something similar to each screen I had build.

Screen 1/2 - Welcome Splash Screen/Login Information

- [Screen 1] Welcome splash screen

- [Screen 2] Alert user to call emergency services in case of emergency

- [Non-functional requirement] Inject delay in screen transition to closely depict app behavior and collect user feedback on acceptable app start up performance.

- [Screen 2] Authenticate user login using twitter authentication services.

Pseudo Code
- Firstly, I created a Twitter developer account and an app that can provide me the consumer key and consumer secret to authenticate my app using twitter developer API's.
- Integrated App inventor prototype to my twitter app dev authentication
- Code to authenticate user login information using twitter APIs provided by App Inventor.
- Installed the emulator to help test code.

Screen 3/4 - Location Selection
- Users can select their current location by either using the built in GPS functionality or entering manually.
- Users can add landmark information

Learnings:

- Building the pseudo code will make it easier for the developers and make UX designers make more prepared for their conversation with developers.

- Its very important to continously test with actual device since I saw some layout discreprancy between the emulator and device (residue of the demo app being in beta?)

- With the time constraints this would have been a great project to work with a team on or could have been coupled with the Website Prototype assignment a week before. Across two weeks we could have built a mobile app that records tweets and a website that can monitor these tweets. We could have taken more development tasks that could have seen these individual projects materialize fruitfully.

- By choosing to use App Inventor 2 (beta) I chose the latest and greatest technology but it proved to be the bleeding edge of the technology. There were no proven way for twitter integration. Most of the learnings available online and in forums was for a version which was superseeded and the current version seemed to be buggy.

- App Inventor was not compatible with IE and added a lot of spyware to my machine when using Firefox.

Feburary 14, 2014: Assignment Redesign DUB Website
Brief: http://blogs.uw.edu/hcid521/assignments/a5
Prototyping Tools: HotGloo
Editing Tool: Camtasia

Process
Began this exercise by mapping out the following work process:
- Evaluating the exiting website: http://dub.washington.edu/
- Identifying areas of improvement
- Scoping Changes
- Layout
- Prototyping interactive wireframes using HotGloo.
- Recording the video that explains key feature of website

Background & Starting Principles

Web Evaluation: To me a good website is a good use of
- Latest Technology
- Design
- Rich and Dynamic content.

In my web evaluation of existing website I found some of these elements missing.

Additionally, the website does not showcase some of the most important value props of DUB
- The vibrant community
- Seminar Recordings.

Today’s website looks more of a news portal. I aim to resolve some of these issues.

Web Prototype
From talking to a number of folks I realized the #1 value prop of DUB is the community learning through seminars and meetings/discussions. I decided to bring those two to the fore. Maximum real estate is given to the latest/most popular seminar recordings that visitors could browse through right away.

Upcoming DUB events are highlighted on the calendar and visitors can know more by selecting the date. If you prefer to sync DUB calendar to your personal calendar, you have that option too.

Now, DUB website needed a virtual community space where folks can talk learn, discuss and spread awareness about new ongoing’s of the industry. Using learning’s from Web 2.0 trends I wanted to focus on providing an ability to content sharing and co-creation. Some of the most popular websites have these features at the core of their business principles (http://en.wikipedia.org/wiki/List_of_most_popular_websites) - Facebook, Youtube, Wikipedia, Linkedin, Wordpress.

New feature requirements -
- Members can engage in meaningful discussions either by initiating or by participating in peer comment forums. [Discussions]
Spread awareness or learn about trends using twitter handle #dubtalk. [News Feeds]
- Integrated twitter and editor approved news feeds [News Feeds]
One location for all research papers and call for action proposals [Research & Papers]
- Collaboration space lists the current member projects and may list call for contributors [Collaborations]

Final Website Prototype http://hcid520.hotgloo.com/wf/091f578e

Learnings
- Easy and quick to translate sketch to interactive wireframe
- Working on actual size was helpful. I used 960grid which is easy divisible and the grids can easily be translated in responsive website.
- Easy to iterate – I went through 8-12 iterations in a relative small amount of time.
- Tool limitation – I had a hard time on deciding which tool to use HotGloo vs. Axure. Both tools had a few good options and missing some I needed. Finally I settled with HotGloo because of familiarity. The relative reliability of the tool itself was in question as I moved to test between platforms (Windows, OSX) and browsers (Safari, IE, Mozilla).
- Prototyping is supposed to be quick and dirty and I think I was able to achieve the goal however, it cannot show case some of the core principles we design with – responsiveness, live content.
- Learning the tool and delivering a project at the same time within strict timelines can stress you out.

Feburary 7, 2014
Brief: http://blogs.uw.edu/hcid521/assignments/a4

Inspiration: SNUPI Technologies

Prototyping Tools: Arduino

Editing Tool: Adobe Premier

For the first time this quarter we were were in teams to deliver one project.

Process
We began this exercise by mapping out the following work process:
1) Decide what functionality and features our home water alarm system would have.
2) Create a scenario to test the system.
3) Build and test the prototype.
4) Test and video record.

Background & Starting Principles

Notification System: The most important task was to create a great user experience. The only user interaction is when user gets a notification about water hazard. The user is mostly already in a state of shock, so we wanted extra emphasis on providing option to quickly alleviate his concerns and put him in the best position to take quick decisions. We explored several methods to notify user of the water leak, such as text message, mobile app notification and phone calls.

Text Messages: Even though with phones today the test messaging is conservative using in built smart phone text ⇔ voice conversion technologies (ala Siri), its still an asynchronous way of communication. You receive a text, which could be read by voice and you could respond via voice but then its a fire and forget mechanism when you send the response. Some phones have also hooked with speech recognition back end services (Windows Phone) but they leave a lot to be desired. Not to forget many users do not want to pay the high text messaging rates.

Phone App: App creation, maintenance and support dissuaded this option. We wanted to use an omnipresent way to implement our solution.

Phone Call: Everyone has a phone, its a synchronous way of communicating with a user and you could provide value added services by transferring to actual people(something you cannot do with text). We decided to have the home WaterLink base station trigger phone calls to notify the users and execute their commands. However, as we started testing we realized it would be much better user experience if a live video feed from the sensor was sent to the user. This will empower him to make critical decisions based on the extent of the damage. We decided to go with a VIDEO CALL. We use two iPhones and connect them by facetime.

Accuracy of Voice recognition systems still leaves a lot to be desired after ~20 years of development. From our research, Accuracy is at 94% for Siri , 82% for Google Voice.

Product & Prototype

Product WaterLink is an alarm system that alerts users’ to unwanted water and leaks in their home.

System components and their functions

- Internet connected base station
Detect signals from wirelessly connected sensors
Execute user commands on home main valve
Dial alert calls to users and walk through Interactive Voice & Video Response (IVVR)
Connect Sensor video feed to the user.
Connect to WaterLink cloud to provide value added services.

- Individual sensors strategically placed near each water supply area
Detect leaks and alerts the base station
Light indicator to show “attention needed” level of water and moisture
Provide video feed to show detected issue to users when not in home or in hard to reach areas

- WaterLink Services
Additional services such as handyman recommendations, scheduling of maintenance appointments, connection to emergency services, directory of home equipment store

Scenario We decided on a scenario that would test the alert notification component of our alarm system. In our scenario, the user is away from the home and receives a call from WaterLink. There is a leak under the kitchen sink, and the user is given several options on how to address the issue.

Prototype: A behavioral prototype was built to “wizard of oz” the scenario
● An arduino served as a mock sensor placed near the kitchen sink. A red LED indicator light was programmed to blink rapidly to signal a problem with the kitchen sink drain.
● An iPhone was pre-programmed with the contact name WaterLink” so that any calls look like they came from the system.
● Developed a workflow/script for the IVVR which presents options and responses based on the user’s voice input.

● To simulate a computer voice, each text response was copy/pasted from the script into Google Translate, and the voice was played. Our first test found this method to be too slow, resulting in very long wait times for responses from the system. On the second test, we used a text-speech translate website, and we pre-recorded all the responses of user, the speed was faster than before but there was less flexibility for the user to provide different responses.
● Two members of the team played the role of the WaterLink system, and were hidden away in the bathroom. The third member facilitated the test with the participant in the living room.
● Video recording was made of the participant and the iPhone screen.
● The participant was told the following at the beginning of the test:
“Thanks for being here. We're testing a new home monitoring system that detects and alerts you to leaks and undesirable moisture in your home. The system is called WaterLink, and is already pre-installed in a separate test apartment. Please go ahead and respond to any calls from WaterLink”
● We ran tests with two participants, and asked them to test the system a few times, providing different responses each time.

Scenario Catalyst

Analysis

In general, our prototype worked well. Users understood the basics, which is that they were receiving an emergency alert call from WaterLink, and that they could interact with the system.
● Participant 1 was clearly nervous during the test, and was uncomfortable in front of the camera. We decided it would be useful to provide more explanation and background on what we were testing, and what to expect prior to arriving at our test space.
● The response speed was so slow for the first series of tests, that Participant 1 ended up answering several time before getting feedback from the system, sometimes changing his answers. Because of this, in a few instances, the wrong message was played.
● Participant 2 was given more context and preparation prior to arrival, which resulted in a smoother and more comfortable test. She was also given specific responses to provide to the system, which enabled our team to use a pre-recorded track and play/pause as needed.
● Participant 1 thought the video feed was actionable and enabled him to see what was going on.
● We learned from additional feedback that users may need additional context on the exact problem in order to make any decisions.
● The options available in our prototype were intentionally limited because it was difficult to pre-code all of the possible questions and responses in preparation for a true speech recognition system. In this case, our abilities as prototype builders caused us to make certain decisions about the actual product.
● Because the options were limited, the voice interaction had a frustration/annoyance factor as the response to anything other than “yes” or “no” was “I didn’t understand you, please say yes if….”
● The experience of seeing our product in action brought up questions around the value proposition - Do users want to receive a phone call from their drain pipe? Is talking to a robotic voice frustrating? Do they want to be able to turn off their water remotely - what if somebody else is in the house? Do users want handyman recommendations?

References
http://www.macrumors.com/2013/12/10/siris-accuracy-continues-to-improve-as-apple-works-to-reduce-reliance-on-google/
http://techcrunch.com/2010/01/28/phonetag-voice-to-text-86-percent-accurate-google-voice/
http://uxmag.com/articles/process-makes-perfect-speech-recognition-user-interface-design

January 31, 2014: Assignment A3: (Accessibility) Proximity Alerting

Video Prototype

http://blogs.uw.edu/hcid521/assignments#a3

Editing Tool: iMovie

January 23, 2014, Assignment A2: Handheld Device

Model Prototype

Brief: http://blogs.uw.edu/hcid521/assignments#a2

Ease of use: Jigar should be able to use his blender to make shakes directly in his gym bottle. Aesthetics: Explore different forms to arrive at an aesthetically pleasing design that will please Jigar’s wife

Issues with existing blender:

Design Option 1
Incoroprates better asthetics: Exploring different forms that are ergonomic and have pleasing aesthetics for when appliances are left on the dining table or kitchen counter top was main criteria for this prototype exploration. While brainstorming I kept on coming up with designs that can stand upright. It just made sense - let go with those two piece blenders, or the ones that lie down and roll over.

Form Exploration

Design Option 2
Approach: Inspiration - PC mouse. Aim was to test if horizontal form work better that current vertical form which is mostly the industry standard for handheld blenders. The prototype was created using foam board, duck tape and a plastic base that replicated the blender blade.

Design Sketch and Making

Design Option 3
Approach: Inspiration - Tennis ball. OXO is known for its universal design. Tennis balls have the same universal appeal and people of all ages can easily grip it. Additionally, it maintains it form factor over lot of wear and tear. This design provides comfort grip and resistance to vibrations from the motor. The overall design ends up looking like a dropper. The base of the blender is made sleeker to ensure usages in most bottles with small opening radius. Additionally, it runs on rechargable battery, can come in different color'ed tops/button and has a flat top to enable sitting upright on the counter top.

Design Sketch and Inspiration

...................................................................................................................................................................................

January 17, 2014, Exercise E2: EcoATM

Model Prototype

Brief: To Be uploaded. Subject: www.ecoatm.com

For our second project again we worked in an inter-disciplinary team of three students. The prototype scheme to be used this time was Model Prototyping where focus is on industrial product design.

ecoATM eats (recycles) your old phones, mp3 players giving back CASH! Its a great cause - save the planet! Perfect for doing good for the community Fridays! So we were super excited.

We started as a team to brainstorm on identifying issues with the current design of ecoATM.

Issues identified

- Accessibility needs of people using a wheelchair (secure phone drop off, screen access)

- Privacy concerns for cancelled transactions

- Secure phone drop off

- Static kiosk height

- Stolen phones

- Cash transactions

- Identification

- Phone collection procedures

- Can there be a backend marketplace where these phones are sold? (yeah we got a little carried away, started going into the business plan)

Below is our reaction before and after the brainstorming exercise. :)

We voted for the top issues we want to solve and started our design prototypes.

Problem: Accessibility needs of people using a wheelchair (secure phone drop off, screen access)

Proposed Solution: A lowered height with angled screen for easy approach. The lowered height will allow these users to interact with the screen below the eye level. The angled screen ensures a solution for all - whether on wheelchair or standing. As you would guess, this will help with the static height problem as well.

Problem: Identification

Proposed Solution: We saw ecoATM was collecting drivers information and finger prints. We though this process was super tidious. Additionally, not all drivers licenses have biometrics embedded and not everyone has a driver's license (common from our class of lot of international students). To ease the user experience we through of going a different route with user identification - Facial Recognition. Facial recognition software will enable users with different form of ID's to use this system as their face is compared against any form of photo ID. Just hold it up against the camera! Thats it!

Presence of a camera can also discourage thefts.

Design: We decided to embed the phone drop off right below the screen which can open only during an appropriate stage of the transaction to ensure secure drop off.

Card board - Check

Cutter - Check

Wodden stick - Check

Glue - Check

Lets Go!

DUCT TAPE!!!! - CHECK!

Wallah!

See that camera? & Fake cash!

Learnings

We were really time crunched for this in class exercise - couple of hours. As you can see the end product looks very - SIMPLE! May be we should have done better time management and just plain project management with distribution of labor.

A lot of calculations go into an industrial design - the correct angle/depth of screen, height are just a few very important things. An extensive amount of research/user testing will be required before this can be thought of as a redesign idea in any way.

We iterated and with limited resources improved a lot (DUCT TAPE! - withstood many rounds of user testing) :)

You can really prototype anything you want to.

Having said that, we delivered incremental value with improved user experience. We came together as a team and showcased some great team work to deliver a great functional prototype.

January 17, 2014, Assignment A1: Polite Calling

http://blogs.uw.edu/hcid521/assignments#a1

Polite Calling is a concept paper prototype that looks to integrate the new age technologies like smart watches to the old age basic calling functionality.

The Meeting buried Professional

It’s you, me and everyone who is following our dreams and passions. In our busy work days we still want to ensure we don’t miss those important alerts while we turn off our cell phones to silent in meeting in an effort to focus on the subject at hand.

Jigar Dani is a busy professional. He usually misses his calls as he sifts through his daily meetings. He wants to make sure he does not miss those most important calls.

Through advanced features in vanity calling applications Polite Calling concept tries to dramatically improve the user experience.

: Jigar sync's his phone with his calendar so the phone is aware of his availability. Additionally, the prototype introduces two vanity callee preference features -

1. Automated responses when busy - Used to send a polite acknowledgement to the caller.

2. Allow important calls - Used to allow incoming important calls.

Jigar's phone is synced with his new smart watch. If he is busy, notifications will only be allowed for incoming important calls.

Unnati (Jigar's wife) uses two new caller side calling preferences introduced by this prototype -

1. Subject - Used to relay purpose of the call.

2. Importance (Normal/Urgent) - Used to relay the priority of the call.

Unnati tries calling him for a casual call. She rightly sets the priority of the call to Normal.

This call is masked by the Jigar's phone and a polite acknowledgement is sent back to Unnati

At a later time, Jigar sees his missed calls.

: Jigar has set up his callee preferences to allow only important calls. This time, Unnati has an important call for Jigar. She marks the call as Urgent using her caller preferences.

Jigar's is alerted on his smart watch and is able to make arrangements for the new arising situation - just in time.

I ran this idea through some of Microsoft, Amazon and Snupi employees. The general consensus was extremely positive. People drew parallels to some of the products they already have in the market in unified communications space - Microsoft Exchange provides options for users to set up their voicemail forwarding. Microsoft Lync allows you to automatically forward your calls when presenting in meetings, Google Talk has already forayed into this arena. However, none of these products provide the personal user experience - They are not ingrained in the vanilla calling function of the feature/smart phone. People I spoke to said their co-workers still carries their phones to meetings and keep looking at them every few minutes to ensure they are not missing any important calls/messages/emails.

Positive Feedback in two words - "refreshingly simple".

Constructive Feedback

I would like to spend more time to curate this idea. Ensure the simplicity and ease of use of making a one click call is not compromised to provide an advanced feature set. Additionally, I would like to curate this idea for my secondary audience using another prototyping tool.

Whether it is a door bell or an incoming call - Ryan, our hearing impaired user - on an average misses 50-60% of these key alerts. The mobile phone in the pants/winter clothing vibrate that can be easily missed. Flashing lights alerts also work only when the phone is in vision range. 1:1 interviews exposed deficiencies in placement design of the light itself - Top corner of the phone - where users have to keep the phone perched on an upright holster. Things we have learnt to take for granted don’t come so easily to them. In the new world of smart watches, here is a device that can be adopted to serve these users. I have just tried to adopt it to one use case that can impact them.

Smart watches are a great new gadget for the hearing impaired. It’s always in "touch" and at "arm’s length" - pun intended. I tested the concept with some hearing impaired folks at UW. They loved it, they got a sense of connection. Vibrating alert tied to your hand can easily replace if/any alerting tools they have today. As the eco system develops these smart watches can be integrated into door bells, microwaves, ovens, washing machines and just about any other home appliance to create an advanced notification system for these users.

Unfortunately, Paper prototyping did not prove to be the most effective tool to test this scenario - vibrations, flashing lights and what not. Here's looking forward to another Arduino based project. :)

January 10, 2014, Exercise E1: Coffee Ordering App

Paper Protyotype

Brief: http://blogs.uw.edu/hcid521/exercises#e1

We worked in a groups of 3 with people from varied diciplines.

Firstly, individually we spent time understanding the brief and creating quick sketches for our ideas. This ensured each had time to think through the brief and come up with individualistic solutions respecting our backgrounds and expertise. We regrouped to discuss our ideas and get inspired from each others work.

We worked togther to think through the most impactful scenarios and creating the workflow.

Impact: Long queues along with long wait time makes a coffee ordering experience unpleasant.

AIM: Coffee Ordering App to allow customers to place orders from cafe tables.

Design: Simple, Effective & Quick.

Jigar's phone is synced with his new smart watch. If he is busy, notifications will only be allowed for incoming important calls.

Unnati (Jigar's Wife) uses two new caller side calling preferences introduced by this prototype -

1. Subject - Used to relay purpose of the call.

2. Importance (Normal/Urgent) - Used to relay the priority of the call.Jigar's phone is synced with his new smart watch. If he is busy, notifications will only be allowed for incoming important calls.

Unnati (Jigar's Wife) uses two new caller side calling preferences introduced by this prototype -

1. Subject - Used to relay purpose of the call.

2. Importance (Normal/Urgent) - Used to relay the priority of the call.

Jigar's phone is synced with his new smart watch. If he is busy, notifications will only be allowed for incoming important calls.

Unnati (Jigar's Wife) uses two new caller side calling preferences introduced by this prototype -

1. Subject - Used to relay purpose of the call.

2. Importance (Normal/Urgent) - Used to relay the priority of the call.

App Work Flow

Three Very Quick Steps:

- Browse Options

- Place Order

- Pickup Coffee

Quick Prototyping

Once we agreed on a basic framework we started sketching individual UI elements on Post-it's.That way its very easy to edit, change or reuse elements. We started working on quick test screens for our concept work flow. Making of prototype was fun, easy and intutive.

...................................................................................................................................................................................

Internal Testing

We interated through a number of rounds of internal testing to fine tune app work flow.

Final APP elements

APP Workflow

That Delight Element (ala Domino's) - Real Time Order Status

End User Testing

Exercise Takeaways

This is a great technique for initial design stages. Given its nature it acts as a great collaborative technique, something hard to achieve at times with PERSONAL computers. As the design and idea matures we can move to advanced tooling to produce the precision expected of a finished product.

PROS

- Paper prototyping is an amazingly easy and quick design technique during brainstorming/wire frame stages.

- No dependency on technical teams to implement ideas and design options

- Quick iterative process

- Invites feedback and discussion because of the unfinished nature

- One can pre-emptively create option matrix

Cons

- Replicating digital media animations (eg. default state, mouse over, click)

- Static nature of the media