Skype’s Future Redesign of Their Recent Redesign: How Did That Happen?

Posted By Debbie on September 14, 2018

In September 2018, Skype made the tech news announcing that a redesign would be coming, roughly a year after their last redesign. The goal would be to simplify and remove many of the features they added the year before. These new features were designed to emulate Snapchat and (supposedly) attract younger customers. The backlash was large enough that Skype felt the need to announce their redesign intentions to the public.

This is a DevOps disaster.

One can only guess at the internal cost for Skype to have designed, built, and tested these features. The cost to release them across multiple platforms and devices. The coming cost to redo and undo features, UX, and UI. It’s staggering. I have no internal knowledge of Skype but I would estimate it at millions of dollars.

This is where DevOps goals like shorter time to market, productivity, efficiency, and good internal culture and communication may have scored well. However, these won’t matter much if we’re not achieving and improving other DevOps goals like building the right product for the user and increased customer satisfaction. All of the beautifully-planned Sprints and IT triumphs are for naught when a product fails in the eyes of the user.

So how did this happen?

According to me, there are three components to Product Design success:

  1. The company must value the user over the business. In this case, Skype probably wanted to deliver what they thought users wanted even if it would cost the business time and money.
  2. The company must respect their product designers, normally a UX team. This means giving them the staffing, budget, resources, and time they need to do a proper UX process. Many companies want to skip steps in the UX process thinking this will save time or money. UX practitioners and processes are often circumvented, excluded, or overruled by Product or Engineering. Ultimately, these are mistakes that often lead to spending extra time and money in development cycles or facing larger issues like Skype now is.
  3. The company must hire expert, experienced UX specialists to do UX work. Many companies misunderstand UX and believe that “anybody can make wireframes.” They see the “designer” title and believe that any artist can do the work. Some companies believe that Agile Teams should do the UX work (without a UX specialist). There is no other software development role where companies hire untrained, non-experts who might have no natural talent for that role. If we hire expert, trained, and talented engineers, we should hire expert, trained, and talented UX employees, contractors, or freelancers.

Without internal knowledge of Skype, I can’t say for sure where they went wrong. I can create hypotheses based on what I have seen happen at many companies, including Fortune 500s.

If These Were UX Failures, Why Is This a DevOps Problem?

At many companies, Engineering is fed designs and blueprints by their UX team. Engineering does not operate in a vacuum. DevOps aims for customer-focused goals including getting the right product to customers in a shorter amount of time as well as improving customer satisfaction. Engineers already complain that UX is siloed; if you leave UX out of your definitions of software development, you are creating more disconnection, less collaboration, and supporting the siloing.

DevOps should care if the product they are building is a quality product. Quality must be established through a thorough and proper UX process. Talented developers can build entire products just from Product Managers describing the interface… but that doesn’t mean they should. UX has an extensive and formalized process centering around research, design, testing, and iteration. That should feel familiar to Engineering and it should be fully supported. DevOps cares about corporate culture and collaboration; working harmoniously and efficiently with UX should be considered part of DevOps goals.

DevOps should include the process by which they receive what they will build. This also includes UX and Engineering collaborating during the UX process as well as during Engineering processes. Collaboration should go both ways and should continue even after the feature is released; UX would want to keep an eye on metrics and KPIs to see if results show success or failure.

Possible Scenario 1: Product Should Collaborate With UX Very Early On

I imagine someone in Product said, “Hey, we could really win over younger customers if we make this more like Snapchat!” Product might have received support for that idea and the decision may have been made to build those features.

One important role for UX practitioners is to work with Product as soon as there are feature concepts or ideas. UX normally checks and balances Product in the following ways:

  • If Product is not forthcoming with data, UX should push Product for data that shows customer pain points, needs, or frustrations. There might also be data on our business opportunities to solve customer problems or innovate. To continue with our Skype example, was UX at the table to ask Product for data that proves that customers want Skype to be more like Snapchat?
  • If this data was produced, was it biased or skewed? Did it lack detail? Was it only quantitative? For example, “X% of our surveyed users said they love Snapchat.” That might be true but that doesn’t mean they want Skype to be Snapchat.
  • If this data cannot be produced, the project should not happen or UX should spin up a research project to collect the data that would best inform all relevant teams. Did UX researchers at Skype undertake a study to determine what users needed or what would make younger users switch to Skype? It seems unlikely that this happened since this research would have indicated and foreseen that turning Skype into Snapchat was not what current or potential customers wanted.
  • UX can save companies an incredible amount of time, money, backlash, outrage, social media cleanup, and rolling heads if brought in early enough to validate whether or not a feature should be built. This can only happen when Product and/or Project Managers know to have UX in those early discussions.

