<p>Published on <a href="https://blog.prototypr.io/how-to-approach-redesigning-established-products-bd08127e4ee7?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Akar Sumset </p>
<p>I recently wrote about designing for results instead of users or businesses. <a href="https://uxplanet.org/design-for-results-not-for-users-or-businesses-6490c4324b04">The article</a> is an attempt to remind us that users and businesses tell us a lot about what they want and inevitably tell how things should work, too. Although, there is value to it, we should be focused on the results they want to achieve more than how they want to achieve that. Because users and businesses do not know what product they want. They only know what results they want. The product, the agent that’s delivering them results, is ours to build. It is our job to satisfy both users and businesses in a coherent way. The article then goes on to describe a process to help with applying this approach. As a response to the article, <a href="https://medium.com/u/306b643d28a6">Jim Ground</a> asked an excellent question on how to apply the process to redesigning well established products.</p>
<p>So, the following is my answer to his question. I wanted to share it as a separate article because as much as I love writing on Medium, I find <a href="https://medium.com/u/504c7870fdb6">Medium</a>’s response experience a bit frustrating to use. <em>(Some of the reasons are: It is to detached from the article itself. I need to click and wait for the page to load too many times if there are multiple answers. There are suggested articles between a response and a following response on Android app which makes it difficult to follow a conversation.)</em></p>
<p>Here it is.</p>
<h3>Original Article</h3>
<h4><a href="https://uxplanet.org/design-for-results-not-for-users-or-businesses-6490c4324b04">Design for Results not for Users or Businesses</a></h4>
<p><em>Because neither know what product they want. They only know what results they want.</em></p>
<h3>Question</h3>
<blockquote><p>Neat perspective. I’m curious how you’d apply this thought process in designing updates to an existing product, where a user is more likely to have pre-existing preferences or commitments to a specific way of doing things. I see Design as an incredibly important discipline to make better outcomes that are focused on user experience rather than technology for its own sake, but the technology does matter — especially if you have a well established set of customers with likes and dislikes specific to the products they already use. — Jim Ground</p></blockquote>
<h3>Answer</h3>
<p>That is always a tough process to manage. I had to do dramatic whole product redesigns a couple of times myself and those taught me good lessons every time.</p>
<p>Before anything else, remembering that most of the difficulties in this process stem from our resistance to change not because of the the change itself, is very helpful. First, this reminds us the fact that people will resist to change no matter what and that’s normal. Second, it reminds us that a self aware persistence (knowing we might have made mistakes and listening to feedback that address those) will eventually get us through.</p>
<p>And some more tactical tips.</p>
<h4><strong>Being loyal to our core principles and brand promise</strong></h4>
<p>Having <a href="http://bit.ly/1stprncpls">principles</a> has countless benefits one of them being the guidance they provide during redesigns. Knowing the brand promise has a similar benefit. Being loyal to these will help us make more consistent and eventually acceptable changes.</p>
<h4><a href="https://www.nirandfar.com/2015/06/california-role-rule.html"><strong>People don’t want something truly new, they want the familiar done differently</strong></a></h4>
<p>I’ll directly quote from the post on <a href="https://medium.com/u/295258f6269d">Nir Eyal</a>’s blog. This principle is very helpful when design teams are very eager to “put their mark” on the work and put user experience at risk during redesign process.</p>
<blockquote><p>The California Roll introduced Americans to sushi by using familiar ingredients arranged in a new way.</p></blockquote>
<blockquote><p>The California Roll Rule: People don’t want something truly new, they want the familiar done differently.</p></blockquote>
<blockquote><p>Things that are truly new need to use familiar mental models to gain user adoptions (i.e., Apple’s use of skeuomorphs.)</p></blockquote>
<blockquote><p>Unfamiliar interfaces are more difficult to use and impede adoption.</p></blockquote>
<blockquote><p>If your new product or service is not engaging users, ask “What’s my California Roll?”</p></blockquote>
<h4><strong>Knowing which feedback to listen to</strong></h4>
<p>All user feedback is valuable yet this doesn’t mean all should be addressed.</p>
<p>Using prioritization techniques, especially <a href="https://foldingburritos.com/kano-model/">Kano Model</a>, and trying to understand if the complaints have a real use case or just stem from our innate resistance to change help us understand which feedback to listen to. I believe the recent Instagram redesign is a successful example of a drastic redesign. Yes, a lot of criticism and even rage was received but then all has gone away and everyone keep using it. A very real example is my girlfriend who recently saw an old screenshot of Instagram and told me “look how ugly it is” who in the first place was not a fan of the new design 🙂</p>
<h4><strong>Plan ahead and release bite sized changes</strong></h4>
<p>Amazon, Facebook, Gmail (Inbox is a separate product) change everyday, bit by bit. Even though they introduce totally new products they do it in a consistent way. There might be lots to change but if you have the time to release them bit by bit, then it’ll be much more easier to manage the change.</p>
<h4><strong>Long beta period and then opt in to new design</strong></h4>
<p>One of the tactics to achieve a smoother transition to new design is having a rather long beta period (if you have time of course) and then opening a opt in version of new design. Also, if you position the beta as a closed one where only privileged users have the chance to participate then it’ll be much more likely that you’ll collect quality feedback.</p>
<p>All that said, there is another approach that only “different” (not looking for world domination or monopoly, not looking for outrageous profits etc.) companies like Basecamp handle. They published an <a href="https://m.signalvnoise.com/how-to-launch-software-changes-without-pissing-people-off-cf79dce64630">article</a> on this but the incredible thing they do is this: they keep the older versions running as long as there are users. This is not applicable to all products but more often than not the reason is not that it is impossible but we just don’t want to do it.</p>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=bd08127e4ee7" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/how-to-approach-redesigning-established-products-bd08127e4ee7">How to Approach Redesigning Established Products</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


How to Approach Redesigning Established Products

Top Stories