Detailing an App’s Interface

prototyping-page5.png

For the past five weeks, I’ve spent a considerable amount of time creating an in-depth, digital baseball scorekeeping app from start to finish. This included details such as the proposal, user research, and wireframes. With all that in mind, I’m now at one of the most crucial steps in the process, which is taking all my research and manifesting it into a fully functioning prototype.

Color and Type

Before jumping right into the prototype though, I need to figure out what my final typefaces and color’s will be for the apps. For my colors, I first started by testing out a few different shades of black, as that will be essential for features such as the type and physical design of the scorecard as well. After that, I started thinking of how I could implement other colors. Going by my wireframes as well as how many other sports applications do their colors, I decided to go with a feature that would allow users to choose which color they want the app to feature. Sports apps often give fans the option to make their app themed after their favorite teams, so I thought this app should follow a similar principle.

To give a good example of this, I ended up testing out a few different reds and blues. The options would be far more vast than that in the final product, but I felt red and blue gave a good showcase of it as they’re easy to tell apart as well as the main color for many teams. Beyond that, I also tested out a cream color in case it was needed for certain buttons and what not, though it’s not as prominent as the other colors mentioned.

With the colors straightened out I then moved on to the typography, which I feel was pretty easy. Much of the type in this app will be from the user manually writing in the scorecard, so the only type I needed was for headers as well as small body paragraphs. For header’s, I wanted a serif font, as that matches well with the old school look many scorecards have or try to insinuate. For the body, I knew that most of this text would probably be small things such as the score of a game under a card, so I felt a sans serif was needed to make sure it’s legible on the screen. I also wanted it to be a fairly simple font in general as easy to read type would help the accessibility of my app.

Final color and type studies

Final color and type studies

Prototyping time

With a set idea of what colors and type I’ll be using, I began implementing them into my wireframes. I made two separate versions of it, one using the red color and another using the blue to help show how color selection will affect the app. While creating the wireframes and looking at the critique I got, I began to notice the app was missing something. I had a whole community section with ability to upload a profile picture and scorecards, though no actual profile page. With that in mind, I added on a profile page to my app, adding in features such as the ability to show off cards, memorabilia, and old tickets. I didn’t want the profile to be too crazy and distract from the main draw of the app, the scorecard, though having this profile section I feel will help the personalization of the app for many, as well as a fun way for baseball fans to share some of what they like.

A example of what the profile page looks like

A example of what the profile page looks like

When trying to create a second mock up for my prototype though, I struggled to think of ways to change it up. Much of the core design is focused on the physical act of keeping score and there’s not many different ways to design that. I then began thinking of what is most frequently used in this app, which is the navigation. Much of the time with the app when not scorekeeping will be spent surfing through all the different screens and other scorecards. The traditional navigation bar at the bottom works well enough, though I wanted to see how it may feel with something different.

When researching navigation, the most common one I usually find is the hamburger menu. This menu style is very frequent on sites, though it has its detractors. This article from UX Planet goes into great detail listing some of these detractions, such as how it doesn’t properly showcase features as well as not being clicked on frequently. This article also lists the positives, as well as potential alternatives to the traditional menu.

Despite the drawbacks, I felt the only style listed in the article that would fit well with this app was a hamburger menu of some kind, though with some variation. You can get to the menu using the traditional hamburger navigation, though I also made it like the sixth alternative listed in the article,

which is a slide out tab. I felt this style helped maximize the screen space of the app while also allowing a quick way to surf through the app. This style also lends itself well to the profile page, as it makes it easier to access as compared with the other mockup

An example of the second navigation style using the home screen

An example of the second navigation style using the home screen

Overall, I unfortunately only was able to finish up two mock ups compared to the three I wanted to do. I did obtain a lot of value from designing and testing these mockups though, which will help me finalize a design, as well as expand on the app in certain ways in the future.

Full set of prototypes

Full week 6 production journal

Previous
Previous

Making an InVision Prototype

Next
Next

Narrowing the App’s Focus