Presentation - Team work and focus.

 The mobile app for the critical food lover!

A brief on the presentation planning. 

Here was our presentation planning meeting notes.

The minutes here described the features, niche, market, storyboards and generally how we were to tackle the presentation.

The needs on the right showed 3 storyboards which we felt were important to show potential users how this app would enrich their daily lives. 

With 4 people to speak, the work was divided as such:

Nicoletta really wanted to do the opening speech and describe the app, the target audience and how we differ from the competition. I would have liked to been the opening speaker but with my role now supplying all of the art assets, prototype, live testing and refinements. My hands were full to create a suitable presentation. With extensive Prezi experience, she had some wonderful ideas on how to create and demonstrate this also. So I was happy to let her continue with a 4 slide setup to describe the key features and competition and so on.

Chris, Peter and myself then were to tackle the demonstration of the app and how it relates to 3 storyboards.

• Needs to search
• Needs to have reliable reviews
• Needs to be rewarded for contributing

Since I already had these storyboards templated up, it was quite easy to give the templates to Chris and Peter to put their own spin on my idea, if for no other reason than consistency in the presentation. Nothing wrong with their work, except mine has a particular style and was more polished for demonstration.

Those 3 Storyboards are available in a previous post.

Getting closer to the presentation, we had a test run of the speeches and that's when I saw how nervous my group was... They spoke too fast, were shakey in their voice and presentation and weren't actually "presenting" the content.

I decided to source some background music to go along with out app presentation... Okay so as it turned out, it annoyed some people for 12minutes, but others really enjoyed it and thought it added to the experience.

Here's my reasons for doing so...

• "Kickstarter" music... no-one else was doing it.. and I wanted our team to stand out. 
•  It set a pace. I used the pace of the music to set a frequency for each speaker to time their speech. 
• It calmed awkward silences... which it thankfully did when we experienced internet issues that effectively killed my part of the presentation.

In the 2 hours before the presentation, I gave all our team members some basic voice coaching training. Tried to make known the differentiation between 'Talking about something' and 'Telling someone about something'. Advised them that it was a 1 way communication channel and that their style had to reflect this. Never finish a sentence as if it were a question! Because they aren't going to answer... Be excited about this product as if you couldn't live your own life without it. And to be passionate about how you've implemented it. Have confidence in your own work.

So, having feeling somewhat confidently prepared, we entered the room only to find that the presentation space had changed and how we were to demonstrate the application was unavailable.

Thankfully I'm pretty good and thinking on my feet and within moments had an alternative ready to go.

I think my team spoke well if a little shakey at times. Nicolette for a brief moment forgot my advice to not present like a 2 way conversation and tried to engage the audience... Thankfully she picked it up quickly again and was fine. 

Peter and Chris presented shakey also, but atleast they had visual reference by my interaction of the app and the storyboard.

This is where problems which were already apparent in the beginning of the demonstration had now failed completely and my portion of the app to demonstrate was now no longer available to show.

I'm a planner, I don't believe in only 1 solution and as such in my career have developed a habit of having contingency plans. ("never trust an engineer who only has 1 idea" - M.Gallon 2009).

I had developed a backup powerpoint presentation in the event that my team members did not come through with the goods on the day. It's just habit but one I'm glad I'm in.

The powerpoint presentation I performed on the day was not something I had specifically scripted, nor practiced at all. But was a dot.point prompt for me to speak on my app. Since I had the majority input to the final product (perks of doing it myself), I could confidently speak on what I was trying to portray.

When I started speaking, I had to reset my mind and clear my thoughts of the momentarily flustered moments of trying to recover the technical problems. After conceeding defeat, I went to my back up presentation. Here I felt more comfortable again as I got back on my feet and thought "How would Steve Jobs present this?".... well I had no time to go shopping for a turtle neck.. Confidence! Explain this as I would explaining my technical solution and project estimations to a Queensland Rail stakeholder financial board meeting. And thats exactly what I did... I wouldn't say I wing'ed it... but thinking on my feet and experience went along way.

Thankful that I put in SOoooo much effort into this project, that I knew every part inside and out. Confidence in your work goes a long way to being able to perform under pressure. 

I hope eveyone enjoyed it.

:) 

Mark.
Creator of Foodle - The mobile app for the critical food lover!

My presentation backup speech





 

Modes and Mindsets.... My Design thinking process...

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...