Designing for mobile.
The things I learned and the decisions I made.
How I got here
Last month I wrote a Medium post that gave a detailed look at my process for redesigning the Yelp app for iOS. I had no idea of the power of the Internet until I published this story. In one day, the article went from 400 reads to over 11k after being picked up by @sidebarIO and posted on Reddit. The ripple effect was astonishing: I would have never thought that such a number of people would be interested in reading about my design work.
The second thing to come out of the experience was the opportunity to work on a real UX/UI project for a start-up here in SF, a company called Meed. Meed aims to bring students together with employer and other students. I’ll go into more detail a little later.
I’m going to keep this short, since doing design — or really anything you love — should not be about the money (though my Netflix addiction isn’t going to pay for itself). Since this was my first contract, I had no idea where to start with pricing out my work. I used a combination of techniques to settle on a number:
- I called one of my good designer friends (a good designer and a good friend) to ask what a good starting price would be— luckily, we had the same number in mind.
- I used hellobonsai.com/rates, a site which allows you to see what other freelancers have charged in the past.
Don’t overthink this. Throw out a reasonable number — something not too low to show that you are confident in your work, but not too high, if you are just starting out. Start the conversation and go from there.
After chatting with the CEO of Meed for a little while, he asked me to come into their downtown SF office to talk more about the project. The condensed version of the story is this:
Meed went live in February, 2015, on the web. With a rapid number of users joining the site each month, they felt that it was time to launch a mobile app. (Cue the Mission Impossible music) My task, should I choose to accept it, was to build a mobile version of the website offerings with full creative freedom.
I’m going to go through this process a little bit differently than I have in the past. Instead of talking about the as-is and to-be processes, I am going to compare each section of the mobile development decisions to the current website design.
*I also want to state that while I did have full creative freedom on this project, I wanted to carry on the design language that the website had already set forth. This was to ensure that users would not be too overwhelmed or confused by the new platform.*
Web: The use of different colors on a website can be incredibly useful if you want to draw the user’s attention to a specific area on the screen. On this particular website, the same colors (blue and green) are being used to draw attention to two different areas.
Mobile: I allowed the user to choose between signing in and creating an account. Two things make this important. We want the user to spend as little time as possible on these types of screens in order to avoid frustration. Using different phrases for similar actions allows the user to quickly identify what they want to accomplish. Not only did I choose different verbs to distinguish between the two choices but I changed the visual style as well. “Sign In” is a filled green button, while create an account has a ghost button style. It may seem like a small point, but shaving even a millisecond off of the time a user takes to complete a simple action can have a huge impact on the experience.
Sign up/Sign in
Mobile: The landing page of the mobile app enables Meed to identify why the user has initially opened the app: whether it’s to sign in to an existing account or sign up for a new one. If they are signing in, the screen to the far left would appear and ask for appropriate credentials. If they choose to sign up, the middle screen would appear and ask if they wanted to sign up as an Influencer or a student. Finally, the user has the option of signing in with a social media connect or by email.
Sign up information
Web: In this medium (HA!) it is easy to put all the information needed to sign up in a long modal or page.
Mobile: On mobile, scrolling through a form sucks. Here, I decided to break up the form into three different sections. In the first step, the user inputs typical information i.e. Name, Email, and Password. In the second step, the user inputs the the information about their degree. Finally, the user is sent a confirmation and asked to type in the validation code. In addition to breaking the content up into three sections, I added a timeline feature right above the “next” button. This not only gives the user a physical location of where they are in the sign up processes, but a goal to work towards while filling out information.
As soon as the user has validated the email address, they are taken into the onboarding flow. To let the user know that they have entered a new process, I created a secondary launch screen which gives a bit of information as to what they should expect.
Web: On the web the onboarding process consists of three steps: joining groups, following influencers, and inviting friends. The general concept of completing each of these tasks worked just fine on the web, but mobile required some adaptations.
Communities — I decided to keep the rounded edge squares for the community pages but lowered the radius to ~2px to keep them from looking too bubbly. In addition, I used a black color overlay in order to lower the harshness of images that may be too bright. Ghost buttons allow the user to see the full image before deciding to join the community, which is really nothing more than a nice aesthetic. Additionally, since this style of button has been used quite often in the past, the user knows that upon touch, an action will be taken.
Influencers — An observant reader will notice that I used circular avatars for the influencers and rounded squares for communities. Why not just use circles or squares throughout the app to keep consistency? The reason is that circular avatars have been widely used in many apps to represent people. Most users have been conditioned to know that circles=people and squares=content. This, of course, could just be a trend that changes sometime down the road, but for now it works. To let the user know that a selection has been made, a green ring surrounds the selection upon touch.
*Steps 3 and 4 of this flow are still in beta, but they basically allow the user to search the Meed people database in order to find friends via their names, emails, or Facebook profiles.*
Mobile: The dashboard is a huge part of the mobile experience. It’s the first screen the user sees after the initial log in. I spent a lot of time trying to think of interesting ways to port over the functionality. Starting at the top, I pinned the search bar and avatar to the top of the screen so that the user could always search no matter the scroll position. The avatar allows the user to jump into their own profile. Just below the search is the status update bar where a user can type a status and tag the status appropriately with the icon far right. The status bar, unlike search, is not pinned to the screen and disappears behind the search bar when scrolling begins.
Next, I want to talk about the feed. I don’t want to harp too much about the actual arrangement because its a fairly standard layout of an avatar to the left of a post. I will talk about two things specifically though.
Meed Badges — Each of these badges represents a different level or status a user can have, depending on their qualifications. On the web, a smaller version of these badges are placed on top of the user’s avatar to allow users to quickly identify the badge associated with a given user.
In the mobile version, I decided to go with a stroke around the avatar instead of the badge. There are two reasons for this:
- Having a badge would take up a lot of space, which we really can’t afford.
- The letters associated with the badge can not be distinguished when shrunk down to the appropriate size.
Since this badging scheme is not used anywhere else, the user would need to get used to what each color means. On the web, users can access a key by clicking their own badge on the topright portion of the navbar.
On mobile, I created a key that appears when the user clicks on the “more” button located in the navbar.
Navigation Bar — Like most social media apps, Meed needs a navbar to reach certain parts of the app quickly. Dashboard and Notifications are pretty self explanatory. More takes you to the badges key as well as app settings. Discover allows the user to view trending tags, communities and influencers. Finally, Jobs shows the users all of the available job postings available through meed.
That’s a wrap
That’s a wrap? Whoa, where’s the rest of it?! There is actually a whole lot more to the development of this mobile app but I just wanted to share some of the highlights. I wanted to write this for people who may be starting out in the design world and don’t really know why designers make the choices they do: “Why did they choose that color?” “Why did they use this shape?” “Why is that not centered?”
These are all questions I had when I was first starting out and I really had to dig to find the answers. Working on my first freelance project was an awesome experience and I can truly say that I have learned so much: working with a client, thinking about the user, creating multiple options of the same screen. Beforehand, all my projects were for me — I was the client. Actually having a person request work from me and discuss design decisions with me was an opportunity I had never been given. With this first app under my belt, I’m excited to get started on the next one.
I would love to get feedback on this post or the project itself. Find me at KennyLopez or firstname.lastname@example.org | Portfolio-kennylopez.co
Special thanks to Rachel George(check out her portfolio)for reviewing the draft