How to approach redesign in the mobile world
Set up redesign goal
Discussions with different teams allow us to collect specific needs from all stakeholders, making sure each is given the proper consideration during the redesign process and that the ultimate product achieves its full potential. Key part of this process includes early involvement of product managers, designers, and engineers. This will significantly reduce the chances of surprise when we start the next step, execution. These discussions help tighten our focus, set a clear vision and goal for the redesign. It builds common understanding for how the final product should look, feel, and function; the dialog paints a verbal picture of the design and aids in the development of a true framework (UX/UI guidelines & toolkit). And makes sure everyone is aligned in applying the best design practices that will transform Sing! into a simple, accessible, delightful and desirable platform for our users.
source: shutterstock
Plan for launch
Incremental feature changes
Before we kick off the redesign, we needed to determine a launch strategy that will assure the success of redesign. In the previous discussion, we found Sing! needs to change its global navigation to improve feature discoverability. That means changing from the once industry standard hamburger navigation to bottom navigation. This is a significant, core level change, for the product. We have to go back to the drawing board and reconsider: what are the primary features, and what is the reasonable, functional, hierarchy for navigation. The first question is whether the navigation change should be a separate release from the redesign or if it should be rolled into the redesign release. We know from past tests and a thorough review of the existing industry case studies, both of these changes will have a significant impact on the product’s performance. Historically, when Smule has introduced a new feature or design, the process has worked like this:
1. Create a hypothesis
2. Design and build the feature
3. Release the feature to users
4. Measure and analyze the new feature performance
5. Evaluate whether the feature achieved the goal or validated the hypothesis
6. Validate the original hypothesis
Using this methodology, it is always better to release design and feature changes one at a time. It isolates changes that can be an unintended result of the redesign, or cause incorrect data measurement. More importantly, it gives time to fully understand the qualitative impact of each of the changes (navigation and redesign) from the users perspective.
Choose the platform and lock resources
After making the first major decision to release these changes sequentially in two separate releases, the next question was whether to release on iOS or Android first given the following factors: (1) All these design changes themselves are high risk; (2) We can’t afford to do an A/B test to validate the hypothesis; (3) We have very limited design and engineering resources. Based on these given factors, we agreed that implementing these changes on one platform is the better option to minimize the risk. But which platform first? Compared to Sing! iOS, Sing! Android had fewer features and worse engagement and retention numbers than Sing iOS. This means less risky to apply the navigation design change and redesign to Sing! Android first. This decision helped locate and lock the needed design and engineering resources. We have a very lean structure and a small team. We are fortunate to have one visual designer and four engineers join me to work on the two phase Sing! Android redesign project. One of the challenges at this point is to make sure we fully understand and scope the design work needed. This will be discussed in the following design execution section.
source: shutterstock
Let’s design!
Scoping design effort
Changing the navigation and the redesign project were two big design driven projects. When scoping the design time requirements, it is critical to build in enough time to research, explore and come up with the right design solutions while executing in a lean and agile process. As the design and project lead, this phase was super useful. It gave me an opportunity to step back and see the big picture while planning the road ahead. It was evident that there are two steps in executing the redesign changes:
(1) Create and incorporate a new navigation paradigm without changing the current visual design.
(2) Create a new design that rolls out the new UX/UI rules, with new colors, fonts, and icons.
The second step requires design research, defining new design rules, and determining how to apply the rules to both platforms. In-depth thought and decisions are needed for: What is the Sing!’s major color; What are the right new fonts, What are the new icons and how do we test these design concepts. Scoping out the myriad of decisions needed to conclude each step in the new design helped me come up with a rough timeline for this future release.
Create new navigation design
As a first step, we started to explore options for the new navigation design, setting a basis for the future redesign. The complexity of the new navigation design is in itself worthy of a separate article. Since the redesign is the intended focus of this article, I won’t cover in-depth details on how we approached the new navigation design. Instead, I would like to share some of the strategic thinking that went into this redesign challenge.
1. Find the right navigation structure that suits your product purpose.
The impact of device size such as: mobile devices vs. laptop vs. desktop vs. iPad forces a critical early decision on the “form” to be used in the design process. Further complicating this decision is mobile device size variation. Mobile devices have various screen sizes that could be as small as 3.5 inches or as big as 13 inches. Creating a simple yet scalable navigation paradigm to fit the smallest screen first is the key to success. When we explored the navigation designs with existing apps in 2014, we found that there were three basic types. (1) iOS standard (main screen navigation), (2) Android standard (hamburger navigation ) and (3) Customized, based on the developer’s needs. We realized that the decision on the navigation paradigm should not be made based on the platform but rather it should be the paradigm that best aligns with the product’s nature or use. For example, if the product is focused on a creation experience, like Instagram and Sing!, then main screen navigation is a great option; if the product is focused on a browsing experience, like email or news product, than hamburger navigation is more suitable for that experience; and finally if the product has one key purpose for usage, like Uber and Snapchat, it is applicable to create a customized navigation design to meet that singular product’s needs.
2. Organize the features around themes
Sing! connects people through music, which means social interaction and creating music are two core themes for organizing the features of the product. The first step we took in the navigation redesign was to place every feature offered in either the “social interaction” or “creating music” bucket. We found some features did not fit in either bucket and some features could fit in both. For features, like registration, that didn’t fit in either bucket, we came up with a third bucket marked “other”. For features that could fit in either bucket, we put them in both buckets for future consideration. The next step is ranking the features in each bucket based on data, product goals, and user research. Ultimately we needed to determine what our users were interested in, what features we would wanted our users to engage with, and how we could best lead them there. Through this ranking exercise, we had a pretty good idea on how we should arrange these features based on their bucket and its relative importance.
3. Set a clear information hierarchy for navigation
In traditional web design there are three levels of navigation systems: global navigation, local navigation, and contextual navigation. The purpose of these three navigations is to provide context and flexibility to users. They help users know where they are and where they can go. In our version of this step, we selected the top 5 ranked features from the previous exercise and included them as the global navigation paradigm. The remaining features became part of the local navigation paradigm. Finally, since mobile screens won’t allow users to jump between screen as easy as a desktop or laptop screen, it is important to develop a clear rule on how to stack screens and when to clear the stacked screens to avoid user confusion.
After rounds of design iterations, the new Android Sing! navigation design was released in Q4 2014. From both quantitative and qualitative research, we found the new navigation design drastically improved the discoverability of both the “creating music” and “social interaction” features. As a result our user retention was increased in a dramatic, and statistically significant way.
source: shutterstock
Kick off the redesign
Redesign strategy
When approaching a mobile app redesign, one core question is which platform (iOS and Android) design guideline should the design team follow and apply. Some companies started with creating the iOS UI style first, and then carried the iOS design style to its Android product. This is a very efficient approach to design and build features for a second platform. Some companies took different design languages for each of the platforms. The purpose of this method is to meet the standard of flat design (iOS) and material design (Android) on each platform. There are pros and cons to each approach. The first method saves a lot of time for the development team while ignoring the fact that Android users and iOS users might use and interact with apps differently. The second approach is more user and platform friendly, but may generate inconsistency on the design, confusing users if they change platforms, and also slow down the development process. For the redesign for Sing!, we decided to develop our own style guideline integrating flat design with material design, while maintaining the minor but unique differences for each platform. In this case, the redesign was aligned with Sing!’s original character, which has successfully attracted millions of users. Based on quantitative data and qualitative research, iOS and Android users do have differences in product usage. Maintaining the platform difference in our style guide respects our users’ behavior and allowed us to maintain our high levels of user retention.
source: shutterstock
The Importance of color selection
There are so many ways a designer can choose a color for both a Brand and a product. Through the redesign of Sing!, we found the following three steps worked well for us.
Step 1 — Finding a primary color to represent your brand identity
We started the process of picking a new color by understanding who our current user community is and who our future target audience is. Sing! is a fun, whimsical and delightful app. The community is welcoming, encouraging and passionate about creating music. It attracts people who believe in self-expression, optimism and enjoy creating music individually and in collaboration. As one of the apps of Smule, the personality of Sing! is inclusive, genuine, optimistic, refreshing and captivating. With these character traits in mind, we explored mood boards that we felt could represent those feelings and selected a primary color to represent Sing! This was not the end of the process. Color choice is very subjective. Knowing this range of primary colors was going to be a permanent presence on screen after screen throughout we wanted to have a high level of confidence that our users would find it appealing and that it “worked” properly on each screen before it was finalized. We conducted qualitative testing on new users and existing power users to understand how they reacted to the new color when applied to the existing design. This feedback helped us get a better idea what they like and don’t like and why. It gave us a clear direction for the next round of design iterations.
Step 2 — Creating a color palette from the primary color
The second step is to build a color palette from the primary color. The goal is to create a set of colors from primary color scaled from light to dark. There are a couple of ways to generate this color palette. Our approach was to create two sets of color blends: from the primary color to white and from the primary color to black. For Sing!, we decided to set 8 steps in between those two blends. The end result was a color palette consisting of 19 colors, including the primary. This gave us a broad enough range of colors for the full range of anticipated uses, i.e.: accent color, text color, icon color, divider colors and background color. The accent color should work in harmony with the primary color while still able to stand out on its own. Locking down the primary and accent color set the foundation for picking text color. Text color plays a critical role in the whole UI design. It affects content readability and how users might respond to calls to actions. For text color, we know we have to strike a balance of working in harmony with our primary color while providing enough of a contrast to make it stand out. The easiest and safest solution is choosing black and white, the two most dominant colors for text. However knowing Sing! is welcome and fun, and our users are creative and passionate, we felt using black and white might be a little dull. So, we utilized our primary color palette to locate the text color. Through several rounds of exploring and testing, we chose three colors to rotate between titles, body copy, the CTA (call to action) and the contextual text.
Once our text colors were set, we started picking out the divider color, navigation color and background color from the same color palette. Since text colors need to stand out in all different contexts, to ensure readability, we know we need contrast. And reversing a dark text color text out of a background makes for poor readability. So, the divider color, navigation color, and background color, all need to be lighter than the text color.
Step 3 — The Rules: Applying the color choices to screens
What I mean by setting the color usage rule is we need to set the primary color applications, accent color applications, text color applications and other design elements color applications. Finalizing your color palette doesn’t mean the job is done. Rules need to be developed as to how these colors can be applied to each UI element in the app while achieving a clear information hierarchy. Whether the colors picked from step one and two are working or not really depends on two parts: how we define the application standards (the rules) and how they work holistically on every screen. We had a rough idea from Steps 1 and 2 what these rule might encompass. Now is the time to add detail and finalize the rules. This also means understanding how color can present product information when aligned with product intention and creating a hierarchy of application. Once we set the color norm, it is quite important to test it and get real, measurable, feedback from users. Real world testing, i.e. applying the color changes to the existing design enabled us to read whether the color rule is working as intended or not. The results also let us know whether we needed to adjust and tweak the rules and under what usage. To speed up the testing process, we didn’t test color rules on every single screen. Instead, we picked the screens that drove the most traffic or have most complex UX and UI patterns to run the color test. Two things needed to be tested at this stage. Making the design work on the computer doesn’t mean it works well on mobile devices, this is especially true for Android phones. We also want to test how the color of CTA and the text readability displayed on the mobile devices. The second test we did was a color blindness test. We wanted to make sure the new design’s grey scale could be read by everyone, and that our color choices weren’t negatively impacted by any user color blindness.
Setting up a style guideline and application rules
One of the purposes and consequences of the redesign is to establish a scalable design system that show how color, fonts, and icons are applied based on the information hierarchy and context of the feature. This system then becomes the bible for future design efforts making them more efficient and less cumbersome. Defining the application rules is a critical step in this whole process. If we ask ourselves what a successful design standard looks like, the rules should keep us in check like a container doesn’t allow water to spill, if used properly. The rules should be general enough to embrace all the different UI cases, but also constricting enough to guide designers to make right decisions. They should provide a consistent, modularized framework yet still yield the space for creativity to shine. They act like a lego set. You can build most anything but within the guidelines of interconnecting and interdependent blocks. You can still build new toys with your legos and add rules to your guideline. As long as you continue to use interconnecting blocks of plastic and your written set of guidelines you can take both to most anywhere. Both Apple’s human interaction guidelines and Google’s material design guidelines are great design frameworks that serve this purpose. Instead of applying different rules to the different platforms, as we discussed in the parts above, we decided to develop our own style guideline that integrates flat design and material design.
This approach gave us a lot of room to embrace our brand identity into the redesign, and develop the UX & UI patterns that suit both platform while respecting the distinct user behaviors of each platform. One example: iOS and Android material design have different languages in the use of icon graphics. In Sing!, half of our daily active users come from international countries. This means we relied on icon graphics to communicate product functions to reduce possible text UI bugs. As a small team, creating and producing one icon for only one platform consumed a lot of time and energy from the visual designer. Having one uniform iconographic helped us to stay focused on the case discussed above while reducing our design and development time.
source: shutterstock
Design modules and build screens
Create new screens
This is the moment of truth. This is the step the designers have been waiting for, a lot of exciting and creative things come through from this step. The visual changes, the look and feel with clear hierarchy really makes the whole product look exciting and new. We used Flinto to create a prototype and shared it within our product and design team, as well as our power users, and collected feedback from all of them. Sharing the Flinto prototype enabled everyone to use and interact with the new design on their device. It helps real users to see and interact with the new design, developing a set of questions and feedback to be addressed before development starts.
Collaborate with engineers to build design
One of the redesign goals was to provide a scalable solution for designers and front end engineers to collaboratively build features. To achieve this goal, we created standardized UI modules, specs and worked with engineers to define the model names and their applications together. We also partnered with engineers to build the UX/UI language library from the UI toolkit in code. This shared initiative not only saved a great amount of time for the designers and engineers but also created a solid foundation for future collaborations.
QA the design
No matter how good your engineers are, there is the chance that they didn’t execute something as the designers had planned. The secret to building a complete and holistic design from a sketch file is to interject a clearly defined and agreed to Design QA into the final build process. The most efficient way to communicate design intent was to actually sit with engineers and act as a pair programmer. The simulator with Xcode can help the designer see single screens with real data on different devices, like iPhone 5, iPhone 6, iPhone 7 and iPad at same time. Meanwhile, the engineers can also see the screens in different languages at once. Providing the right settings from different languages will also further reduce the risk of UI bugs that are caused by localization.
At this stage, the new design is ready to ship. And the the whole the team is ready to hear from our users on how much they like the new, fresh and delightful experience of our rebuild and redesign.
But wait … This doesn’t mean we are done. In the next part, I will share some follow-up steps, post-release understandings and additional updates of this redesign initiative.
source: shutterstock