正文

---

如何设计复杂型的产品系统

处理复杂型产品系统的一些见解

BY  Erik K（Uber设计总监）

翻译：Kevin嚼薯片

在完成《设计数据可视化交互界面》的文章后，我对设计数据驱动的交互界面产生了极大的积极兴趣，我决定研究一个类似的、同样非常重要的主题：管理复杂型的产品系统。

当你的项目只做了一半就拿去展示的时候，会有那种令人不安的感觉。那种感觉让我很害怕，因为你知道潜藏在这下面的复杂性，在你解决问题之前它不会浮出水面。如果你不克服它，它就会破坏你的创造力，甚至在你看到出路之前就被扼杀掉。

产品设计的复杂性倾向于两种表现方式：1)管理员工和管理观点的复杂性。 2)产品本身设计的复杂性。在功能、用户和利益相关者的洪流中，是非常难以保持头脑清醒的。在过去，我失败过很多次，所以我想分享一些我在处理这些大型设计项目时所收集到的经验。

改变沟通方式

我将从这开始，因为这是管理任何设计项目的重要主题。作为设计师，我们经常会承接项目或需求。我们试着用有限的信息去很好地完成工作，但有时在压力下改变设计以应对限制时，我们会感到沮丧。

设计产品的难处在于，在这高风险的环境中混合了有很多观点。遗憾的是，设计师的观点并不总是这里的一部分。这是自然的，但你应该责备的是你自己。

作为设计师，我们有责任改变沟通方式。我们需要教育我们的客户、老板和团队成员如何在设计过程中迈向成功。

这很困难：有时我觉得我们的设计怎么说也没有用。这没有什么灵丹妙药，但有一些技术可以帮助你。

在你把他们带到那里之前，先告诉他们要去哪里

在项目一开始，我就向利益相关者展示了我们的设计过程。我详细地讲述每个主要阶段，并展示一些可交付成果。然后在项目的不同阶段，我都会标注我们目前所处的地方，及下一步去往哪里。

除此之外，我认为重要的是解释我们所期待的反馈类型及反馈时间点。有时我甚至会解释为什么反馈是必要的。这样一来，双方都能对最终的设计输出负责。

与上司沟通

每当我们开始一个新的设计项目时，我都要求与“老板”见面。这通常是首席执行官，或者是我能接触到的资历最深的人。我喜欢从公司的源头直接听到他们的愿景和预期结果。

我做了大量的笔记，去记录他们的情绪和所表述的话。然后我在讲述设计决策的时候去使用同样的语言。这样做是有好处的，因为没有人愿意和老板争论😉

当事情变得混乱的时候，这种情况会经常发生，我试着重新调整我在最初的会议上所听到的内容。作为设计从业者，我们的工作是将公司愿景转化为优雅的解决方案。没有什么比领导所表述的内容更能给你展示这公司的图景了。

同理心！

在构想阶段，我们通常会召集高管和主要的利益相关者，让他们向介绍公司用户的情况。目的是让这些利益相关者放下偏见，后退一步，从同理心的角度来考虑产品。

我们使用一种叫做 “同理心关系图” 的方法来促进讨论。前提很简单，问问你的利益相关者，他们的用户在想什么、在做什么、会说什么、怎么听和有什么感受，然后把它映射成一个人物角色。我们通常用2 - 3个关键人物角色，以及特定的时间里，去跟产品进行交互。

在几个项目中使用了这种方法后，我们收到相同且震惊的反馈——“这是我们第一次让所有的管理人员在一个房间里谈论我们的客户，真的很有成效。” 所以我们开始一直使用这种方法，正如你从上面的图像中看到的那样。

这虽然有点做作，但这是将任务和洞察力与产品系统中的真实用户联系起来的一种强大的方式。在很多情况下，我曾经接触过的利益相关者并没有参与过严格的设计过程，所以这样开始是适当的，并以一种良性的方式去建立一个设计权威。

