In every tech startup’s lifecycle, there comes a point where the product ends up becoming so bloated with features and hacks built on top of each other that it no longer resembles the simple idea it started out as. This is when they embark on a journey to redo it all, to redesign it from scratch while improving upon the important features that users liked and were working well.
But what does this process look like from within the company? When and how does it become an important company-wide initiative? What does the design team need to do in order to push for it and how do they ensure that it actually gets done on a tight timeline while also striving to make it better than it previously was? This is exactly what we did in the first half of this year, and this post will detail our process from start to finish.
1. Identifying existing problems
mCent Browser, our primary product, is an Android-only web browser targeted at emerging markets that allows users to offset rising data costs by getting free mobile recharge right through the app (in exchange for seeing the occasional ad). We’ve been focused on India as our launch market and have been shipping and testing features for user acquisition and retention. Our process is very data-driven and many of the product decisions are a direct result of what experiment variants succeeded and failed in market testing.
We also do a lot of qualitative user testing and research in-market. It led to one of our biggest UX overhauls for which I created, prototyped, tested, and validated the UI. That blog post talks about the company and the product in far more detail, if you’re interested in catching up on the story so far.
The Design Problem: Feature Bloat
We had been making minor visual and UX improvements to the product for the second half of last year. Much of this was driven by company and team objectives for each quarter. We had metrics we needed to hit for user growth, D7 + D30 user retention, and median time-in-app, so we kept shoehorning more and more things into the clean and simple “points card” that we had.
As with most digital products, the real estate on the homescreen is extremely valuable. So every time we needed to draw the user’s attention to something, we added a design element (a callout or a link) on the points card. This was not elegant at all, and the final call to go down this route came down to maximizing the number of potential eyeballs we could get on a CTA.
Case in point: our rewards system. We built out a system of quests and tasks for users to do in our app as an engagement mechanism to improve our retention metrics. Our homescreen was the only piece of the product that we could guarantee all users would see at least once, so we added a scrolling rewards carousel on there where users could view their redeemable rewards and claim their points right from there. Again, this ended up in the points card and further added to the bloat in there. That card was clearly not designed to handle so many features and it quickly got overloaded.
I felt a sense of personal responsibility for this, because I was the one who designed this feature. At the time, it was exactly what the product needed: a place to quickly glance at and redeem available rewards while staying informed of your progress on the other rewards. And it actually worked. We saw measurable bumps in retention as well as time-in-app. We hit our goals for the quarter and everyone rejoiced, but our problems were only beginning.
The Product Problem: Mixed Signals
Although the rewards system was doing well, it wasn’t sustainable. Users were figuring out hacks and ways to accelerate their points earning (a quick YouTube search will reveal a lot), and our retention numbers weren’t holding in the steady state. Data was showing that users weren’t using the product as a web browser, but instead as a rewards app.
Qualitative in-market testing validated this as well. We traveled to India twice to test new features, and users seemed to be completely missing the fact that this was a web browser. When we asked users to search for something or visit their favorite website, they couldn’t find the search bar. This was also backed up with data, which said that the total number of searches triggered by users was down by a significant margin. Search advertising was one of the ways we monetized, so this was a pressing issue that needed a solution fast.
All this user confusion spurred a large internal debate within the Product and Design teams. What was our primary use case? Is it a web browser or a rewards app or a mobile recharge app? We all intuitively knew that it was a hybrid of all three, but we were struggling to figure out what parts of it to highlight and which ones to bury deeper in the app. We were having a bit of an identity crisis as a product and needed to figure ourselves out.
Here’s a fun little design principle that may not be obvious to non-designers: the level of prominence that you give a feature directly correlates to how important you believe that feature is for the user. If you scream rewards on your homescreen, that’s what users will think your product is all about. On the contrary, if you make it all about searching and browsing, that’s what users will think the product is about. So we needed to reduce the loudness of the rewards system by diminishing its importance in terms of real estate taken up on the homescreen. The design team used this as leverage in the discussions to sell the fact that this was a bigger product problem that required a larger solution, not just minor design tweaks here and there.
It was crucial for us to all come together as a product team and align on the fact that making a solid web browsing experience first would naturally lead to user comprehension of the product as a web browser, especially in the crowded space of emerging markets where our competitors had such a big leg up. Once users understood what they were using, only then do we start showing rewards and recharge. We knew our value proposition was a strong one, but we needed to properly project it through the product itself.
2. Defining our goals
We were starting to get all the pieces in place to undertake a major overhaul of the entire product. Both the qualitative and quantitative data was pointing to a failure in user comprehension of the core product itself. The timing was right and we started to get some resources allocated for this endeavor. But first, we needed to get the rest of the organization on board with why we were even doing this instead of focusing on the other giant backlog of features we could be building to improve our metrics.
Typically, companies undertake a redesign because their product pivoted to something different, or their market has undergone a big change, or the company needs to rebrand its identity. It could even be because the company needs to align its business priorities with the product better. Our case was slightly different where we had to re-educate users about what the product even was, so this required us to make sure that everyone knew what our reasons were for doing it and how it differed from a traditional redesign.
We did a company-wide presentation on what we were about to do and why we were doing it. Historically, there was not a strong design culture at the organization, so we had to do a fair amount of education around what a product redesign involves and more importantly, to set expectations correctly:
- We had to make it clear that this would be more than just a visual redesign. We would be reworking some core systems of the app in order to increase user comprehension of the product.
- We let everyone know that this process needed to involve everyone, not just the design team. Everyone at the company would need to pitch in with their input on what they think works and what doesn’t work.
- We would make a lot of users mad. Tech product redesigns aren’t exactly greeted with fanfare, and users often have to break old habits and re-learn how to use the app. We told everyone to initially expect a large negative reaction, which would eventually stabilize over time.
And then we needed some objectives. Without a goalpost to head towards, it’s easy to focus on the wrong things and waste valuable time worrying about things that aren’t as important as we think they are. What were we even trying to accomplish? What problems should we focus our energy on solving? We knew this would be important to answer, so the Product & Design teams came up with and agreed on these objectives:
- Get people to use the browser as a browser: Could easily be measured by trend lines on our metrics and qualitative user feedback.
- Create a strong brand experience: We needed to strengthen the brand identity within the product to aid with the first objective.
- Guide users towards natural behavior: Make simple actions like searching and visiting websites extremely intuitive and obvious.
Finally, we needed a measure of success. How would we know if it even worked after we ship it? We needed actual data to measure once the redesign was out in a steady state. At this time, we didn’t know what the scope of the project would be, so we couldn’t put actual numbers down, but we wanted to keep an eye out for an uplift in some key engagement metrics:
- Increase in D7 retention
- Median time-in-app up
- Total number of searches and page loads up
A lot of this might sound like boring prep work, but outlining our goals & objectives, explaining the process to the larger company, and coming up with our definition for success were all incredibly crucial in gaining the support of everyone on the team. In a lean startup that has traditionally made decisions based on numbers and data, trusting the design team to redo the whole app and then dedicating an entire army of engineers to actually build the thing out was a big leap of faith.
3. The redesign process
And so with excitement building around the product redesign and with the entire organization getting on board, it was time to execute. There was still a lot of nervousness and anxiety in actually beginning the work, simply due to the amount of uncertainty involved in the process. The engineers didn’t know what crazy propositions the design team might have, the data scientists were worried about the metrics getting all screwed up, and the display advertising team was concerned about messing with the placement and positioning of the existing ad units in the app. Needless to say, there was a lot of doubt.
We knew this was going to be an overarching feeling across the company, so we tried to be as approachable and open about the process as possible. We had a pin-up board that we updated every day with our in-flight designs. Many co-workers would wander up to and take a look at the board every day to see how far along we were, and would often chat with us on why we made certain decisions. All of this lent itself to a collaborative and open approach.
Before even starting any work, we met up as a design team to come up with some core design tenets to work with and use as a north star. This would anchor us in our thinking from here on out in what often ends up being a wild and messy ideation process. It helps re-orient us when we start to flounder around in the land of typography and colors and start to lose track of the goal that we were all collectively working towards together. These goals were:
- Shoot for clarity: Always make things as clear and simple as possible. Focus on decreasing cognitive load and eliminate the fluff.
- Be useful: Never leave the user confused about what’s happening. Provide helpful directions in end states and direct users to useful actions.
- Be transparent: Don’t intentionally mislead users into taking potentially harmful actions. Explain the systems in context and be descriptive.
Brainstorming & Planning
In the spirit of our open and collaborative design process, we held team-wide brainstorm sessions to get our minds going with the ideation process of the redesign. This included engineers, data scientists, and product managers. The purpose was to get a sense of what ideas people had as well as give ourselves some early feature sketches to tinker with and iterate upon.
It was organized as a mini design-sprint within each team where every person drew something in the crazy eights format and shared their ideas with the larger team. This greatly helped kickstart our ideation process within the design team and gave us a good starting point to build off of.
Meanwhile within the design team, we were also starting to build out a set of shared common ideologies around how some of the major changes would work. We were laying out things like how many tabs the user’s account would have, how frequently we wanted notifications and modals to pop up, and what the flows for completing tasks could potentially look like.
One thing we quickly realized as we were doing this was that the user’s account section would be massive. We were trying to add and change a lot of things in there, so one of the first challenges I undertook was to figure out was how a user even navigates to their account from the home screen.
Taking all of the ideas, I put together a concept for going from the homescreen to the account: an expanding/collapsing panel from the top with three different states depending on the user intent in that moment. I threw it all together in a prototype to see what the timing and transitions would feel like. Overall, it was snappy and quick, providing information at a glance.
After discussing it with the design team, we quickly killed off the idea before moving on further. While interesting in theory, we were heavily constrained by having to use native Android behavior because our web browser was built off of a Chromium base. This meant that non-native animations or UI behaviors were too memory intensive and we wouldn’t be able to guarantee the precise timing of the interactions we wanted.
Despite this, it was a great experiment to try out and quickly eliminate from the potential solution space. It gave us a very good sense of the information hierarchy, visual states, and the required salience for all the different UI elements on the homescreen. Those wireframes took less than twenty minutes to put together at this level of low-fidelity abstraction. I personally gained a better understanding of how to only display relevant information to the user when necessary and hide it otherwise, a tricky game of balancing feature exposure with user intent.
Visual Mockups and Navigation
Once we started getting a better sense of what information would live on which screens, we started playing with the puzzle pieces. We used our flowcharts and put together the overall app navigation. We had not established a visual style yet, but we still wanted our mockups to be at somewhat of a medium fidelity level so that we could get people’s reactions to them immediately (as we put them up on the board) and see what was already working and what needed further iteration.
We found ourselves struggling a bit to innovate and create something radical while working within the technical constraints and the short timeline, but we kept hacking away at it. We re-organized all our existing features within the massive account section. Different designers were working on different parts of the experience, so we frequently built off of each others’ ideas that we thought worked well and also started combining our differing layouts and visuals that you end up with when multiple designers are working on various versions of the same thing. We were slowly starting to get a better sense of what needed to live in the user’s account and how they would be laid out.
We also had a wealth of user research data to pull from and improve the existing experience. We heavily referenced not just competitor browsers in our markets, but also other rewards apps and recharge apps from mobile operators in India. We tried to see if we could use the best bits and pieces of them and bring it all together into a cohesive account section.
We knew we needed to make the recharge screens more visually appealing, but also wanted it to be informative. Going off of our guidelines of clarity and transparency, we agreed on adding a “Details” view where the user could see in-depth details about each recharge option, because we simply couldn’t fit all the information on the Recharge Options screen. This gave us a lot of flexibility to keep playing with how the options themselves were laid out to communicate the important stuff immediately. We had not nailed the look or style of anything yet, but we were making important decisions and progress.
It was finally starting to come together. With some more discussion and iteration within the design team, we decided to kill the dashboard idea and focus on just three tabs within the account section: one for recharge, one where the user could see ways to earn points, and one for explaining how the whole system worked. We also kept iterating further on colors and layouts.
The recharge screens were still the most difficult part of this whole process. We had a lot of technical complications around what we could actually display here due to the way we were getting the data on the back end. There was a possibility that some of the information would be inaccurate, and we had to do some double-checking to ensure that we were displaying the right thing to the user. We continued to refine the visual hierarchy of the elements on the screen based on research finds and user testing.
This was also a good time to get some ideas going for the other required screens to see how they would work with the account section, as well as to start solidifying a styleguide in order to begin a high-fidelity visual pass on the screens that we were starting to feel good about.
Establishing Visual Branding + Styleguide
We got to a point where we had decided on what screens we needed for the account section. The next big thing we needed to work on was the main homescreen, which was the perfect opportunity to finalize visual styles for the redesign, as the homescreen was the most important part of the app.
The first thing we worked on was making the search bar more visually prominent. We made it stand out from the rest of the UI elements on the screen by modifying the strongest perceptual affordance, its shape. On a screen where we mostly had rectangles, a heavily rounded search bar would contrast really well. We gave it a blocked out background to really draw the user’s eye to the top section of the screen. We also took this chance to remove the confusing clutter of shapes on the homescreen and simplify the quick links icons down to plain circles, visually linking the shape to that feature.
When it came to branding, one of our big research findings was that users had a mental association to our previous product (simply called mCent) which didn’t exist anymore. That app had vivid red visuals and users naturally expected a product called mCent Browser to share a similar visual style. So we went with a high contrast crimson. We also wanted it to feel more modern as an evolution of the mCent brand, so we overlaid a polygonal vector pattern on top of the red to see what it would feel like.
Initial reactions around the company were mixed. Some felt the red was overpowering while others didn’t mind it too much. But overall, everyone agreed that the color blocking the search bar with a background gave the homescreen an entirely different feel. Adding our logo above the search bar took it one step further and fully completed the brand reinforcement.
Now the app felt like a browser. There were no strange point numbers and rewards sandwiched in the midst of the browsing actions on the homescreen. It was clear from the get go what this app was. Users would access their account by tapping the not-so-loud points amount on the top-right corner.
As for the red polygonal pattern, it was one of those things that ended up staying in the redesign mockups for so long that we didn’t have any time to further iterate on it before running out of time, so it got to stay. Any other major shift in visuals just felt weird, so we just rolled with it. In hindsight, it would’ve made more sense to iterate on the branding and styles in parallel with the UX and navigation improvements we were working on.
Another big decision we made was to blend the news feed on the homescreen. The old experience had separate cards for each category the user had selected, but we decided it would work best with user expectations if we mixed in the category types and made the entire feed infinitely scrollable. After some visual iteration on the typography and layout, we decided to use condensed fonts and a clean look for the styling here to fit long article headlines without having to awkwardly truncate them off. This led to us deciding on fonts and type styles to use throughout the rest of the screens.
Iterative decision making
It’s important to mention here what our iteration cycle was actually like. We had designers working on different parts of the experience and we had to use shared styles and components that we were starting to establish in tandem, so we needed to be in sync at all times throughout the process.
Our Trello board had multiple columns for the state of things that we constantly kept updating throughout the day. We could share the progress of certain features and comment on each others’ work. We also met twice every day, once in the morning and once in the afternoon, to review all the in-flight work and give feedback on the “Ready for Review” designs.
We would discuss whether the UX feels right or if the visuals don’t feel in tone with our guidelines. If we agreed on it, it would go into the “Done” column, where engineers would start estimating the work required to build it. If we felt it wasn’t quite there, it would go back to “In Design” with the feedback for another iteration cycle. There were many times where we were forced to call something “Done” due to time constraints despite us not being happy with it.
Changing core mechanisms
As we were defining the visual styles even further, we realized we had to make some important choices about changing some key mechanics of how the app worked. We had an “Add points to my account” button on the points card, which when tapped would transfer the user’s accrued points into their account and convert it to their local currency.
Qualitative in-market research told us that this conversion mechanism was not clear and was a primary cause for early user churn. So we decided to remove this step entirely and have the everything function in points. We had already been doing this in the redesign so far, using points to represent the user’s account balance as well as cost of the recharge packs.
The recharge options would be priced in points and there would be no conversion of currency. It sounds like an obvious solution, but this was a big step forward in reworking a core functionality of how our product worked and required the engineers to undertake some hefty back-end work to get it going.
Having everything be in points meant that our recharge options layout would have to do a lot to properly represent the points cost of a pack. It couldn’t just be a simple number tacked on to it, and we needed to be as clear as possible about the fact that these were real things they were purchasing with virtual points. Our latest iteration on this had a progress bar that updated as the user kept accruing points, and then changed to a button upon completion.
And now that everything was in points, we knew we’d have to make the points feel more real. Taking heavy inspiration from other mobile games that reward users with virtual “loot”, we came up with some gold coin iconography that could be used to represent points in a more realistic manner. The plan was to have different tiers of these coins represent different points reward amounts and strategically use these throughout the new experience.
Things were starting to come together. We started applying our styles to shared UI elements across the app and began taking note of areas where we would need to introduce new type styles or colors. We added and fine-tuned these design elements as necessary and began polishing up the screens.
We simplified as much as possible when it came to iconography and styling. Our only real brand element was the polygonal background pattern. Everything else became clean lines and simple shapes. We wanted all the visual elements to be quickly discernible and immediately distinguishable from each other, in line with our goal of clarity.
The final styles were applied to the account section, with some special treatment given to the interaction of scrolling when the header collapses and the navigation between the tabs. In terms of the information hierarchy, we designed the layout and flow of the screens here based on our research data, which was invaluable in providing us with crucial knowledge, like the fact that the validity of a recharge option was something that users cared about a lot and thus needed to have prominence on the Recharge Options screen as well as on the Recharge Details view.
In our old login flow, we had very minimal or nonexistent branding on the screens, and there was no clear indication about what app the user was in. The UX was a little clunky, the copy was unclear, options were very limited, and it wasn’t visually engaging enough to provide any sort of brand reinforcement to the user about what they were about to experience.
With the redesign, we wanted all interactions that had to do with registering, logging in and account/SIM management to feel like they were a big part of the experience, so we used the full-bleed polygonal pattern background in those screens. Compared to our old login flow, the difference was night and day. We added the app logo as well and snuck in some small enhancements such as representing your country code with a flag icon. We couldn’t change the app icon due to some marketing and technical constraints, so we just tried to keep what we had and made it work with the new designs.
It was crucial to strongly reinforce our brand identity in actions like these, while downplaying it elsewhere by restricting it to just the header. We intentionally went a little overboard with the usage of red when it came to interacting with specific portions of the app and toned it back down in other parts depending on how strongly we wanted to push the brand value across.
We also finished up the “Earn More” tab, the screen where all the rewards would live along with referrals, the streak mechanics, and many more quest systems. We wanted it to have a robust and flexible layout while also allowing for the right information hierarchy. A lot of the content on this screen was merged together and simplified in order to fit elegantly in a condensed list view. We knew this had to scale as we added more rewards in the future, so striving for a clean replicable look was key.
We were quickly getting all the major flows and all their edge cases done. This was a good time to build Sketch libraries and create a styleguide, as the engineers would be working on it very soon and the first thing they would do is create a list of new type and color styles. We created and sync’d libraries for buttons, navigation, UI elements, dialogs, colors, and typography. We ended up going with Roboto as the final typeface, as we needed a high degree of font weights and a variety of condensed variants for numeric displays.
Speeding towards the finish line, we just needed to make sure to get some last few things done. We have a mascot who we didn’t exactly use very strategically in the old version of the app. We sort of just spammed him in dialogs and key moments where we needed to add some visual interest. We knew the redesign could be a great opportunity to leverage some more tactful usage guidelines for him that would be in tone with our goals.
We wanted to use him in specific moments as an element of delight. Since we couldn’t rely on transitions and animations due to our severely constrained technical limitations, our “delight” had to be entirely visual. We created varying emotional states for him at different levels of excitement and used his illustration in modals, bottom sheets, and callouts.
At the bottom of the Recharge and Earn More screens, we wanted users to be able to flow right into the next sensible course of action. So we added some buttons with the mascot peeking in as a friendly mentor. Every time the user saw him, we wanted there to be a related action they could take in the form of a navigational control. This tied right into our “Be useful” design tenet. We also used him in the introductory onboarding tooltips.
We also wanted to use him in key milestone moments for the user, so I created visuals for all the different states by combining the mascot with the coin illustrations. Although the reward visuals had their own tiers, the celebration moments had a different set of tiers in order to make certain point amounts feel more memorable based on our reward amounts.
The day the user completes a streak was one of these moments, which is an important touchpoint where a celebration is warranted, so we have a bottom sheet modal that pops up informing the user about their streak completion along with the mascot congratulating the user for a job well done. There’s quite a few versions of these, and the bottom sheets show the appropriate illustration depending on how many points the user receives for that reward.
Our big “Be transparent” goal achiever was the How It Works screen. Here was where we detailed exactly what actions earned the user points and what didn’t. According to our research findings, this seemed to be another big point of confusion for our users, so having an entire screen dedicated to explaining how points work and what actions provided the user with points was a big move forward in terms of transparency.
Tying into all three design goals was some other niceties like predictive loading states, assistive empty states, and informative failed states. We used the mascot again where appropriate here but tried to keep it simple and straightforward otherwise, using standard mobile design conventions. With this, we had finally wrapped up all the key screens and flows.
Handoff And Assist
There were still quite a few edge cases and error states to design for, but since the majority of the work was done, we began building the redesign. We worked with our Project Manager to get sprints planned and tickets made. A fair amount of descoping happened here as well, where we cut a few features to reduce engineering complexity and ship the thing in time.
It took the engineers three weeks to fully complete the redesign of key flows and screens, with an additional two weeks for debugging, QA testing, and identifying in-market bugs that were difficult to catch. During this time, we as the design team were assisting with asset delivery, answering functionality questions, and coming up with alternative solutions for UX problems in instances where things couldn’t be implemented the way we wanted them to be. It was just as hectic as the redesign itself, but after a chaotic and frenzied two months, we were finally done.
4. Getting it out there
Now it was time to ship it. Despite hitting a few unexpected bugs along the way, it was ready to go. For a product like ours, we had to meet many specifications such as ensuring it worked on many versions of Android down to a specific APK version, checking that the UI looked good on small devices with low resolution, and supported Android all the way back to KitKat.
We also happened to have a team in India at the time as we were getting ready to launch the app, but the build we were fiddling around with in the office was highly unstable and buggy. So instead, we resorted to testing with simple paper prototypes. This obviously isn’t ideal, but it gave us a lot of good feedback in terms of visual comprehension of the iconography and whether the interaction model of a swiping carousel and the complexity of the list views made sense, at least visually. We made minor tweaks to spacing, margins, and colors based on this and got it into the final build.
Around this time, we wanted to remind the team that we should be expecting a negative initial reaction. We had many features in-flight that were running on the old version, and translating it to the redesign wasn’t a quick and easy task. There was some more shuffling of priorities as we got close to release.
One final pitfall we hit was the rollout itself. Because of the way we setup and run experiments, there were some complications in guaranteeing that users put in the redesign version would actually get it. We wanted to start out at 5% exposure and gradually ramp up to 100% while keeping an eye out for crash reports and bugs. We ended up having to make some additional UI and features for existing users who may end up seeing the redesign and would be confused on seeing new visuals with no warning and an economy that now functioned entirely in points. This was very last-minute but we ended up pushing through it and got it out the door.
As expected, the metrics took a big hit. D7 retention went significantly down, and time-in-app started to drop. User reviews on the Google Play Store were a mixed bag, with some positive, some negative, and a lot of overall confusion. We didn’t exactly have any social marketing informing users about the redesign, which in hindsight should’ve been an easy problem to solve.
We kept shipping minor UX fixes and feature polishes as we were watching the metrics after shipping. Yet another complication was that we had at least four or five other active experiments running at the same time, all involving separate features in the old experience, so it was tricky to isolate and obtain exact numbers for the metrics that the redesign was solely responsible for. When we did hit a steady state, things started to stabilize a bit and we had some preliminary results, where we saw:
- Increase in D7 retention
- Median time-in-app up
- Total number of searches and page loads up
There it was! Our goals were somewhat arbitrary, but we managed to see what we needed to. It felt great to have validation of conceptual ideas that took so long to pitch and convince the rest of the team of. It felt good to solve core product issues through design, and it proved to the rest of the company how big of an impact design really has on the overall consumer experience.
And what about the product goals that we had in the beginning? How well did our design improvements directly play into those? Let’s take a look:
- Get people to use the browser as a browser: With our improvements to the perceptual affordances of the search bar, the quick links, and with the addition of the logo, qualitative research told us that users across the board were now comprehending that this was a web browser. Users understood what it was and were in turn using it like a web browser.
- Create a strong brand experience: By bringing back the brand association to the previous product and by being very intentional with its usage, we were doing a much better job of unifying the disparate components of the product under one cohesive brand.
- Guide users towards natural behavior: Now that users were comprehending what the product was, we were seeing more natural behavior like searching and visiting websites directly measurable through metrics. All the rewards stuff now felt secondary, as we initially intended.
A lot of the product goals were somewhat subjective but some could be quantitatively measured. We already knew we had succeeded in some of them without even waiting for data, and collectively agreed that we managed to hit bits and pieces of all of them. Again, it wasn’t perfect and could have been executed better, but we were proud of what we had accomplished.
As you might have noticed, it wasn’t smooth sailing. It was wild, chaotic, messy, and unpredictable. We got hit with unexpected problems but kept sailing onward. We were working on multiple things simultaneously and it caused a lot of shuffling around of tasks. But the team had faith in us and we kept chugging along, even amidst waves of uncertainty and ambiguity.
Our learnings can be summed up in three key points:
- Redesigns need to happen quickly. You can’t spend weeks tweaking the right UX and spending months building a specific interaction. Justifying a ROI on something so abstract is very tricky, even with defined metrics and objectives. Have faith in it and go full steam ahead, because that’s the only way it’ll usually get done in a lean startup environment.
- Share your progress! Put your designs up on the wall and chat with the folks who walk by and look at it. You’d be surprised how many team members from the company stopped to look at the designs as they were taking a break to stretch their legs, which ended with them having a cool idea that they pitched to us. Some of this even made it in. It kept everyone in the loop and made them feel involved in the process. More importantly, it helped explain the design process to them. Designers don’t go into a magic box and come out with something that miraculously works. It’s simply constant tweaking and iteration until it’s finally right.
- Set expectations correctly. Tell everyone ahead of time that it’s going to be painful and messy. It’s not going to be easy and it’s going to require some persistence to see it all the way to the end. Inform people that it’s going to cause a negative backlash when we ship, which will over time stabilize. It lets them plan accordingly. A part of me wishes that we worked with all the team members in tandem from the start instead of incorporating their ideas halfway through the design process, but if we did it this way, we would never have shipped it as fast as we did.
Our process was by no means perfect, and based on the many other product redesign blog posts that I’ve read, neither is any other process. In fact, I’m sure I’m making it sound more polished and fine-tuned than it really was in the way I’m describing it here. It was scrappy and disorganized throughout. It took a huge cultural change for the company to get on board with the idea of a redesign and embrace a design-led project.
As for the app, it has officially launched and you can download it yourself on any Android phone to try it out. As of June 2018, it’s only available in India. We’ve been shipping new features and updates since it shipped, so a few things might look different here and there.
Hopefully, this sheds some light on what a redesign process actually is like. Redesigns are always tricky in a product startup, and many factors have to align. The timing of business objectives and allocation of resources needs to be just right. You need to have a strong case to go forth with the endeavor and there needs to be an immediate need to solve pressing product problems, which in turn requires some product maturity as a prerequisite.
And once you get it rolling, you need to just keep going and ship it, because no matter what you come up with, it will almost inevitably be better than what you originally had. All the backlogged ideas will come pouring out from the organization and will energize the design team to create something new. You’ll gain a lot of momentum to keep the energy of the redesign going all the way until the finish line. In the long run, it’s one of those rare win-win scenarios for both the users and the company itself.