You need to test your paper prototypes at least twice. Make refinements between the testing process (and during!). Document these testing sessions:
200 words on test one & 200 words on test two:
What did you set out to test (i.e. what is your thing?)
What did each test reveal?
What did you change after each test?
Photo documentation (upload to <a href="http://www.flickr.com"Flickr) or EVEN BETTER: video, uploaded to YouTube.
Include links to your documentation and the report itself in the comments of this post.
Filed under: Homework
Mobile Journalism: class blog 
My first test was done by my sister Kirsten. She is only 15 but is on the computer all the time.
Overall, she said the program is easy to use for anyone. It is self-explanatory.
The changes she recommended for the first page was to move the “select a state” part further down on the page. Then she said to move up the “text number” from the bottom of the page.
On the second window, she said the same thing. Move the “select an airport” down toward the middle of the screen, and to move up the text number. She was curious what the airplane symbol was for in the right-hand corner. I explained that it would take you back to the main screen.
The final page where the times would be displayed she said to move all of the times down on the page, and to move the text number up higher. She noticed the clock at the top left corner. She asked what it was and I told her it refreshed the times. The other change she wants to see is the order of the times listed. She wants the curbside check-in first, then the regular check-in second and the security checkpoint time third.
My second test was done by my mom. She travels a few times a year and always gets there early just to be safe.
I made the changes that my sister recommended and centered things on the page. I also changed the order that the times were listed.
My mom said the first page was fine.
The next page she said to change the airplane symbol on the left to just read “home screen” because some people wouldn’t know what it means wouldn’t be able to figure it out.
She like the third page, but also said to change the clock in the left hand corner to read “refresh” for the same reason as above.
One thing she said for me to try and do would be to allow people to select what kind of check-in the person would be using so it would add up the time for that and security. I said there is no point to do that since it only lists three different times.
She definitely said it would be something she would use and something others would use too. It would be helpful for business people especially. No need to arrive too early.
Hopefully the previous video will play, if not, view here.
Testing, part one
This is a basic concept for what I envision would be a useful and functional WBEZ mobile app. Both times I showed the prototypes to some friends. The first attempt happened in a few stages — I redrew the interface a few times to add features I thought would be useful.
Here we have a way to sort stories, in this case I’m demonstrating how to do so by neighborhood and popularity. I felt a feature that would allow the user to save stories for later would be particularly useful.
The guinea pigs said it was a clear interface and that it was obvious what was going on. Originally I had the play/pause/stop buttons next to the “listen now” button, but quickly realized that was essentially useless as the listen now button is only on the main screen and would require quite a bit of back-buttoning/main screen clicking to stop or pause a story. Ah yes, this is what paper prototyping is all about.
Testing, part deux
After drawing up the interface differently with the play/stop/pause buttons easily accessible on the bottom of the screen, more testing. The map was appreciated — “It’s nice to see where everything is” — but one tester made a very important note which I felt rather silly for overlooking: volume control. Ah yes, this is what paper prototyping is all about.
Another tester asked about the sort by –> type feature. “What categories would you use?” Frankly, I’m not yet sure. General categories such as politics, national news, sports would probably be applicable here.
Now I need to add a volume control button at the bottom of the screen. Ah yes, this is what paper prototyping is all about.
I did not create a mobile strategy for an iphone, rather something that could be used on any phone. Simple texting programs is something on a smart phone or basic phone you can do these days that NPR could get on board with. Our school sends out alerts, as does sport websites, and news organizations. I am on WLS-ABC 7s news alerts and am sent breaking news updates to my phone. I think NPR could benefit from doing something as simple as this.
My first experience was with my brother and he did not really get the point of the exercise and then once I explained it better he knew how to navigate it since its simple recieve alerts, reply back.
My mom did not understand the concept as well as my brother because she is not big with technology and didn’t even know that some organizations send out alerts to phones. She knew you can text in your opinion in several polls on TV shows etc but has never done so herself but then got the concept that it was the same as texting a person.
My first attempt at using the prototype I got my friend Nick to help me. The thing with this application is that there are so many things you can do/use that I wasn’t prepared for what he would actually end up ‘clicking.’ I ended up totally redo the home screen because he said the original one was too cluttered, something I had a feeling I would have to change. When he got to the events page we discussed how it would be nice to have a map where all the events could be viewed on instead of just viewing them individually so I ended up adding a button at the top with that option. Everything else he seemed to understand pretty well and at the end I asked him what he liked and disliked about the application and if he would use it if it were available. His response was as follows:
Pros:
Fun to use if you’re in a neighborhood you’re not familiar with
Being able to receive CTA times and data
Cons:
App would probably be slow because of having to receive so much data
Lots of information to the point where it seems too much
He said he would use the application but only if it was free
The next person I asked to help me was my roommate. At this point the interface has had a complete makeover and I also went back and tried to make a lot of the screens look a little more clean and simpler. This time around was a better turn out. When we went through the application features he actually went and clicked almost everything I wanted him to on his first instinct. He suggested to me that the share and more info links on the events page would probably be better if they were both on the same drop down menu, which I did later change in my final prototype. All in all it went pretty well but I asked him also about what he thought was good/bad about the app and if he would buy it. He said:
Pros:
CTA times
Being able to submit something about your neighborhood
Maps and column viewing
Cons:
No option to view anything outside of your area
Unclear symbols in map viewing
He said he would buy this application if it was 99 cents or less and he also said he could see himself using it often.
My prototype detects your location and tells you news stories that have occurred in your area. My friend John tested my prototype and said it worked smoothly but he said if it had more news features in a broader map it would be more interesting. He liked that it can pick up the stories near you but he suggested that you choose a ending location and see stories that pop up along the way.
I also tested my prototype on my sister Alysse who has the iPhone. She said it is a feature she would use to check the crime in areas she wasn’t sure of. She liked it because she thought it would be helpful for naive college students like her. So I stuck with her insights and didn’t make any changes
My Prototype is a GPS Based Event finder for Chicago Public Radio Events. The Application works off detecting your location and then searching for events (CPR Presents, Music Acts, Arts & Culture, or Chicago Amplified Events) within however far of a distance you see fit. You can search within 5 miles of your location or all the way up to 50 or 100 miles of your location. The selling point for the app is that it is entirely GPS based. That is what makes the application so easy to use and that is why people will want it on their mobile device. Here are the tests I did below…
The first person I had use my paper prototype was Caitlin Cummans, a senior at DePaul University, and she enjoyed the idea of it. As a college student who is always open to going to different events and see what is going on in Chicago she said it was a very good concept. She said that the application could work great for both iPhones and the new generation of BlackBerrys, which is nice since so many college kids are using those two phones. She liked how you could see the different options either separately, simultaneously, or just use it as a map with the directions option. And while my art skills might be lacking, she couldn’t help but laugh at my handwriting at some points, overall she thought it was a great idea that could be put to use right away. And that people on their phones who are fans of Chicago Public Radio would most certainly use it right away.
The second person I had use my paper prototype was a friend named Lauren McTigue, also a senior at DePaul University and also in the Journalism department there. She like the application very much and said it reminds her of an application called “bar-town” or something like that where you plug in your zip code and on a map it shows bars and deals near you. She thinks the GPS enabled aspect of it is very helpful but suggested if I plan on doing an alternate App with phones that do not have GPS to just simply add a zip code box for people to type in their zip codes. Otherwise she thought it was a very useful application idea and that a wide range of people, from teenagers to people older than our parents, who listen to Public Radio would find it very helpful almost immediately.
And now here is the video
GPS Events App Paper Prototype from JD on Vimeo.
hopefully this works?
I realized I talked about the tests I did but I forgot to post what my application was all about!
The project I decided to go with is a GPS based application that gives you events, news, CTA times and traffic info along with user submitted content all based on your current location. I’ve been referring to it as CPR (Chicago Public Radio) GPS. It’s a pretty simply concept, you’re able to know information about pretty much anything around you with a couple clicks. You’re also able to share your information using Twitter, text messaging and other social networking sites.
For my prototype, I decided to test a possible “randomize” feature that would play different shows and users can skip over or choose to rate the show. Basically, when a show starts playing, a pop-up appears that asks you if you like or dislike the show or if you want to keep listening. My first test was with my mom, who’s not a public radio fanatic, but is at least familiar with some of the programs. What I wanted to know specifically from this test is what information users would want to see about the show before choosing whether or not to keep listening. I also wanted to know if this was even something people would be interested in having.
What I found out is that she wanted to know pretty much everything about the show right up front: name, description, host(s), length, and a description of what the particular episode is about. I had only put the show name and a brief description before, so I had to add some information. She also said that randomize doesn’t seem like a feature that a lot of people would really use, unless they had very eclectic taste. So I changed up the prototype a bit and moved on to the next test.
For test number two, I got my boyfriend to help me. I added all the information that my mom suggested to the pages about the shows. I also added a “Listen Live” button to the homepage, which really isn’t relevant to my testing but I thought it should be there anyway. He said he got how the app worked, and that the sequence of the pop ups made sense, but he was also unsure of whether people would use a randomize feature since people usually have favorite shows and listen for a particular reason.
We brainstormed and came up with something that I think might work a little better – randomizing within a specific category. Instead of the app picking a completely random show, you would choose a category of show – something you’re interested in – and the app would pick a random show within that category. Then from there it would work pretty much the same. This way, people can still discover new shows, but they don’t have to wade through so many others that hold no interest for them.
Here’s my set of photos on Flickr: http://www.flickr.com/photos/41869756@N05/sets/72157622411000537/
#1) My product is a relatively simple smartphone application that plays a variety of public radio shows and helps to better the mobile listening experience. Each test revealed a variety of things. First off, the tests revealed that many people would like a simple way to listen to WBEZ via a mobile device. The features they liked were the story preview, the story photos/videos, the chat, and transcript. The confusing areas were navigating backwards and the what some icons did. Most often than not my users could find their way around the application and said that it was clear and relatively intuitive. After this test I added a button to preview the stories and decided that a “share story” option would be helpful as well.
#2) This test was done by someone who uses an older, beat up Symbian-based phone and is not at all familiar with smartphone functionality. She listens to WBEZ podcasts regularly at work and on her iPod, and would enjoy a way to listen on a mobile device (if only she had one, which is a drawback). She found it easy to navigate into the application and find something that she wanted to listen to. She was unsure how to navigate back to a top screen. The buttons at the bottom were a little unclear to her, and she thought the forward/rewind buttons were for navigating the pages. This helps me realize there needs to be a bar above those buttons that shows the minutes:seconds into a show and the ability to move your location by selection a location on that bar. Those are things that I will change in my next iteration.
I posted the pictures and steps of my paper prototype on drop.io.
I just realized I forgot to logout of wordpress before submitting my assignment, so the response from “wattlebirddesigns” is from me.
First prototype verification:
My first paper prototype really sucked. My girlfriend tested it and said she couldn’t understand anything.
I basically tried to reproduce the exact measurements of an iPhone and found out that 1) It wasn’t easy to read and 2) It involved too many small pieces of paper that eventually ended up flying everywhere.
The idea was to get the user to listen to a number of radio programs that would comfortably fit the time he or she commuted or traveled to a certain destination.
Right away, I thought of having the GPS in the phone pick up where the user was and reproduce the location on the phone through a Google Maps sort of screen. I had a huge map with many dots showing the nearest train stops.
Once you chose your stop, it would open a new screen asking in what direction you wanted to go and what stop you wanted to get off. That was just painful, so we thought of simplifying this step by having the list appear on the map.
The final part was pretty much the same, except for the categorization that comes before the list of programs shown at the very end.
Second prototype verification:
My friend Chris checked out what was supposed to be my final version after I filmed it. In fact, I showed him the video this morning and everything seemed to be just perfect until he made me notice something at the very end: there’s no control panel!!! I had created the perfect radio/mass transit app without any possibility to actually listen to the radio.
So the video doesn’t show me repairing this glitch, but I’m imagining that control panel with the play, stop, back and skip buttons to appear on the side, in a vertical column. This way it will provide the user with a visual idea of where he wants to go. I am not sure about a record button, for it may conflict with the station’s interests. I don’t know, but that sounds like pirating.
Another thing Chris made me notice was the uselessness of the initial map function if the user is not familiar with the city. For that, the search tool is useful but cannot help much if I am totally lost. A more sophisticated search tool should be devised and I should include it my prototyping video.
My design is similar to the current design already used but I added a commuting function that designed playlists around the amount of time you have available to listen to your device.
In my first test, I tested to see how basic functions were interpreted by people brand new to the device. The star system for favoriting programs was confusing for the subject until he saw the “custom dial” category and was able to deduce it’s use. I’ll either need to add words or change the system.
The volume control wasn’t apparent to the subject (this was because I designed the volume to appear after clicking on a file to play) and the commute function was only intuitive on a minimum level. I had wanted the function to be searchable and programmable but he only saw it as searchable. Again, the star system wasn’t intuitive for programming.
My Paper Prototype test runs are all posted on my Posterous profile
http://www.icolin.posterous.com
Here’s the link to my drop.io with the pics of my paper prototype http://drop.io/vvplmxp#
My idea is based on being simple and being available. You subscribe to a show you like and after the show airs you get a text message with a hot line number and extension to call. You would get one for each show that you sign up for. This way CPR needs only one hot line, and one extension for each show. You call in, get prompted to enter the extension and then you listen to the show like you are on a phone call.
Test 1:
The largest hurdle in the first test was getting the user used to using a paper model over the real thing. A task like opening a text message was an issue when using a phone interface not familiar to them, although they can text and receive them on their personal phone and do often.
After that the test was easier. One drawback of a paper model is that you can’t hear prompts you normally would through the phone. Much of my idea is based on what you hear when you call their number. The user had no issue dialing and doing things that are natural when using a phone.
Using systems that already exist on all phones made the process of listening to the radio through a cell phone much easier.
Test 2:
Again the idea of a paper model was difficult for the user. This time it went smoother though. The text was received, opened and read. They dialed the hot line and entered the extension and got through the few steps easily.
I was asked how you would subscribe to it, and had always assumed that you would sign up online. That made sense to the user and her friends there. But if we want to keep this totally mobile then having a text number set up for each show you want to listen to, or certain times to text one number to subscribe to whatever show.
I hadn’t put much thought into how to subscribe, just what you do after that.
Re-posting my paper prototype video from Vimeo
Mobile Phone Paper Prototype from Nick Orichuia on Vimeo.