了解产品使用频率

如果你正在修改现有的产品，你会发现大量需要重新设计的产品功能。大型产品系统中常见的问题是：希望找到一个能适合所有使用场景的方案。换句话说，他们是为每个人、每个场景去设计单一产品。如果给这个产品一个标签，就是 #繁杂# 。接受这样一个产品项目会让人望而生畏，要想成功，你需要了解产品的使用频率。

了解一个功能、屏幕展示、标签、甚至一个输入框的使用频繁程度，能给你一种优先级的判断。我发现它非常有助于客户去梳理现有的屏幕展示和元素，并划掉他们从不经常使用的东西。有时我们把它描述为80 / 20的行动（圈出那些有80%时间会使用的东西，然后删掉其他的东西）。

上面的图是一个项目，我们需要提取一个特定角色的关键元素。我们的目标是了解人们实际使用的是什么，然后在重新设计的工作流程中优先考虑这些功能。

关注输入和输出

大多数时候，产品是达到目的的手段。产品的需求通常来自某些方面，而输出却是其他方面。

在制作高保真设计的过程中很容易忽略了输入和输出。你的用户不太可能在没有任何其他干扰下通过一个清晰的屏幕上看到你的产品。你应该自问“这些信息来自哪里？”和“下一步要做什么？”

自问对于理解app的上下文至关重要。产品生态系统的复杂性会对你的设计产生很大的影响。你可能会发现你的产品在一个桌面中与30个其他窗口同时存在。或者它主要是在平板电脑上使用，或者是出于某种意想不到的目的。

上图突出了这个理念。在一次现场采访中，我们比较了：利益相关者访谈所得的产品使用方法 和 实际的产品使用方法。让我们惊讶的是，每一个参与者都在用一种与他所说的完全不同的方式来使用这个产品。

了解用户在产品和任务之间共享的关注点，重新改变了我们的设计策略。

可发现性和可学习性的优先级

当你为你的手机下载一个新的app时，它可以弹出小窗口去告知它能给你提供的价值，或者不做任何提示。这是提升可发现性的一个重要方式，因为作为一个消费者，你可以选择使用该产品或其他类似的100种产品。

这种发现性的特性也开始进入商业类软件。我们从客户那里听到反馈，说他们担心用户不会找到那些特别的功能，所以我们应该让它更突出，或者强调一下。如果这种情况足够多，你就会猜到，事情会变得混乱而复杂。

这是我们经常围绕学习性去争论的地方。不是所有的功能都需要变得可用，用户通过互动是可以学习的。好的互动只需要学习一次。

这是动物的本性，复杂的系统需要以牺牲可视性为代价。我们的工作是揭示主要的使用功能并使其尽可能直观。用户不应该“发现”经常使用的项目，也不应该要求他们记住文档才能使用产品。

简洁和清晰

在任何商用级的产品中，真正巨大的挑战是管理信息的密度。页面上的信息太多，会让用户陷入了一种精神上的混乱，太少，会开始让人难以获得有意义的见解。那么如何才能达到平衡呢?

简洁

有时，你有很多信息可以塞进一个小空间，但全部堆在手上并不是正确的方法。在这种情况下，我们通常建议一个渐进的方法来处理UI。逐步揭示是基于用户的利益驱动信息保真度的原则。

上图显示了这个概念。UI中的信息是结构化的，所以只有核心元素是可见的。然后，当用户想要的时候，就会引入更多的信息。交易关闭，当然，是以可见的速度，但你会得到一个更干净、更整洁的UI。

清晰

另一方面，有些产品要求有高级别的数据可见性来辅助完成任务。金融、医疗和电子商务都是众所周知的需要复杂数据的行业。

当数据密度很高时，试着对保持清晰度。使信息密度高的UI清晰的方法是通过使用视觉语言的一致性和收缩性。

在这种情形下保持一致性意味着对以下内容进行约束：