At many companies, Product and Project leave UX out of these early stages either because they don’t understand the value UX can bring or because they want to eliminate anybody who might change or kill their ideas. Purposefully excluding teammates out of fear that your idea will be shot down or changed is ego-based and doesn’t belong in product design or software development.

Possible Scenario 2: Product Prescribed the Designs

UX is often left out of early feature and concept discussions. They become aware of ideas and projects when they are invited to a kick-off meeting. By then, it’s considered “too late” for UX to kill or evolve the project; it has been approved, funded, staffed, and here we all are to start building it.

At this point, I have often seen the Product team tell UX how the feature will look or work. In Skype’s case, that might have sounded like, “We like the way Snapchat does this, this, and this. Wireframe that.” Due to misunderstanding the UX process and tasks, Product and Project Managers often give UX very little time to do this. When UX wants to research, design, test, iterate, and use their process, they are often told that there isn’t time. We must hurry up and get wireframes to Engineering; UX is now the bottleneck, being warned that they are throwing off the timeline or Sprints.

UX then ends up more as “Production Designers,” building what they are told. This is not a real or good UX process or approach. Throwing this kind of work at the UX team is also what leads many companies to hire non-specialists in UX jobs. Hey, if “anybody can make wireframes” and our Product team knows exactly how this should look and work, then give this to the junior graphic designer or cheapest person we can find. Why hire talented experts or specialists?

Possible Scenario 3: UX Should Conduct User Testing Before Developers Write a Line of Code

Even when companies don’t allow time or budget for UX research, user testing (when done by UX experts) can be used to validate or invalidate hypotheses and ideas. UX can mock up or prototype the feature and its execution. It can then be tested on real or archetypal customers.

Poorly-designed or poorly-run user testing can be biased, providing data that looks real but is actually junk science.

Who would spend time and money on user testing and not do it correctly? Many companies for many reasons. Again, if companies are not hiring UX specialists because they don’t really understand who they are or what they do, then who knows who at the company is doing user testing. I worked at one Fortune 500 that decided that Product Managers can do user testing. Some of the company’s Product Managers had reputations for manipulating the data they used both to bring their project to life and to prove after launch that the project was a winner; now we’re going to let these people test UX designs?

If your company is adopting Lean principles, you might imagine that UX testing isn’t needed. We’ll come up with an MVP, just ship it, and see what people think. Or we’ll push it to X% of users as a live experiment. However, once you ship it, that is the product that your customers must use. They can’t roll back to another version. If they dislike it, you have left them with no choices. Why would you want to burn time and money having Engineering develop, test, and deploy something that has not been vetted in user testing? The risks are too high.

Companies make strange choices in the belief that they are saving time and money. You can’t skimp on user testing. The proposed designs should have been thoroughly and properly tested by UX professionals.

Possible Scenario 4: The Skype UX Team is Awesome but Was Overruled at Every Turn

Companies might care about the user and hire great UX workers but then show them nothing but disrespect. They are excluded, circumvented, and overruled. I have seen a Lean Triad engineer at a Fortune 500 explode in delight during a cross-functional team meeting. What was so wonderful? His programmers excluded UX workers from their process and did some UX design themselves; according to him, that was cutting, “Lean waste.”

I would have to buy you a 6-pack of water, soda, or something stronger to tell you all of my stories. Time after time, there is a teammate with no UX education, training, experience, or (in some cases) talent, but they are sure they know better than the UX pros how this should be laid out, what the process is, and how users interact with it. When these test poorly, you’d imagine that these pseudo-experts would surrender to the testing results and allow UX to move forward with UX’s recommended concepts. But I have been on teams where I was directed to use the ideas that tested poorly and, “make them work.” Egos should not force a bad user experience to stay in the feature.

Have you ever noticed this doesn’t happen in the other direction? Your UX practitioners don’t show up to meetings and tell business analysts how to do their jobs. UX workers don’t show up to engineering meetings, stand over programmers, and suggest changes to their code or approach. Yet so many unqualified people at companies whose names you would recognize are sure they are better product designers than specialized, expert product designers. This is the Barnum Effect, and anything companies can do to help certain people self-assess their UX talents and skills more accurately will be greatly appreciated by your UX specialists.

Any One of These Can Summon The Four Horsemen of Bad UX® for Your Customers

Looking at Skype’s situation, any one of these may have happened. More than one of these may have happened. These are incredibly common at companies of all sizes. We tend to assume that the Microsofts, Apples, and Googles of the world are hiring the best people, giving them what they need to deliver their best work, and utilizing that work product in the best ways possible. Many times a year, the tech news provides us with the wake-up calls that this fantasy is not reality.

The Skype example highlights what happens when UX practitioners are not brought into the product and software development process at all points where they are necessary. UX is a piece of the puzzle that more and more companies are learning can’t be left out, skimped on, or given to non-experts.

What can your company change or improve before you become the next tech news headline?