Have you ever thought, “There’s nothing to do in [insert name of town you live in]?” Many have. They think where they live has nothing going on. I set out to prove them wrong by giving them a way to find these local events.

The solution to the problem: an app called Planit.

I actually did this project with another student. I did the design and user testing while he did the developing. So this project very much resembled the real world where one person or team focuses on user experience and design and has to collaborate with the developer to see what is possible, what we have time to do, and what we have the money to do.

The 4 phases of design

  1. Asking questions
  2. Visual research and brainstorming
  3. User Testing
  4. Adding Details

As I take you through these phases you will better understand what it takes to create something that not only looks good, but works well because of user testing.

Phase 1: Asking questions

You may be thinking, where did you start? That was seriously the biggest question. At the very first meeting we had I asked questions. A lot of questions. Questions like:

  • What will make our app different?
  • What is it’s purpose?
  • Will we develop and user test it for apple and android?
  • What do the users need or want?
  • What do we want completed in the next 3 months?

Then I researched screen sizes for apple and android and began sketching. From sketching I quickly discovered that we needed to decide how we want users to find events and how would sorting work?

firstpage-01

I found out that before I could answer questions about how to find events, the first thing that needed to be defined was the purpose of the app. All apps should do one thing really well, so what would ours do?

Provide event awareness. That was our purpose. This helped us make many more

decisions down the road.

Phase 2: Visual research and brainstorming

Just to get started I looked at a few other event apps and drew up these screen concepts.

concept1   concept3concept2   concept4

But which is best? The one that the users understand and like best. This is when I came up with the idea of how to see what users want to know about an event. What do users want to see for each event as they scroll through and then once they click on an event what information do they want to see then.

Survey: Desired event information

I wrote all the event details on little pieces of paper and on another piece of paper I divided it into three sections. Then I asked people to put event details into three categories, “Must Know to attend event,” “Good to Know to attend event,” and “I Don’t Care.”

0108151537a0108151535

I showed each person I tested these two screens and explained I wanted them to categorize the event details based on the screen where they’re scrolling through many events and then do it again for the screen that shows an event once it’s been clicked.

0108151538

0108151538a

Results: The three most important things to know about an event besides the name are the time, cost, and distance.

Based on the results and looking at other apps, specifically event apps, I drew up some more sketches. In the interest of saving time I’ll cut to the part where I get ahead of myself. Without thorough user testing, I mocked up the design. I was still in the second phase and I was already mocking things up which is phase 4! And it’s a good thing I didn’t go with this design because once I did test it, I found out that the slider idea wasn’t appreciated by the users.

webapp_eventview-09 webapp_eventview-10

Phase 3: User testing

otherscreen-01By this step we had decided that we were going to sort through events by time, cost, and distance. We knew we wanted the user to be able to switch between the three but had no idea how to do it well. Since this was the main issue, I’ll take you through some of the scenarios I tested that have to do with this.

Keep in mind that in each of the 4 phases I’m doing visual research. This screen on the left is the app Eventbrite and the screen that sorts events. So I set out to try my hand at doing something to this effect.

 

screens-02   screens-01

When I user tested this I found many problems. The user didn’t know how to sort by cost instead of time, they didn’t even know it was a feature. I just asked them to find the cheapest events so they looked manually, instead of using the sort button. How are they supposed to know what that button with the clock even does? Changing the day was a bit easier, but it wasn’t the fastest way and it’s hard to select the day you want because it’s fairly small.

screens-05

So I changed the buttons a little. I added the words “Sort by” and added a calendar icon beside the day. So instead of clicking on the word, the user would click the calendar icon. The sort by made more sense but now the user didn’t want to click it because the word sort is a verb and that involves thinking, which is what users don’t want to do. This design didn’t work either.

 

 

 

I brainstormed other ways to represent how to sort by time, distance, and cost.

screens-03    screens-06  screens-07screens-08

 

 

The one I liked best was the three in one button, shown in the image below. But when I tested it, the user had no idea what they were looking at. Three icons in one button? Not working.

screens-04

I tested the next one I thought would work: the three separate buttons side by side.

horizontal_sort

This tested well and so I moved on to many other questions about functionality, of which I’ve spared you the extensive details.

Phase 4: Adding details

Scenarios-07After more testing and visual research I got to this mockup. I kinda have a logo going on now, I’ve included a slider that allows the user to easily switch from day to day, and I’ve added the users location on the top.

In this mockup I’ve decided the picture will go where the blue box is, the title will be next to it, and then the three pieces of information will show on the side (the clock is highlighted blue because right now the user is sorting by time.

 

 

Questions-10

Based on feedback, I tried the same basic layout, but moved the navigation to the bottom because apple users are used to navigation being on the bottom, while android apps have navigation on the top.

I got an overwhelming dislike of the navigation being on the bottom. The user wanted to see where they were and what day they were on before looking at events. Having the nav at the top kept the events in context. The hierarchy just made more sense.

 

 

Done_Artboard 6 copyBased on more user testing I added icons for each event, removed the hamburger menu (3 lines), moved the event details to be displayed horizontally (this way they can be compared easier), and finally I added a button to add to calendar (which will add to the calendar that is installed on the phone already).

 

 

 

 

 

Here are the images that show what happens when the user clicks on the title or image for an event. The box expands to show more details. Then if the user wants to still see more they can click “more details.”

Done_Artboard 4 copy    Done_Artboard 5 copy

There you have it.

mockup

A “brief” look at an app that took roughly 50 hours to concept, design, user test, but not develop. The actual development of this app is still in the making. A prototype has been made, but we don’t want to show you just yet.