- 类型的变化

- 按钮的样式

- 简单的导航系统

以及对以下内容形成系统化：

- 颜色的选择

- 标签

- 微小元素的复制

所有这些都是优雅的解决方案。这个话题肯定需要更大、更深思熟虑的修改，但我先介绍这么多。

动态标签的交互

在过去，我们花很多时间来画线框图，用荒谬的线条、方块和箭头来连接它们。更糟糕的是，这些可交付成果往往很难让客户理解，并引致糟糕的假设和复杂的讨论。

当我们展示任何一种动态概念的时候，我们看到了他们不再疑惑。因此，我们开始创建基本的动态标签方法来展示和互动。

即使是使用基本的灰度线框图，这些动态动画也能免除沟通中的歧义。它不是线框图的替代品，但它是一个很好的工具，可以快速地减少同一页面上的复杂性。

给他们他们要的东西，以及他们没有的东西

亨利·福特最著名的创新格言是“如果我问他们想要什么，他们会说更快的马。”

客户通常要求“更快的马”，并且可能对它的外观和工作有一个概念。信不信由你，这往往会导致不必要的复杂性。我们都有过这样的经历，就像大多数设计师一样，尽管如此，我们被要求做很多我们并不兴奋的事情。

做你想做的事很重要，但做正确的事也是很重要的。

提出替代概念可能被认为是一种禁忌，尤其是在他们主动提出的时候。当我们有关于如何改进或简化的想法时，我们试图创造一个另外的观点，让利益相关者以一种全新的方式思考这个问题。

目标是通过理性思维和有数据支持的执行，并与客户建立信任关系。我们的客户尊重并普遍接受这样一个事实，即我们正在挑战假设，并将有想法的想法带到谈判桌上。

最终想法

设备、app和数据访问方式的变化使得设计以一些相当令人兴奋的方式在演变。不到两年前，设计笔记本电脑、手机和手表的想法还很少见，现在已经大众化了。交互的愿景越来越大，随之而来的是对管理复杂性的更大需求。

这是一段有趣的旅程，帮助这么多客户在过去的几年里创造出伟大的产品。如果你走的是一条类似的道路，我希望这些想法能为你做下一个大设计项目时，提供一些指导。

在文章底部打赏并留言，将获得《产品经理能力模型地图》和《运营能力模式地图》高清无码版本。

---

Designing complex products

Thoughts on managing complexity

BY  Erik K

After the overwhelmingly positive interest in my Designing Data-Driven Interfaces article, I decided to write about this related and equally important topic: managing complexity.

You know that unsettling feeling when you’re half way through a project and you’re presenting design concepts? No major feedback, smiles across the table, heads noddingyes.Home run right? No, that feeling scares the shit out of me becauseyou knowthere’s complexity lurking below and it will surface before you’re done solving the problem. If you don’t overcome it can crush your productivity and even kill the product before it sees the light of day.

Complexity in product design tends to rear its head in two ways 1) the complexity of managing people and opinions. And 2) the complexity of designing the product itself. It’s not always intuitive how to keep your head above water in a sea of features, users and stakeholders. I’ve certainly fallen on my face in the past, so I’d like to share some insights I’ve gleaned about tackling these big design projects.

Change the conversation

I’ll start here, since this is an over-arching theme for managing any design project. As designers we too often inherit projects or requirements and accept them as-is. We try to do a good job with the little information we have then get frustrated later when pressured to change the design to address changing constraints.

Part of why designing products is hard is because they represent high-stakes environments and there are a lot of opinions in the mix. Sadly, a design voice isn’t always part of that mix. It’s natural to blame the business, but the one you should blame is yourself.

It’s our responsibility as designers to change the conversation. We need to educate our clients, bosses and teams on how to be successful in a design process.

This is hard: sometimes I feel like our design sermon falls on deaf ears. There’s no silver bullet, but here are some techniques that help.

