Low-fi Prototyping Yuandi, Lesly, Robert, Carol, Sun

I. Team NamePike

II. IntroductionWe realized one of the problems students face is finding available parking space within the university campus. We have tried to conceptualize our POV and HMW statements into a series of sketches. We came up with three experience prototypes based on the responses of our interviews. The final prototype we decided on was a prototype that included the four major functions that we consider necessary for our app. We decided to work ahead and for this assignment we already had our lo-fi prototypes. We created a UI that we want to implement in our testing.

III. Sketches Web

Watch

UI Storyboard

IV. Interface Design

For the interface design, we wanted to focus on integrating the functionalities that wethought would be the most useful for the user. We wanted to create a space foreach of the four functions. We are still debating if to create a personal user for eachuser, where they would be able to register and create a profile. “Search” wouldenable the user to look for a specific building or area immediately. “Locate” wouldshow the user the last known location where they parked. “Filter” would filter out theplaces that are available or empty on the map. “Favorite” would be for the user toknow where they have parked the most in case they forgot to check in,they cancheck their favorites to maybe remember where they left their bicycles.

V. Prototype DescriptionA. This prototype was the simplest of them all. The user would just search and pick where they would like to park. In this prototype we have the first option being the option of clicking on the map and checking what location would be available. The user would be able to park the bike and thats it. We thought some of the users would appreciate the simplicity.

B. With this prototype we wanted to add profiles for each user so that they would be able to record past parked locations. This would serve in case they forgot to use the app when they parked their bike, past locations might help them remember where they parked. Also, we added the “find” button where immediately the last known location would appear.

C. Here we created a more structured prototype with the functions we believe that a user will want to have. Again, we are still testing which functionalities would work and which wouldnt. Here we added: search, filter, locate and favorite. Because this prototype adds more functionality to the app, we discussed about it for a little longer than usual, trying to se which features are needed or not, and we came up with the following prototype:

VI. Method1. Participants: demographics, how recruited/compensated

We can categorize our participants into three categories: a pedestrian,a bike rider, and others. Others are people that do not go around onfoot or with bike, like motorcyclists.

2. Environment We came up to them and tested our prototypes with the app POP. Weput all the paper prototypes on the app so that we can test differentprototypes based on the same environment.

3. Tasks Simple task : Remember the location where you parked the bike. Moderate task : Avoid his/her bike to be towed.Complex task : Find a parking space in an efficient way and desiredlocation in order to save time.

4. Procedure We approached each person and asked them if they could help us testthe prototypes. We promised to ensure their confidentiality by notrevealing their name or additional personal information. If he/she gaveus permission, we would proceed to introduce the general concept andtargeted problem of our app to him/her. Finally, the user was able totest the app and provide us with feedback.

5. Test MeasuresWe divide the procedure into three phases. At each phase, we gavethem a simple task direction and we let the user operate the app ontheir own, since we created the links beforehand. If they encountersome problem or they clicked on some functions that are notimplemented, we’ll guide them through and record the problem. Notonly did we record all the problems encountered, we also recordedwhen and why the participant had either a positive or negativecomment about the paper prototype.

VII. ResultOverall, after finding users to work through our tasks we found out that PIKE

is jovial. Most of the users said our design is simple and clear and useful. What’smore, we can add more target customers in PIKE. besides NTU students can usePIKE, the motobikers can use PIKE . But there is a problem of PIKE, some of theusers said that they may not need the “history” function because it is not reallyuseful. So, we will discuss about changing this function or deleting it.

Start screen :

We put all of our function in the start screen to let users know what canPIKE do. None of the users had trouble getting started. They easily found the“Click me” button to complete the simple task.

Search : Two of the users hope that it can find the location where the user is at

first.Then,find the other location If the nearby parking slots are full. One of theusers is not the NTU students and he said that he will really like it if we addmore selection ( location where out of school) on it . We think that we canmake not only the students bikers to use PIKE but also the other bikes to usePIKE.

Locate : One of the users suggested we to use the google map API to make this

function more clear and real. And the rest of users said that this is reallypractical , they need it to find the bike.

Icon & Color : We use green and red to indicate the “slot parking space ” and “

crowded parking space” on the map. Except the color, we add hint to let usersto know what is the mean to green and red. None of the users had to guess atthese colors because they think it is clear. And most of the users think that theicons are approachable. Most of users consider that the color and icon of Pikeare simple and clear. They can use it directly without instruction.

VIII. Conclusion1. Users prefer more functionalities rather than having a super simple app.2. Although adding more functionalities to our application, our main goal is too

still try to achieve simplicity so that users won’t be overwhelmed.3. We still have not decided whether or not to keep the functionality of “history”

in our app. We need further testing to decide if this functionality will really work or not.

4. Users understood fairly quickly and easily the main goal of our app without further explanation.

5. We decided to expand the scope of our research to other university campusesand to have motorcycle riders users be able to also use our app. The app would basically be the same but we would add the ability to choose between which campus.

word count: 1186