This week, I will be giving some feedback to Martin Watts on his prototype for a joke application. If you are interested, you can view his prototype on his blog. Martin and I will be working together throughout the rest of the semester as a programmer/designer pair to develop an app. Without further adieu...
Consistency and Standards
Severity Rating: 2
The biggest issue I noticed with the "Joke Around" app was the idea of "saved" jokes. Here, the word "save" seems a little out of context. Instead of using "Save," I would use "Add to Favorites" and change the "Saved" tab to "Favorites."
Aesthetic and Minimalist Design
Severity Rating: 1
The "Read" page has a lot more information on it than I think will fit onto the screen of a mobile device. Once you begin designing, I'm sure this will work itself out.
Error Prevention
Severity Rating: 2
When entering a new joke, I would recommend a "preview" before it saves it to the system.
Also, specifically for Martin: it has been a while since I have used android, and since you were designing with that in-mind, I am not sure about the design. Specifically, I am talking about the navigation. To me, it looks more web than mobile. On the iOS, a lot of interaction is done with icons. For example, instead of a button that says "Add to Favorites," there would be a heart, and when you click the heart, this performs the action of adding to "Favorites" and is indicated by filling in the heart. Additionally, tabs and a nav bar at the top are uncommon on iOS. Often times, the main navigation is found in a list under the menu icon in the top right corner. And the categories are usually accessed in another manner, similar to the expandable menus you have on your current "Saved" page. When we meet later this week, let's sit down and look really in-depth at the navigation.
And finally, here is a video of me walking through the prototype:
Great evaluation. I think you're absolutely right that the current app looks a lot like a web app at the moment. I think there are some key differences between iOS and Android that might mean that some of Martin's choices are more appropriate given an Android app, but then again ... :-)
ReplyDeleteRegarding preview, I would recommend against preview, and instead prefer undo and edit functionality, i.e. you want to make it as simple as possible to submit a joke. If you force a preview step fewer will be submitted, and offering a good edit option will provide the same functionality for those who want to review. You could argue that people might not edit and so there will be mispellings etc., but I'd say leave those to be weeded out via a popularity mechanism - allowing peer editing etc.
Thanks for the tips, that makes sense. Peer editing seems more like something to add in a future version maybe? Is it necessary in MVP?
ReplyDeletepeer editing definitely a future step - not necessary in the MVP. However I'd also leave out any preview step, and first implement self-editing, but then that can easily be left out of an MVP.
ReplyDelete