Show them where they’re going, before you take them there

At the outset of a project I present stakeholders with a peek at our design process. I walk everyone through each major stage and show sample deliverables of what to expect. Then at various points in the project, I remind everyone where we are and where we’re going next.

In addition to explaining the process, I think it’s important to explain what types of feedback I expect and when I expect it. Sometimes I even explain how and why feedback is essential. That way it’s clear that both sides have a responsibility to make the design successful.

Talk to the boss

Whenever we start a new design project I ask to meet with the “boss”. Usually it’s the CEO, or most senior person I can get access to. I like to hear the vision and expected outcomes straight from the source.

I take copious notes and try to capture the sentiment and “voice” of what’s being said. Then I re-use the same language later when advocating for design decisions.This has served me well, because nobody wants to argue with the boss 😉

When things get confusing, and they often do, I try to re-align with what I heard in that original meeting. As design practitioners it’s our job to translate the company vision into elegant solutions. There’s nothing better than the voice of the leadership to help remind you of the bigger picture.

Empathize!

As a part of the discovery phase we typically gather executives and key stakeholders into a room to tell us about their customers. The goal is to get stakeholders to let their guards down, take a step back and think about the product from an empathetic perspective.

We use a tactic called an empathy map to facilitate the discussion. The premise is simple, ask your stakeholders what their customers are thinking, doing, saying, hearing and feeling then map it to a persona. We typically do this for 2–3 key personas scoped to a specific time or interaction in the product.

After using this technique on a few projects we noticed consistent (and surprising) feedback— “That was the first time we’ve had all the executives in a room talking about our customers. It was really insightful.” So we started using this technique all the time, as you can see from the image above.

It may seem hokey but it’s a powerful way to tie tasks and insights to real users in the system. In many cases, stakeholders I’ve worked with haven’t participated in a rigorous design process before, so starting here was appropriate and helped establish a design authority in a benign way.

Understand frequency

If you’re working on overhauling an existing product, its not uncommon to find yourself cataloging aninsaneamount of features that need to be present in the redesign. One common thread I see in big software products is that they tend to be one-size-fits all solutions. In other words, they’re monolithic products that do everything for everybody. If there was one hashtag for these products it would be #complex. Taking on a project like this can be daunting, and to be successful you need to understand frequency of use.

Understanding how frequently a feature, screen, tab, or even an input box is used gives you a sense for priority. I find it extremely helpful for clients to comb through existing screens and circle elements they use everyday and cross out anything they never use or use infrequently. Sometimes we describe it as the 80/20 activity (circle the things you use 80% of the time and cross out anything else).

The figure above is an artifact from a project where we needed to extract the key elements for one specific persona. The goal is to understand what people are actually using then prioritize those features in the redesigned workflows.

Find the beginning and the end

Most of the time a product is a means to an end. The need for the product usually comes from somewhere else, and the output goes somewhere else.

It’s easy to get wrapped up in the process of crafting pixel-perfect designs and overlook the beginning and end. It’s unlikely your users are looking at your product on a crisp retina screen, in a perfectly sized window without any other distractions. You should ask the questions “Where does this information come from?” and “Where does it go next?”.

The answers to these questions are critical for understanding your app’s context.The complexity of the ecosystem your product lives in can have a big impact on your designs.You may learn that your product lives on a desktop with 30 other windows open. Or that it’s primarily used outside on a tablet or for some unintended purpose altogether.

The figure above highlights this concept in action. During an onsite interview we compared how people actually use the product with what we were told from stakeholders. To our surprise each of the participants used the product in a completely different way.

Understanding how the user’s focus and attention was shared between other products and tasks completely changed our redesign strategy.

Prioritize discoverability and learnability

When you download a new app for your phone, it has very short window to onboard you and provide value or it’s dead. That’s a big reason to promotediscoverability, because as a consumer you have a choice to use that product or 100 others like it.

