Or,
How to Not Screw Up Your Product
From time to time, manufacturers and developers make unilateral design decisions that affect the way a product functions.
This isn’t always a good thing.
Here are some examples of why major product design changes should always include feedback from the user community.
Table of Contents
Mistake: Microsoft Removed the Start Button from Windows 8
Quite a bit has already been said and written about this, but it remains as one of the most visible tech design faux pas of all time.
In an attempt to unify the desktop and tablet interface, Microsoft invented the “Metro” interface, a full-screen, tile-driven presentation for delivering applications and content, essentially eliminating the need for a desktop in the process.
The problem with this approach was that many existing Windows applications were not “Metro”-compatible, and still required a traditional desktop user interface in order to run properly.
In addition, “Metro” had some serious limitations – there was no easy way to see what applications are currently running, and it was difficult to find files and applications.
Worse, the existing Windows user base had to be completely re-trained on how to use Windows, because all of the familiar user interface elements were gone. Part of the value proposition for upgrading to previous versions of Windows was that there were no major design changes – if you know how to use Windows 95, you know how to use Windows 98, Windows NT 4, Windows ME, Windows 2000, Windows XP, Windows Vista, and Windows 7.
The user base wanted a start button.
This led to depressed desktop and laptop sales, and created a revenue opportunity for 3rd-party developers who quickly jumped on the “Start Button Replacement” bandwagon.
The economic impact to Microsoft was pretty severe, and even carried over to the hardware manufacturers, to the point that the media declared that “The PC is Dead”.
Microsoft rapidly developed and deployed a Windows 8 service pack that had a pseudo start button.
Meanwhile, Microsoft also went in to full-tilt development of Windows 10 (which miraculously includes a start button), and immediately attempted to retcon Windows 8 out of existence, just as it had done with Vista, its other recent failure.
Lesson to be Learned: Although the pundits hailed Windows 8 as “innovative”, the user base has the final vote, and they voted with their dollars. With the release of Windows 10, PC desktop and laptop sales are back up, and the Windows market share is improving.
Had Microsoft done more extensive pre-release focus studies, and deeply reached out to the user community before releasing Windows 8, they would have quickly realized that dropping the Start button was a mistake.
Near Miss: Early Microsoft XBox One Requires Internet
The year was 2013, and the 8th gen console wars were already being fought, pre-release, in the media.
Sony Playstation vs. Microsoft XBox was the title match of this decade, and both sides had some extremely fluid working designs of their final products leading up to their respective releases.
Both Sony and Microsoft contemplated “always connected” as a requirement, as well as introducing extra fees as a means to combat the used video game market.
Microsoft, early on, made the unilateral decision to require internet access. When confronted by the public with legitimate scenarios, such as rural access, and members of the armed services serving overseas, Microsoft’s condescending response was that these people should stay with the previous-gen XBox 360 console instead.
Sony quickly identified this as a weakness and capitalized on the opportunity, with it’s now infamous “how to share a game on Playstation 4” video. This passive-aggressive jab at Microsoft caused an abrupt turn-around.
When the “XBone” (Xbox One) was finally released, there was a day-1, large, mandatory update to the system software, and several early access users have commented that even the final beta included the “mandatory internet access” version of the system software.
In this case, Microsoft openly disregarded and discounted feedback from its user base, until confronted by its competitor.
Lesson to be Learned: Condescension is not necessarily the best approach to community feedback. People want to share games for free. People want a used games market. People don’t want (or can’t get) always-on internet access.
Public betas quickly uncovered the problem. However, a lack of willingness to change direction in spite of that feedback almost resulted in massive backlash.
Near Miss: Microsoft Internet Explorer 8 and Compatibility View
In 2009, Microsoft announced it’s latest browser at the time, Internet Explorer 8. It also announced that IE 8 would no longer support the “non-standard” formatting that had been supported by its predecessors.
On the surface, this might not seem like a huge problem, but let’s look at the history in a little more detail…
Although the internet has been around since the 1970’s, it was primarily used for chat and file transfer, until the standardization of HTTP and HTML, and that’s when the first web browsers began to appear.
Netscape ruled the world for a few years, during which, there was a veritable explosion of content, all written to render properly when viewed with the Netscape browser.
Eventually, Microsoft released its own browser, Internet Explorer, which had its own rendering engine. The first couple of versions of IE were terrible, and adoption was low. However, with the release of IE 3.0, Microsoft finally had a winner – a decent browser with a similar feature set to that of Netscape, that you could download and run on Windows for free, rather than having to pay for a full version of Netscape.
The only problem with IE was that, because it had its own rendering engine, a web page that was formatted for Netscape might not render (appear) properly in IE.
In spite of this, as soon as Netscape began to lose market share to Internet Explorer, web site developers had to start supporting IE. Often, this resulted in two versions of the same web page being embedded in to the same document – one set of HTML instructions for rendering properly in Netscape, and a second set of HTML instructions for rendering properly in IE. In some cases, two entire websites were maintained in parallel.
The standardization and release of HTML 4.01 forced newer versions of both browsers to converge on similar syntax and rendering standards, but that also meant that the (at the time) modern browsers had to support “the old” (pre-HTML 4.01) rendering, as well. Support for incomplete or legacy standards that pre-date HTML 4.01 became known as “Quirks” mode – essentially, a set of static rules for how to guess at rendering older content that may lack formatting specifics.
IE 6, released in 2001, was the first fully-HTML 4.01-compliant version of IE. With a five year lifespan, IE 6 was finally replaced with IE 7 in 2006, which also supported “Quirks” rendering, and had a three year lifespan.
Between these two versions, there was an eight year span, where web developers could do one of three things with their older content:
- Upgrade the content to modern standards — HTML 4.01 format, and use CSS (Cascading Style Sheets) for formatting specificity.
- Leave the content as-is, possibly using a second set of instructions specific to IE 5 and up, which might include some “Quirks”.
- Format the content using generic HTML so that the page looks “good enough” in either Netscape or IE, relying on “Quirks” rendering mode.
Worse, lazy developers could still create new applications and content either using split formatting, or relying on “Quirks” mode for proper presentation in IE.
So when Microsoft announced that IE 8 would no longer support “Quirks”, this was potentially a huge impact to websites that had published their content in a pre-IE 6 format. Now, for seemingly no reason, almost every website administrator would have to go back and review all of their applications and content, to make sure that everything strictly complied with HTML 4.01, even for apps and content had been out there for years, and had been working just fine when viewed in older versions of IE.
Microsoft’s original stance around the announcement was that these older standards had been deprecated long ago, and that all websites and software developers should be supporting modern standards.
The strict rendering approach was meant to streamline IE, which was now losing market share to Firefox and Chrome browsers. I’m sure someone looked at the code and said, “hey, we can cut 30% of the code out of IE if we dump support for rendering Quirks”, which sounds great on paper, but puts the burden on the customer base to have to go out there and update all of the stuff that isn’t compliant.
For some companies, updating circa 2000 applications could be very problematic:
- In the early days of web application development, it was not uncommon for the developer to move on to a new job without leaving the source code.
- It was also not uncommon for companies to be running commercially-developed, 2000-era web applications internally, that either couldn’t be updated for whatever reason, or the developer might have gone out of business.
- In addition, some companies used non-technical workers to maintain its website using content generation and publishing tools, and if those tools were not compliant, none of the content that they had published was compliant.
After quite a bit of backlash from the community, the “compromise” solution was “Compatibility View” – Microsoft would provide an IE6 rendering mode that could be manually triggered by the user, and would maintain a list of known websites and applications that would automatically trigger Compatibility View without user intervention. This supposedly allowed the core rendering engine of IE8 to be brought up to date and streamlined for efficiency in order to have competitive rendering times to those of Firefox and Chrome, while still providing a “legacy” rendering mode for websites and applications that couldn’t be brought up to date for whatever reason.
Lesson to be Learned: Don’t make assumptions about how users use your product. If you decide to drop support for a critical feature, the users might elect not to upgrade, or to switch to a competitor.
Market surveys might have quickly identified the issue with outdated applications and websites that would have been affected by dropping “Quirks” rendering.
Many modern software products include telemetry that helps the developers identify which components and features are commonly-used, in order to prevent this type of problem. Although this data is important, some users find it intrusive, so there has to be a fine balance, and a heavy emphasis on protecting user privacy.
If Microsoft had stuck to its guns, some enterprising third party would have figured out a way to repackage the IE6 rendering engine inside a custom application that could be widely sold to Microsoft’s enterprise customers, severely narrowing the drive to adopt IE8, and the end result is that Microsoft would have lost even more market share.
The user base will always find a way to get what they want. If YOU don’t provide it, YOU become the bad guy, and you risk creating a competing revenue stream, as a competitor or third party back-fills the missing functionality.
Mistake: Google+ is Mandatory
In 2011, Google realized that it severely missed the boat because it didn’t have a Facebook competitor, and thus, in June of 2011, Google+ (“Google Plus”) was launched.
No one liked it.
No one used it.
In 2013, Google took the unilateral route, making Google+ a mandatory part of all of its other services in order to try to boost adoption.
- You want to comment on YouTube? Sign in to Google+.
- You want to rate an app in “Google Play”? Sign in to Google+
- Gmail? Google+.
- Search? Google+.
- Send a text message in Android? Google Hangouts. Which, is tied to your Google+ profile.
The backlash was universal, and in 2015, Google finally announced that it would end forced integration, and also dropped its “real names” policy.
Lesson to be Learned: You can’t make something popular just by forcing it on everyone.
A better approach is to conduct user surveys before rolling out this type of policy, to see what your users think, and how it will affect them.
Mistake: Google Hangouts replaces SMS
Released in 2013, users of previous versions of Android, Google’s mobile operating system, who updated to the KitKat version were in for a big, yet hidden surprise.
Google quietly replaced the Android SMS application with “Hangouts”, which of course, linked to your Google+ profile.
In a very famous case, this change resulted in outing a transgender user, who thought she was sending an SMS to a co-worker. To her horror, she later discovered that she had sent a “hangouts message” instead, with a link to her Google+ profile (remember, integration was mandatory!), revealing her female identity to the coworker. The problem is that she was hired as a male, and maintained a male identity at work. There have been many infamous situations where transgenders have been ostracized, fired, or worse after being outed. Fortunately for her, there was no major impact, but things could have easily gone very wrong, very quickly, due to a single, simple text message.
Google called it a “user error”.
However, had she been clearly made aware that she was communicating using her “google identity” rather than a standard “text message” (a standard feature on all digital cell phones since 1998), she could have adjusted her profile and settings, or simply downloaded a 3rd-party SMS (text message) application.
To this day, modern versions of Android still use “Hangouts” rather than sending standard text messages, and this feature can’t natively be disabled. To work around it, you have to download a 3rd-party SMS application. Most if not all of the handset manufacturers and carriers have responded by disabling Hangouts by default, and including their own proprietary SMS application.
The users have spoken. The hardware manufacturers have spoken. The carriers have spoken. Google doesn’t seem to care.
Lessons to be Learned: Don’t change industry standards without resetting user expectations. If the user base is familiar with “standard” functionality, changing it equates to a policy change, and that can lead to problems.
Extensive use of surveys prior to release, within the user community might have uncovered the potential issues associated with the functionality / policy change.
Likewise, a proper tutorial and a clear, pop-up warning would provide the user with sufficient ability to make an informed decision about how to use the “Hangouts” application, or how to adjust or hide their personal information.
Meanwhile, even if Hangouts is enabled by default, simply having a setting that allows users to revert to “standard” SMS functionality instead (rather than mandate the use of Hangouts), would at least preclude the need for a third-party application, and would help maintain some semblance of standardization across the Google landscape.
Mistake: Google’s Real Names Policy
As part of its 2013 bad-policy trifecta, Google enacted it’s “real names” policy.
Google’s statement at the time was, “it’s important to Google for people to be authentic” (when making comments, etc…)
Dating back to ancient history, a pseudonym is an important tool, often used to anonymously criticize public policy without incurring the individual risk of retribution from the establishment or community.
An individual should be allowed to criticize the establishment, community, or even another individual, without the risk of retribution. This is part of the first amendment, and also, part of the Fair Use doctrine, which is the modern basis that legally allows for published criticism as well as parody.
Anonymity is a valid tool that can and should be used in the situation where a person faces monetary or social repercussions from expressing an opinion, yet has a fiduciary or ethical responsibility to be completely honest.
However, Google’s move had two purposes:
- Enable the ability to tie multiple services to one profile, in an attempt to refine the data mining that underlies micro-targeted advertising.
- Follow Facebook, who implemented the same policy for the same reason.
The policy itself had more to do with making money than some mythical quest for honesty or integrity.
As with mandatory Google+ integration, and amidst severe user backlash, Google dropped their “Real Names” policy in 2015.
Lesson to be Learned: Know your user base. Understand what they want and why they want it.
Again, early user surveys might have uncovered the issues with this policy change.
Mistake: Google Chrome’s “New Tab” Page
What do Internet Explorer and Firefox have in common, that Chrome doesn’t?
You can’t set the “New Tab” page in Chrome.
Just as you can set the “home” (or startup) page in all three browsers, Internet Explorer and Firefox allow you to define the “new tab” behavior – what the browser should display when a new, empty tab is opened by the user. Chrome, however, does not.
Some users severely dislike Chrome’s “New Tab” page, because it displays thumbnails of all most-frequently visited websites, and some people find this invasive, unnecessary, and potentially dangerous or embarrassing.
For example, if I used Chrome as my primary browser, and I fire up a new tab at Starbucks, you could figure out which bank I use, where my e-mail is stored, and where I shop online, all on one screen. Also, if I had recently visited an online lingerie store, that might show up there as well, along with a picture of the most recent movie I was watching on Netflix. Those would be awesome things to have pop up in a web meeting with a potential client…
In posts going back as far as 2008, users have been complaining about this, and asking for a solution, but Google is mute on the issue.
In the user forums, the common solution is, “install a plugin, there are many ‘New Tab Redirect’ plugins out there”.
The better questions are:
- Shouldn’t this be baked in to Chrome?
- In the era of identity theft and privacy awareness, shouldn’t there be an option to simply hide the thumbnails?
Lesson to be Learned: Users are obviously clamoring for this feature. Adding it in to the core product will make the users happy, will boost adoption, will help protect user privacy, and may prevent some users from running a malicious plugin masquerading as a “New Tab” utility.
Similarly, Microsoft incorporated the ability to create, modify, and open “compressed folders” (zip files) after many years where the most popular Windows application was WinZip. Everyone had it installed, because, before the age of One Drive and Google Drive, everything you downloaded or sent to someone was generally stored as a zip file. Very few people actually paid for WinZip, because quite often, they needed it once or twice, downloaded the shareware version, then never used it again. Providing basic zip file manipulation functionality without having to download a separate application was a huge win for the user base. For users that required advanced functionality, WinZip (and other archive file managers) was out there.
TBD: Apple’s iPhone 7 – No Headphone Jack
In a music-enabled world, that Apple itself helped bring about, it’s latest device has no physical headphone jack.
The iPhone 7 does, of course, support Bluetooth headphones, which are more expensive, and require periodic recharging.
The other option is to connect an “aux jack” – a dongle that plugs in to the bottom of the phone, and supplies a standard 3.5mm jack. Of course, the aux jack adapter is a $40 part that doesn’t come with the phone, and “dongles” in general, are known to be fragile and problematic.
The lack of a physical headphone jack is being highly-criticized by the media and the community.
We’ll see how this turns out…
Conclusion
The way to make your product truly great, and to maintain its relevance, is to deeply interact with the user community.
Making unilateral decisions about major design changes can lead to backlash, can affect product sales, and might even open up new market opportunities for your competitors and third parties.
Pingback: BlueStacks 3 – A Mess of Hardware Shaming and Pika Points | Justin A. Parr - Technologist