Failing Fast: The unspoken process behind well-designed apps
“Failure” — the last word any board room wants to hear. Most people see failure as a bad thing, especially when it comes to new product design. But thanks to new business concepts like “lean” and “agile” spreading like wildfire, the business world is beginning to finally understand the benefit of embracing failure. The reality is that all new product ideas fail as soon as they make first contact with the target customer. Forward thinking companies are finally starting to accept this reality, and encourage their team to fail as quickly as possible, over and over again, until the new product requirements are certain, drastically increasing the odds of a successful product launch that is accepted by the market.
Over the past few months, I wanted to prove to myself that the concept of failing fast actually works. I started the app creation process 10 weeks ago. Each week I implemented a new User Experience Design concept. I learned the importance of going to your users first in order to avoid developing an app or app features that the users don’t actually want, the importance of storyboarding and paper prototypes, and finally the significant amount of insight attained from user testing. I will be explaining the methods of User Experience design while using examples from my app that was developed over the course of the ten weeks.
I wanted to develop an app that would encourage people to go out and help others. I believe that people can find deep joy and contentment in doing something nice for their fellow humans, so I made an app that helps do just that.
Charity Now is an app that allows same day volunteer sign up so that there are no more excuses. I know a lot of people who would like to volunteer but find the process difficult. Charity Now streamlines the sign up process from the selection of the event all the way to the registration; it even allows you to sync your charity event with your phones calendar in order to get reminders close to the event time.
In order to develop Charity Now, I implemented User Experience Design principles from beginning to end. To start with, I brainstormed a list of potential app features that could be helpful to the users.
Step 1: Ideation
Coming up with an App concept. Below are some brainstorming ideas I wrote out for the Charity App.
- App should be able to link the person with a charity that needs help within that same hour to allow for last minute charity work.
- The charity work should include food kitchens, old age homes, helping special needs groups, garbage cleanup, elderly care, spending time with the lonely, clothing drives, church ushering, singing in a church choir, clean parks, planting trees, etc.
- App could have a filter for family friendly volunteer activities (could take kids along if you are a stay at home parent).
- Goal planning: at the beginning of the month the user wants a prompt at the beginning of each month to ask what days you would like to volunteer.
- Reminders throughout the month.
- Gamify the app: user wants the app to allow them to win “heart
- Location could fill out your goal logs, could track how long you have been at the charity event and the app will automatically log this and give you “hearts” or points based off it.
- Location of charities: can filter by closest to you and parking safety/how easy it is to park.
- Aid with court ordered volunteer work. Email your progress to court ordered supervisor, perhaps the app could allow an E-Signature from your volunteering manager.
- Super easy to use interface.
- Give the user the ability to compare their “charity” scores to their friends or perhaps even strangers.
- Give the user the ability to watch over group of people using the app, for e.g. a highschool teacher hoping to keep track of her students charity work for school tracking purposes.
- Ability to facetime with elderly to keep them company from a far.
- Notifications to let them know that they missed a nearby charity event.
Of course, I could not implement all of these ideas. In the next step “Needfinding” I interviewed potential users to find out exactly which features they cared about.
Step 2: Needfinding
Needfinding is the process of finding out what your target market really wants. A more detailed definition is watching and asking people questions to learn about their goals and values to be able to uncover user needs and opportunities for improvements.
The tricky part is to not ask any leading questions. If you ask your audience the question “Would you like a charity app that allows you to volunteer this instant?”. This is a leading question and you will probably get a yes or no answer which is not likely to represent how they really feel. The correct way to pose the question is “If you had an application that allowed you to sign up for volunteer events, what features might you like to see?”. This allows the interviewee to talk and your interview will be more fruitful, providing you with insights that you may have not thought about.
I interviewed a few people that represented my target market. I wanted to make this app for all ages so I interviewed 3 people with ages 24, 48, and 73. Needfinding allowed me to identify two key features that the users wanted: 1. The ability to sign up for volunteer work on this day. 2. The ability to sign up for volunteer work on specific dates in the future.
3. Observation
In order to further identify customer needs it is important to observe your target market performing the design task using currently available resources.
I observed people of varying ages sign up for volunteer work using their phones. The result was clumsy. A lot of the volunteer websites are not created for mobile devices and were hard to navigate. The process of signing up for the event typically involved a phone call, which seemed off-putting to the users.
The other main issue observed was that the users were unable to find a website that displayed all of the available volunteer opportunities in the area. Thus, they were clicking around between sites to find volunteer opportunities for the days they were free.
4. Personas
Personas enable the designer to focus on a manageable cast of characters, instead of focusing on thousands of individuals. I created a few personas which represented the type of individual whom would be using my application.
The personas included a picture (from online stock images) representing the user and a detailed paragraph about the “person” including where they worked, modes of transportation, what their daily routines looked like, etc. This helps keep your design focused on your target market.
5. Prototyping & Storyboarding
Prototyping can be done in many ways, but initially I believe paper prototypes are the best way to gain knowledge about your users without investing too much effort. Paper prototypes allow the testers to give honest feedback as they are not worried about hurting your feelings — its just a paper prototype, not something you’ve invested hours of your life on. In addition they force you to walk through your design and help you identify holes in your workflow.
Storyboarding is typically done in a sketch format and shows the identified users while they are using the application. These sketches include characteristics identified in the “personas”.
After collecting data from my interviews I sketched out 2 different workflows. The first workflow is the “Volunteer Now” path, the 2nd workflow is the “Volunteer Later” path. The storyboards and prototypes show both paths.
6. Clickable Paper Prototype
Developing a “clickable” paper prototype is helpful if you want user feedback on your workflow. To make a clickable paper prototype I drew each page of my app on a cut out square piece of paper, allowing the user to advance through your prototype as if it were a functional app. The clickable prototype was tested by a colleague who gave me feedback related to Jakob Neilson’s 10 design Heuristics. The clickable paper prototype is especially helpful in identifying holes in your design.
Heuristic Evaluation Technique is a technique that consists of having a small set of evaluators examine an interface and judge its compliance against a set of established rules (heuristics). A typical evaluation would consist of evaluators working through a task flow, documenting findings and high-level recommendations as they go. The usability issues found are then ranked in terms of severity and additionally in terms of ease-of-fixing from a design and development perspective. Below is an example a heuristic evaluation I performed for a friends app.
I learned to appreciate Jakob Neilson’s list of 10 Heuristics. They held my application against a design standard, which helped identify a few areas for improvement that I would not have otherwise noticed. Here is an example of a Heuristic violation and the change I implemented:
7. Develop Prototype using Sketch & Proto.io
Finally it was time to design each application page. Using the feedback from the heuristic evaluations, I edited my prototype. Next, I used Sketch to create each page of the application and used Proto.io to make my application interactive. The initial application I created was a wireframe. I knew that my application had yet to go through user testing, therefore I waiting to add the aesthetically pleasing elements until I had more feedback.
8. Test the Prototype
I asked a few friends to test my prototype and ran a usability script for each tester. The usability script assigns tasks to your testers and allows the developer to observe how easy or how difficult each task is. During the test it was important to allow the testers to run though the app on their own, obviously if they were at a complete dead end, I would offer minimal guidance to help the tester get back on the right track.
I recorded the results from each usability test and implemented some suggestions from the tests into a separate application. For example, one tester wanted to select from different volunteer categories before going right into all available charity events for the day.
Some suggestions from the Usability Tests were implemented in a second version of my app. The second version of my app was later used for A/B testing.
8. A/B Testing
After the wireframe was completed, I submitted my application to UserTesting.com to get feedback between two different designs. I designed an A/B test that was comprised of 35 questions. This test went out to four people who read each question aloud and gave feedback as they were performing the actions.
The A/B testing was immensely helpful. The testers gave me information on which workflows were preferred and certain aspects of the app design they did or didn’t like. Some of the testers even gave useful suggestions on alternate design options. For example, one tester suggested that I allow the user to select the calendar dates and select the events for each date all on the same page. I ended up changing my app per her suggestion and it helped streamline the process and remove some confusion.
9. Complete Application
After the A/B Testing was complete it was time to implement the feedback into my final prototype. I ended up changing a lot about my application after the A/B testing, mostly because the UserTesting.com feedback.
Final Thoughts
Over the course of 10 weeks, the Charity Now app changed immensely. Looking back, it’s clear to me that the first few iterations of the app were flawed, and it wasn’t until after speaking with multiple users and multiple iterations that the app became intuitive. Each iteration along the way garnered less and less critical feedback, helping me finally narrow down the desired look and feel.
The User Experience Design process of rapid prototyping and constant user feedback was critical in helping me realize the design failures early on. By embracing failure instead of avoiding it, I was able to more quickly achieve success.