This stigma of discoverability tends to carry over into business-class software too. We’ve heard critiques from clients saying they’re worried users won’t find a particular feature, so we should make it more prominent or give it more emphasis. If that happens enough times, you guessed it, things get messy and complex.

This is where we often make the argument forlearnability.Not every feature needs to blast you in the face to be usable, an interaction can be learned. Good interactions only need to be be learnt once.

It’s the nature of the beast, complex systems require the prioritization of features at the expense of visibility to others. It’s our job to uncover the primary use cases and make them as intuitive as possible. Users should never have to “discover” frequently used items, nor should they be required to memorize documentation to use the product.

Cleanliness and Clarity

One really big challenge in any business-class product is managing information density. Too much information on the page and it puts users in a mental straight jacket, too little and it starts making it cumbersome to reach meaningful insights. So how do you strike the right balance?

Cleanliness

Sometimes you have a lot of information to cram into a small space, but it’s not critical to have it all on-hand. In this case, we often suggest aprogressive revealstrategy for decluttering the UI. Progressive reveal is based on theprinciple that the user’s interest drives information fidelity.

The figure above shows this idea in action. The information in the UI is structured so only the core elements are visible. Then more fidelity is introduced when the user wants it, and no sooner. The trade off, of course, is speed to insight, but you get the benefit of a cleaner, less cluttered UI.

Clarity

On the other hand, some products demand a high-level of data visibility for the job to be done. Financial, healthcare, and e-commerce are industries known for having notoriously complex products.

When data density is important, try to be meticulous about clarity. The way to make dense UIs clear is by being ultra consistent and crisp with the visual language.

Dialing in that consistency means exercising extreme constraint with the following:

- Type variations

- Button styles

- Simple navigation systems

And being systematic about:

- Color choices

- Labeling

- Even the microcopy

All this adds up to an elegant solution. This topic certainly warrants a bigger, more thoughtful writeup, so I’ll leave it at that.

Animate Signature Interactions

In the past we’ve spent countless hours generating wireframes and tediously connecting them with an absurd amount of lines, boxes and arrows. What’s worse, these deliverables tend to be hard for clients to understand and lead to bad assumptions and convoluted discussions.

Time and time again we see faces light up when we present any kind of motion concepts. So we started creating basic motion treatments to demonstrate signature (read: hard to communicate), interactions.

Even with basic grayscale wireframes, these animations zap the ambiguity from the conversation. It’s not a replacement for full wireframes, but it’s a great tool to cut through the complexity of getting people on the same page quickly.

Give ’em what they asked for, and something they didn’t

Henry Ford’s most famous innovation adage captures it best —“If I had asked people what they wanted, they would have said faster horses.”

Clients usually ask for “faster horses”, and probably have an idea of how it should look and work too. Believe it or not, this often leads to unnecessary complexity. We’ve all been there, and like most designers, we get asked to do plenty of things we’re not overly excited about. Nonetheless,

It’s important to do what’s asked of you, but it’s also important to do what’s right.

It may be considered a bit taboo to present alternative concepts, especially when they are unsolicited. When we have ideas on how to improve or simplify, we try to create a polarizing view and get stakeholders thinking about the problem in a fresh way.

The goal is to build trust with your client through thoughtful executions backed by reason and data. Our clients respect and generally embrace the fact that we’re challenging assumptions and bringing thoughtful ideas to the table.

Final Thoughts

The changes in devices, apps, and access to data has caused design to evolve in some pretty exciting ways. Less than two years ago the thought of designing for laptop, phone, and watch simultaneously was rare, now it’s table stakes. The landscape of interactions is ever growing, and with that comes an even greater need to manage complexity.

It’s been a fun journey helping so many clients create great products over the years. If you’re on a similar path I hope these thoughts provide some guidance on your next big design project.

英文原文来自：https://blog.truthlabs.com/designing-complex-products-8f9289ab26c9