The mobile app for the critical food lover!
Design thinking application.
I thought it would be a good idea to address my mindsets and modes of thinking directly for ease of assessment, and catagorize where I have applied these principles.
The process from left to right and back and forth a bit...
Empathizing with the user in this case was a natural step. Being a user experiencing the problem our app tries to tackle made identifying how the user struggled to get information, get reliable information.
In addition, my research followed many links and stories online where there are people citing the pro's of Food photography and enjoying food loving culture, where as there was just as much social media mocking of the cultures development.
Struggle to be part of a community which sometimes likes your input and sometimes mocks your input is a rollercoaster of an experience. Facebook shun's some of the food lover culture with an 'over' social setting ( too easy to troll and put others down ), and instagram doesn't allow people to socialise enough?
My needs for an application like this were much less than those I spoke too. Some of the feedback when presenting my idea with friends and family were actually more business orientated than the original social aspect that I had scoped.
People actually cared less about the messaging and posting photo's of food, than the actual need to find a place, get the prices/menu and discounts!
So maybe I was wrong about the social idea, people like to be social... but not too social. I suppose that's why people sms rather than actually calling someone.
This gave me alot to go on when defining the problem....Empathizing with myself and potential users
Defining the problem and gap.
I have feel I have managed to isolate the core problem and the gap in the experience people were experiencing with involved research and empathizing with the target users.
Something that I wanted to point out here however is that it was noted that the user needs varied significantly between the age and social demographic of users I spoke with.
For example...
Potential users between 40-60 (Parents and friends) actually were more interested in 'Where they could eat, and the valid reviews' but not likely to share experiences on social media.
Users between 18-30 (Student collegues) were more interested in discounts and specials and more likely to share the experience with others on social media.
The albeit small demographic of people I interviewed between 30-40 (my family) were interested in both the discounts and reviews of a venue. Social media sharing of this/my demographic is less likely (Digital immigrants) than the younger demographic, but we felt that leaving the review to bank points was a good idea as it felt like it associated with a loyalty card service.
So it was interesting here that actually sharing the photo's of food really depended on how social the group of people were to which part of the application they felt they would pay focus on....
Further research on identifying the users and gap here...Defining the problem, target audience the gap they experience
Ideate and Prototype felt like they went hand in hand in this process. Ideation for us was a number of hand drawn diagrams, storyboards which were inspired from the definitions and concepts...
We focused on the potential ways to solve the problems.
- Methods of directly integrating Facebook and instagram API's into the app...
- Should we create our own social network?
- Was the social side enough or too much?
- What did people really want to do in a social section that they couldn't already do with SMS or Facebook messaging?
- When users created a profile... how much or little information would be necessary to function in this social application? Too much information and people wouldn't feel comfortable leaving comments and reviews. Too little and people wouldn't trust the reviews at all! This was very important and difficult to pin down.
- Should we include navigation as a feature? or do people prefer a link to an external app like Google Maps etc....
These were discussions in our group about the feature sets needed to satisfy those
needs, and how we could implement some of our delighters (CP, Business
integration and Reward systems).
This involved concept on GUI and pulling all the resources into a single space.
(Focus and Flaring)
So this leads to prototypes and internal iterations of the prototype in house testing.
This was the fun part, Some examples....
Iteration and prototyping screen shots...
Early Lo-Fi version... basic grouping of features and building blocks.
Late Hi-Fi version based on feedback and live user testing
As you can see there were alot of changes implemented throughout the prototype loop... Every time it passed through the Testing phase, more and more features were being requested as being 'functional' to be experienced before comment was being passed on it.
This as it turned out had an effect on time contraints where the testing demographic through my immediate contacts, and extended feedback from the peer user testing.
Since my portion of this project was implementation as well as user research, I would have liked to get more time directly with user testing with people much further outside of my contact set.
Bringing in designs for their portion of the project too, it was my responsibilty to implement and refine some of the idea's and concepts put forward by the rest of my group also..
Suffice to say that Rapid Prototyping was employed and being design led in process we could not document every change to the project where it was defined as a missing feature. i.e. 'This feature is already documented as a need, and shouldn't be documented as a change log'
Examples of my change log... here Rapid Prototype and iteration
How many iterations and prototypes??? 359!!!
Time to test this puppy!
Because choose to work with fluidui. This made rapid prototype and testing in a single phase very quick. In fact, it was possible to make changes live whilst people were testing the application and quickly refine features that were needed, where they should be, how they would be interpreted by the user and clean up the interface as the development was happening.
I cannot show more appreciation for tools like fluidui.com enough and credit the speed of the process to the ease of use to the product.
Live Testing is available here... Foodle App - Fluidui Live
Feedback from this phase was in my case direct and fast. Using the OIP question model provided, I found that the feedback I got during testing had much more to do with preferences in the user interface than the actual features in the app. This dissapointed me a little since I put so much effort into the underlying business model, reward system and reviewing feature...
The changes and feedback are included in my change log in the previous post.
I encourage you to take a drive by through our Foodle App in the link above. And let me know how my user interface works out... and perhaps you'd like to leave a comment on it and if you have the time? leave some answers to some of my questions....
Do you feel like your navigate through the app was natural?
What features would you expect from an application like this?
Are there any features that have suprised you in this app?
Are there any features you feel are missing from this app?
How do you typically communicate directions and coordinate your dining experiences with your friends?
How important is a review based on a user providing enough information to be able to tell if they are real or not?
How much information would you be willing to provide to show others the same?
Are you competitive?
These were the base questions I asked.. but often my responses digressed into User interface enquiries... So I focussed on fixing those to bring the attention back to the core principle of the app.
... It didn't work. People are strangely obsessed by how something looks, rather than by how it works...
This was my testing experience...
No comments:
Post a Comment