As a designer, the word “port” can be somewhat cringe worthy. By definition, a port is an application adapted from one computing environment to another; however, this four-letter word almost implies a short, sweet re-skin for what is actually a challenging process involving design, development, and stakeholder communication. In the case of some iOS-to-Android ports, a design using iOS interface elements can be put into production that doesn’t necessarily bode well with an Android user. Instead of just “making it work on this thing”, a port needs it’s own process for it to truly resonate with the end user. At Big Nerd Ranch, we use quality time, communication, and preparative thought to make sure that any “port” we make does away with a negative connotation and delivers a quality experience.
Prepare for Android
It should be understood that Android and iOS have a completely different mental model. Navigation, transitions, animations, and design language all change dramatically between the two. In order for the user to fully understand the experience, it must mimic the OS precisely which requires the designer to have a full understanding of even the smallest, most “enchanting” details.
The best way to prepare for an Android version of an app is to familiarize yourself with every part of the operating system (even if you already use it). If you’re mostly an iOS user (like myself), go out and find a Jellybean, KitKat, or L device (if possible), and play with it. Better yet, stick your SIM card in it and struggle bug your way through the user’s experience until it’s second nature. Android users have a developed muscle memory for navigating apps which is imperative for a designer to understand. For designers already using Android, pay attention to how you navigate your own device. Record your experiences, both positive and negative for a number of applications, and refer to these when talking to a team member or stakeholder. Nothing is better for understanding your users than being them!
In addition to this, brush up on the lingo and invite your developers to be a part of the conversation. Android developers are some of the few people that know the operating system literally inside and out. At Big Nerd Ranch, designers and developers work a stone’s throw away in order to ensure this type of communication happens constantly.
Analyze the Existing Experience
When porting from iOS to Android, it’s important to begin separating the core experience from the existing iOS application. Ask the question “what does the user need to accomplish with this product?” and map out the best way to do this without reference to any operating system. If there are existing issues with the core experience, this would be the time to discuss that and find a solution. Although the goal is to create the same experience, ported apps sometimes have the unique advantage of solving a problem that could exist in the original.
Depending on the project, the user flow of an Android app can be vastly different its iOS counterpart due to the increased number of navigation options. Make sure any new user flow first incorporates the stripped down core experience before adding Android specific navigation details. A separate set of wireframes are also necessary to ensure that all elements are OS specific. At this point, with any design, both a hawk’s eye perspective and a user’s perspective should be referenced to iron out any redundancies or experience problems.
Since this ported app is usually part of a larger product, it’s important to implement similar branding; however, that branding should be stripped of any relationship to iOS. Functional design elements (like navigational iconography) should keep with Android design guidelines to ensure that the user understands how to navigate. By keeping this visual design “happy medium”, you’re ensuring visual communication of both functionality and the product’s brand.
With time, consideration, and expertise, a ported application can be an amazing standalone experience for any user. This being said, let’s eliminate frankenstein apps and make the term “port” mean a wonderful, cross-platform experience that everyone can enjoy! To help us in that initiative, join us for our next iOS and Android Design Bootcamp.
I have been asked several times for advice on entering the UX field, and thought I would post my most recent response to a woman moving from the fashion industry into wearables and health devices:
The app industry (even/especially wearables) is a UX designer’s dream. An app is nothing without conscious placement, animation, and movement decisions. It’s 90% content with a bit of gloss added at the end to make it look modern, but most of the “delight” users and clients refer to come from UX decisions.
First of all, I recommend checking out Meetup.com and finding groups near you like IXDA, AIGA, CHI, etc. They frequently have meet ups with free or inexpensive talks, panel discussions, workshops, and social gatherings. There may even be some specifically focused on wearables. We just hosted (here in Atlanta) a talk on Android wearables this past weekend.
We have a week-long bootcamp on designing iOS and Android apps, so have done a lot of competitive research and have a robust list of schools and other training resources. Those might offer more or additional options for you (though this list is long!).
On your mark. Get set. Whoa! The act of running and completing a marathon is no small feat. Neither is the process of designing an app. Both events require weeks of preparation and work. And sprints are only a small part of the story.
Getting up to speed I love running and design. I recently completed my 6th marathon in New Orleans, my 3rd since joining Big Nerd Ranch as a UX and UI Designer. I’m currently training for my first Half Ironman. Every Wednesday, a run group leaves from our Intergalactic Headquarters to flex their legs and lungs after a day of mind flexing. Seems like the right spot to merge my favorite things. So how does one cross the finish line in both activities? As crazy as it might sound, the process is very similar.
The Starting Line If only we could lace up the shoes, and run without preparation. However, a lot of planning has to happen if you want the race to be a delightful experience. Where is the race? How many weeks away is it? Is it a hilly race? How many miles will you be running? Similar questions must be answered in the design process. Who is the user? What is the budget? When is the launch? Which devices will it be used on? If you don’t answer these questions in the beginning, your experience might not go well. The preparation and solutions for one design problem will not work for others. You have to plan for specific experiences.
Building Your Base Much like training, good design takes time. When training for a marathon, you don’t start with a 26.2 mile run. You have to build up your mileage over many weeks before making that final run. Each week is scheduled and has goals much like the iterative design process. Run iterations are based on your race goal and what type of race you are running. The design process works in in a similar way. With user experience design, you have to include continual feedback in the process. This is where sprinting comes into play. Test your design now instead of testing on race day. Did that form work? Was the user confused? Did it solve the client’s problem? You have to interpret what worked and see how to improve it. As a designer, you have to remain aware of the user throughout the process. With running, I usually test new shoes, clothes, and nutrition on my shorter runs. Did the shoes cause a blister? Did that gel make my stomach hurt? Waiting until launch day can lead to disaster. Training and design takes time. The biggest challenge is to not lose focus.
Race Day It’s go time. Your planning and training has put you on the path to a good experience. You have all the right tools at your disposal. Now it’s time to trust the process and preparation. It’s your chance to test the experience. Once you cross that finish line, the “race” is not over. There may be a celebratory beer and a bunch of high fives. But there is also a self evaluation that must be completed. How did it feel? Would you do anything different?
The students in Big Nerd Ranch’s first week-long Mobile Design Bootcamp this month were from all walks of the industry. We had app, desktop, and web designers, Android and iOS developers, project managers, and college professors. The common trait they shared was that they were all seeking app design empowerment.
They were interested in rapid prototyping, user testing, and visual design trends. They wanted to know the correct vocabulary to have a meaningful conversation with their app teams, and to make design decisions in line with the code they were writing.
There has been this line between software development and aesthetic design. A class system of “artistic people” and “non-artistic people” has kept programmers from pursuing more attractive interface design on their own.
Ten years ago, one did not presume to cross that line, lest you be petted on the head and told to go back to what you’re good at. Recently that’s changed in a really big way. A bridge has grown between software and design, and both are not only given permission to cross the line, but encouraged to blur it.
The app market is the gateway drug for many developers to become interested in UX and UI design. The evidence connecting beautiful design, simplified user experiences, and user success to money spent is palpable. Developers can no longer ignore design. Consumers are privy.
That care for design and attention to the actual user adds an element of humanity to software development. It has all the feels now. The humans matter!
As designers at Big Nerd Ranch, it’s our job to make sure our developers come to each project with this understanding and appreciation firmly in place. In fact, most of our developers are eager to take our new Mobile Design Bootcamp to better understand design principles, usability, and platform best practices. They want to know how best to use these tools. Why are they there? What do they do? Why should they care? What does the user gain? I love these questions!
And designers can no longer ignore the numbers, brackets, and letters that make up the code of an app. Our design team is always learning bits of JS, Objective-C, or simply boning up on complex animation capabilities introduced with new SDK’s. They are curious about where the boundaries lie, how they can better converse with developers, or how they can push natural mental models. They aren’t necessarily learning how to program, they are learning what programmers do in order to be better app designers.
We want to encourage developers and designers to blur that line and step over it. To stop tossing designs over walls, and to stop automatically saying no. Start a dialogue. Make better apps.
This year’s Apple Worldwide Developers Conference (WWDC) was, as usual, both an exciting and polarizing event amongst the design and development communities. With the announcement that OSX Yosemite would be ditching Lucida Grande in favor of iOS 7’s current typeface of choice, Helvetica Neue, there are many opinions on both sides. Though some folks are quick to point to things like Erik Spiekermann’s bluntly titled “Helvetica Sucks,” which ostensibly proves how poorly Helvetica Neue reads at small point sizes through various typesettings of the word “milliliter,” the choice to make Helvetica Neue the standard across both OS X Yosemite and iOS 8 makes a lot of sense to me.
Last year’s iOS7 update saw Helvetica Neue become Apple’s most recent system-wide typographic change, and losing Lucida Grande for this latest iteration of OS X continues a pattern of incremental forward motion. John Gruber mentioned on his blog leading up to the WWDC that Apple has been working on Apple Sans, a proprietary sans-serif typeface, for some time. If that is indeed the case, it would be arguably just as easy to roll out a proprietary custom typeface now—but it’s likely that Apple Sans is still in the works. And although it may seem like a missed opportunity, it’s also possible that bringing the two OS’s in sync with Helvetica Neue now will help ensure a smoother introduction of their custom typeface ahead of this Fall’s consumer release date.
I’ve personally never had any issues with reading Helvetica Neue at smaller point sizes, but I recognize that some folks may. But with retina displays becoming more prevalent every day, any legibility issues with Helvetica Neue will continue to diminish. Structurally speaking, Helvetica Neue fits well in the space used by Lucida Grande at the same point size—an important consideration when ensuring that any system level typography update won’t dramatically impact existing OS X user interfaces for the worse. That said, it’s still tough to argue against the fact that Helvetica Neue is a robust, versatile typeface that fits Apple’s aesthetic very well.
As it relates to both design and development, typography is all about hierarchy, order, and clarity. Helvetica Neue is an updated version of Max Miedinger’s 1957 original Helvetica that carries a modern, clean feel, and is very much in line with Apple’s minimalist brand. The family includes extensive variety, meaning there are many options for establishing clear hierarchy using various weights, styles, or combinations of the two. Bringing the current iOS system typeface into OS X certainly makes the overall user experience more consistent between both OS’s, aligning with OS X Yosemite’s new push towards more seamless integration of workflows between phone, tablet, and laptop / desktop interfaces. Sure, the same could be said about any typeface that’s standardized across systems, but with Apple having made a push for Helvetica Neue in iOS7, it’s much less of a leap for a user to find familiarity in the look and feel between experiences. This translates to a greater overall comfort with the UI.
In the design community, opinions on typography often come off like snarky reviews from a wine tasting, and it’s always in fashion to question Apple’s wisdom as far as UX / UI decisions are concerned. But, in the immortal words of The Dude, “You know, that’s just like, your opinion, man.”
As is all of the above.
This video, posted to Designer News today, made me think again about using Illustrator in projects. I quickly adopted Sketch when it came out and haven’t regretted it much, especially over Photoshop. The focused feature set makes Sketch a pleasure to use in virtually every respect but this one. Namely, that as my project gets more complex, especially during the mockup phase, Sketch performance tanks. I end up trying to work around the issues, creating separate Pages to store ideas for different pieces of UI, turning off blurring and other expensive rendering or taking screenshots to temporarily replace them. Bitmaps aren’t wonderfully fast either and I have to trim before dropping them in to increase speed (though to be fair I hear Illustrator has similar issues). If there is a chink in Sketch’s armor this is it. It hints at a fundamental question of our tools. As professionals should we really fear complexity at the cost of performance? At the Ranch we find that Sketch is far less frightening to new users and terribly quick to work with. There will always be a place for it. But where it fits in the toolbox when viewed across the spectrum of a project is worth every designer’s examination.
Essentially we’re 28 comps in and 9 weeks into design, and we haven’t even coded the thing yet […] To me, when I look at 28 comps and 9 weeks just to get to this point, it just feels wrong. It feels like there’s got to be a better way of doing this. A way that’s more efficient, a way that’s faster, a way that’s better to communicate to clients.