ITaaU/ustwo UX Bootcamp – 11th February 2015.

This is the second of three posts on the recent UX Boot Camp that ITaaU and ustwo organised on the 11 February, 2015 written by Alix King.

Part two

To experience the methodology and processes behind user centred design when developing new apps, the groups were given a task for the day; to design an app.

The design brief

The design brief was to develop a mobile app for a gym in East London. The gym would like to attract young people via a digital platform that would also benefit the company.

The day was set out into six sections:

1. User Testing
2. New Assumptions and Hypothesis
3. Sketching
4. Prototyping
5. User Testing
6. A pitch to others in the workshop.

First, the groups had to set out their vision: what was the vision, and what was the overarching goal of the product?

Persona

Ustwo introduced the group to the Persona technique – a tool to help understand users’ needs. They are fictitious characters, based on real data, to create a profile. This introduces to the developer an audience, and in more detail, a person that the app is to be created for, helping to keep users in mind during a project, focusing the developer on the ultimate target user.

Draw a box

The groups were then asked to ‘draw a fictitious box’; a box-shape with the goal of cementing the idea of what each groups’ service is. After the groups drew the box, they were to give it a name, image and tagline. The idea was then to create three benefits that the service would have for the consumer. One group described the benefits from downloading their gym app:

• To be healthier
• Getting/making more friends
• To enable the user to switch off from work.

Merging ideas

The groups were then given 10 minutes to share their ‘fictitious box’ ideas and to merge each idea into one service/product that they liked the most.

Declare assumptions.

Then the groups had to ‘declare assumptions’. They were to write on post-it notes what the group thought to be true about the business and the user. The assumptions were differentiated by blue post-its for the business assumptions and yellow for the user. Examples were given as ‘We assume that the business has good connections with surrounding football clubs and other sports organisations’ and ‘we assume that the user would be interested in exercising along with people they don’t know’.

Prioritise assumptions

With these assumptions, the groups were then asked to set their priority based on their level of risk and how much faith they attached to the assumptions. These were plotted on a graph of high risk to low risk, known and unknown. This was to make the group members think about what would jeopardise the proposition if that assumption was wrong.

Develop hypothesis

The next step was Developing Hypothesis. In 10 minutes, the group was tasked to transform an assumption statement into a testable hypothesis. This was completed using the following template:

“We believe [doing/creating/providing] …. for [these people/personas] …. through [this feature] …. will [achieve this] …. we will know this is true when we see [this user feedback] ….”

This hypothesis was given as an example:

“We believe that offering the opportunity to connect with other people to exercise together for young people under 25 in Shoreditch through geo-location will increase the user base of our service. We will know this is true when during user interviews the majority of participants express a positive attitude towards this feature”

The next goal was to visualise the group’s chosen hypothesis. This was done using a screen sketch template, with the team sketching images of the app screens onto paper to show a simple screen design that will be shown to users.

User Testing

The groups were then given a user to test their screen design on. Georgios and Isabelle gave the groups directions on what to ask the user, such as not to direct them and therefore gain more subjective answers.

The points were:

• Introduce yourself
• Build rapport
• Ask them to speak out loud
• Don’t ask leading questions
• Ask open questions
• Ask what, why, when, where
• Take notes
• Playback learnings to the team.

The goal for user testing was to validate if it was a desirable proposition, and to gather the user’s subjective view of the proposed app. The groups were given two users, who were chosen from the staff at Ustwo, with no prior knowledge of the app development so far.

Test one

Groups were given 20 minutes to go through their screen landing page and vision for their app with no leading questions to gain the user’s opinion of the app. Did it seem easy to use? Did the app provide the user with everything they expected to gain from the vision that the groups were offering?

The groups were told to put down their findings, one by one on an individual post it note.

Updating assumptions

From the opinions that the groups ascertained from their users, Georgios and Isabelle instructed the groups to then update the assumptions that they had gathered previously, now that they had subjective opinions from the users.

Create and test a prototype

The groups were then asked to get creative – using an app (frequently used in the industry) called ‘Pop’, the task was to draw each screen of their app idea, to take pictures of each screen, and upload onto the Pop app. When uploaded, this digital tool allows the user to see the finished app idea, with pages on a digital platform. Groups were told to think about:

• Navigation
• Text/copy
• Button placement

This was a great task, as the groups could visualise their ideas in the format of a useable application.

User test 2

The idea was to test the ‘useable app’ on three different people. These were now members of the other groups. One of each of the team would go to another to ‘test’ the app, while the remaining two would stay to run the test app on the visiting user. This was circulated so every member of the team experienced being the tester and the user.

This exercise showed completely different opinions than the first user test. The groups then made notes of changes and improvement ideas that they would implement before further advancement of their app idea.

To be continued…