Review: Enterprise UX 2017, Part 2: Conference, Day 1

Augmenting Teams

“How are we going to augment the people we support?” asked Elizabeth. She told a story about “introducing productivity and collaboration tools” to augment the capabilities of teams. A project began in 1999 at Fuji-Xerox to build collaborations between researchers in Tokyo and Silicon Valley. A curator seeded posts on interactive boards to create a sense of shared experience. This was the YeTi interface—the Yesterday/Today interface—of Collabo-poster, whose goal was to create trust, a collaborative environment, and co-ownership.

Today, Google’s Jam Board serves a similar purpose. It integrates with Google’s G Suite and provides distributed social sharing, making “a whole host of collaborations possible.” Elizabeth spoke about the cultural impacts of the uptake of technologies and their long-term legacy.

Material Design

In 2014, Google published its Material Design Framework for Android, iOS, and the Web at material.io. They based this framework on classic principles of design and cognition. Today, 90% of external application designers and developers use the Material Design Framework. Elizabeth showed a number of examples of Material Design—including that shown in Figure 5—saying that these “codified best practices are bringing consumer-quality experiences into the enterprise.”

“Material Design crosses all product teams, including enterprise product teams, leading to the cross-fertilization of ideas across silos,” said Elizabeth.

Research

Google’s practical research has looked at the uptake of tools by designers and consumers. Three examples in particular represent different cadences:

1. Google conducted a study of the line affordances of text fields, identifying seven variable to test, evaluating the performance of 144 alternative design solutions, then determining a discrete set of the best contenders and demonstrating their impact on the enterprise.
2. Google studied text legibility, looking at the contrast ratio between text and its background. This research is having an impact on accessibility standards.
3. During its study of workflows and collaborations, Google interviewed designers about their use of collaboration tools and learned: “Iteration is more effective. Social diffusion through collaboration is key.” Therefore, Google is codifying its work into tools.

Final Thoughts

Elizabeth considered “time as a calendar, as a task, as retrospect, as foresight, as deep coordination and collaboration with others.” She told us, “Work gets done in conversations.” She described time and time management as “a trust exchange.” She also looked at “time as archive, as impact, and as UX strategy design material—collaboration and communication strategy.”

In concluding her talk, Elizabeth asked, “How do we build tools for collaboration and trust and long-term strategic benefit?” She has a passion for designing collaboration tools, which she referred to as her “first love.” Because of my passion for and experience working on collaboration software, I really enjoyed this keynote.

Elizabeth was unphased by the audio-visual challenges of the morning, ensuring that any negative impact on the quality of attendees’ conference experience was minimal. She took a couple of follow-up questions from the audience:

1. “How does timeboxing affect the more strategic conversation?”—Elizabeth answered: “Timeboxing is about managing your own time or the time of the group. It reduces anxiety. It creates a check-in moment and can motivate. It also helps everyone understand the objective. It provides a means of cognitive switching, too. None of these precludes having the bigger perspective. Did we achieve our goal? What was that meeting for? Did we get closer to the bigger goal? The challenge is that our work is always a work in process. Things shift. Retrospectives provide a means of reevaluting what did and didn’t work. Timeboxing is good for psychological reasons, but if you’re a slave to it, you don’t focus on the bigger picture.”
2. “How were you able to convince your management to allow you to do the Collabo-poster?”—Elizabeth responded: “The CEO came to us saying, ‘There’s no collaboration happening.’ He was looking for rapport, trust, and creativity. Our teams weren’t working effectively together. I wanted to try another solution—creating knowledge and social capital. Conversation would lead to rapport and, ultimately, to other collaboration tools. Offer tools that enable better work across silos. Then provide relevant business metrics. Use internal productivity metrics to make your point. To build a business case, you need to find measures and metrics that are important to the business and show progress. Be creative, honest, and persuasive.”

Elizabeth is an entertaining speaker, and this was a great keynote!

Morning of Day 1: Highlights from Conference Sessions

The sessions during the morning of Day 1 of EUX 2017 focused on the first of four conference themes:

Crafting Enterprise Experiences—“The enterprise setting forces us to redefine what good design means. We’ll explore how unique factors like complexity, scale, and lack of control can impact our craft and completely change our expectations.” Theresa Neil was the theme leader.

Solving Not Sexy, But Important Problems

Presenter: Tricia Wang

Tricia Wang, shown in Figure 6, is Global Technology Ethnographer and Cofounder at Constellate Data. In Figure 7, MJ Broadbent’s sketchnote provides a summary of Tricia’s talk. She spoke about “why corporate innovation doesn’t work and how to fix it.” Tricia attributed corporations’ innovation challenges to distributed and hierarchical decision-making. “Insights lose fidelity as they travel up the hierarchy,” said Tricia. “By the time the insights make it to decision makers, they somehow seem less powerful, less transformative. The people who found the insights are not present in those discussions.”

Tricia told us, “Every company needs a Department of the Unknown. Connect people who are closest to the unknown—ethnographers, market researchers, UX researchers—with those making the decisions.” She provided three principles for sharing data:

1. Use numbers and words to tell a story.
2. Share data that surfaces the unknown.
3. Ensure decision makers directly experience the data.

To explore and make decisions, Tricia recommends using the Integrated Data Thinking Framework, shown in Figure 8.

Taming Design Complexity with UX Models

Presenter: Robert Reimann

Robert Reimann, Principal UX Designer at PatientsLikeMe, who is shown in Figure 9, delivered an in-depth presentation on strategic UX models that help tame the design complexity of enterprise systems. Figure 10 shows MJ Broadbent’s sketchnote of Robert’s talk.

Robert began by saying, “It’s still too often the case that enterprise systems are stuck in the past or don’t deliver on promises or just don’t work very well for users.” There are three main reasons why this is so:

1. “Enterprise software mainly serves corporate goals and rarely serves people goals well.”
2. “Enterprise applications don’t always scale in the ways that best suit the companies that purchase them.”
3. “The design of enterprise software is really, really complicated and that complexity gets passed on to users.”

What does Robert mean by UX models? Wireframes and flow diagrams are “tactical-level UX models that we use every day.” However, Robert’s talk was about more strategic UX models, about which he said, “They’re simply methods of visualizing, categorizing, and describing … people, organizations,” and product experiences we want people to have. “They can help you empathize better with your target users. Help you understand the shape and scope of your designs with more clarity. So UX models are really the power tools for tackling the complexity of enterprise systems.”

Scott Berinato, an editor at Harvard Business Review and author of Good Charts, proposed the model of models shown in Figure 11. Robert focused his discussion on
the illustrative models in the upper-left quadrant of Berinato’s model of models. Models that “we can use to help clarify ideas, user behaviors, and UX structure as a way to start tackling complexity.”

Source: Sketch by Christina Wodtke

Robert described five types of UX models:

1. Enterprise user models, or personas
2. Data ecology and sequence models
3. Organizational models
4. Concept maps
5. Systems models

1. Enterprise User Models, or Personas

Personas help us to understand our design targets. “Enterprise is the sweet spot for personas! That’s really where personas are great,” said Robert. “They’re some of the best tools for understanding what your users are trying to do, what their needs are, and what their motivations are. Personas help you enumerate, group, and prioritize. They help you understand what functions and behaviors should be in your product, how they should be grouped together, how they should be prioritized, and how to structure your entire suite of functions.

“In an enterprise setting, personas are usually very closely related to roles and skills. While those initial types might be easy to identify, [understanding] the actual needs and behaviors really require user research. Personas for an enterprise product have a different scope than consumer personas. They’re both broad and deep. There’s the breadth of the enterprise product, but there’s the depth as well. It’s kind of a challenge to figure out the structure, so you don’t have too few personas that are too broad and don’t give you any information about the functionality [of] such a complex product and don’t become overwhelmed by a sea of personas that you don’t really know how to manage.”

Figure 12 shows a set of primary and secondary personas that Robert created for a legal ediscovery product. Figure 13 shows a blowup on one of these personas. An enterprise persona defines the role, tells the user’s story and describes the product’s painpoints to build empathy, summarizes goals and requirements—delving into the specific user’s needs and primary usage patterns—and, in some cases, denotes skills along skill ranges.

To solve the breadth and depth issue, Robert advised that we need two different tiers of personas:

1. First-tier personas—These define “the broad roles and usage patterns at the suite level” and help you “to figure out the different modules and sections of your enterprise product.”
2. Second-tier personas—These define “detailed breakdowns of goals and needs at the module level. At the individual module level, you’ll definitely have different usage patterns, and that’s what this tiering is all about.”

“Another thing you need to keep track of are the interactions between different roles,” said Robert. “Those can be transactional”—and, thus, can be captured in workflows. They can be structural. How is an enterprise and its departments structured? “Are there silos? How does information get back and forth between people? And related to that are cultural issues.” How the company “views what it’s trying to do and how it communicates. How does that affect these relationships?

“There are also non-user personas that are super important,” Robert told us. “One is the customer persona—the person who’s buying the system. You obviously have to make the people who are buying the software happy at some level. Just make sure you’re not doing that at the expense of the people who are actually using the product on a day-to-day basis. The other persona that’s really, really important for enterprise products is the served persona—the people who are being served by the system, but aren’t the users of the system. This is especially important in healthcare.” People depend on these enterprise systems working the way they should.

Data Ecology and Sequence Models

These models aid our understanding of data flow and sequence. “Once you have personas and you’re trying to figure out how data flows between them and what you’re trying to accomplish,” these models help you to visualize the process, suggested Robert. “Data ecology models show where information is produced, consumed, and passed along to others. They’re very helpful for both the design team and the stakeholders and, ultimately, the developers.” Figure 14 shows a data ecology model for the legal ediscovery product Robert worked on.

Robert told us about “another kind of model that is helpful: the activity sequence model,” which shows a process over time—“who is doing what when, what the timing of the actions is across roles, and any painpoints or out-of-sync actions so they can be corrected in the design.” These two models together “paint a picture of exactly how data is coordinated, how it flows, and helps you go to the next stage of building appropriate workflows and wireframes and so forth.” Figure 15 depicts an activity sequence model.

Organizational Models

Organizational models enable us to understand the business landscape, so we “can figure out the right direction for design,” stated Robert. Figure 16 shows Booz & Company’s Organizational DNA model. “It calls out four major elements, and they’re divided into formalized behaviors and informal behaviors. They include decision-making policies, incentives to succeed, data and tacit data in the system, organizational structures, and interpersonal communication styles. Enterprise systems fail if the design of the system is not a good match for some of these elements. It’s pretty standard to incorporate the formal [elements] into enterprise software, but it’s the cutting edge to start thinking about some of these more informal things. They represent some hidden complexity that can trip up a design. The solution to finding and incorporating that stuff is appropriate UX research that can lead to good user models, allowing mappings to the organizational models.”

Source: Organizational DNA model created by Booz & Co.

“There are many different kinds of business domains, and they’re all structured differently,” do things differently, and “have different needs when it comes to software.” suggested Robert. For example:

• research-and-development-centric domains such as the pharmaceutical industry
• manufacturing-centric domains such as the automotive industry
• marketing-and-sales-centric domains such as retail
• service-centric domains such as hotels
• resource-centric domains such as mining
• distribution-centric domains such as utilities

“A company’s business model often reflects its domain,” said Robert. “By visualizing the business model, you can also get clarity of what elements are most important to a business and why. Alexander Osterwalder and Yves Pigneur have invented a tool for doing this: the business model canvas.” Figure 17 shows an example of a business model canvas created by Osterwalder and Pigneur. “The model represents key partners, activities, resources, cost structures, customer relationships and segments, revenue streams, the value proposition,” and external forces that affect the business. “Working with product owners and stakeholders, you can use a model like this to help develop business and UX strategy, compare your business to competitors, and get priority alignment.”

Source: Business model canvas created by Alexander Osterwalder and Yves Pigneur

Organizational growth is another thing you can model and consider in enterprise design. Figure 18 shows Larry Greiner’s organizational growth model. “Does your enterprise take this into account?” asked Robert. “What happens when a company makes the transition from Phase 1 to Phase 2? Is your software going to be able to deal with the changes?”

Source: Organizational growth model created by Larry E. Greiner and published in Harvard Business Review in his article “Evolution and Revolution as Organizations Grow”

You can also model organizational culture. Figure 19 shows Kim Cameron and Robert Quinn’s competing frameworks model. “Enterprise tools can either help or can hinder,” said Robert. “In the Clan culture, since decisions are participatory, tools and techniques that facilitate teamwork, collaboration, talent management, and consensus building are super important to that kind of organization. In an Adhocracy, they need to be flexible and think outside the box, so any kind of software that imposes rigid processes or policies that are controlled centrally is going to be rejected. Classical command-and-control systems would be super at home in a hierarchy-based corporate culture. A market-culture organization, since its emphasis is on competition and speed to market, would seek tools for being more competitive, having rapid response to market changes, help in decision-making, and help in setting appropriate goals.”

Source: Competing frameworks model created by Kim Cameron and Robert Quinn, from their book Diagnosing and Changing Corporate Culture.

Concept Maps

Concept maps provide an understanding of data objects and their relationships. “If you have a complex system with a lot of complex objects and relationships, nothing beats a concept map as a way of itemizing and visualizing those things and making sense of them,” advised Robert. “Concept maps are basically webs of terms.” Verbs or verb phrases connect terms to other terms. “The purpose of a concept map is to represent, on a single visual plane, a complex concept.” Joseph D. Novak pioneered this approach in his book Learning How to Learn. “Use of concept maps isn’t limited to the functionality of the project, but can also involve strategy and process and other things as well.” Figure 20 shows an example of a concept map.

Robert described Hugh Dubberly’s approach to creating concept maps, as follows:

1. Enumerate all the terms.
2. Enumerate the relationships between the terms by listing them on two axes and creating a matrix, then filling in the matrix according to what the relationships are.
3. Undoubtedly you will find duplicates. Merge and cull those terms. Then, rank the terms in order of importance.
4. Use the rankings to determine the main branches and write the framing sentences that connect all of the nodes together.
5. Fill in details.
6. Apply typography and color to reinforce hierarchy.

Systems Models

These models help you to understand the mechanics of a system and express things in a way that can provide alignment across all the different departments in your company—not at the database-structure or engineering level, but in a human-readable way that’s understandable by all stakeholders. Figure 21 shows an example of a systems model.

In Summary

Robert summarized his presentation as follows:

• “Models help you organize design thinking and inform product structure, flow, and focus.
• “Two-tiered user models help you prioritize both broad and detailed system behaviors to address the goals and needs of each user role and its variants.
• “Data ecology and sequence models help you understand what information is used by whom. where it comes from, where it’s going, and when it needs to be there.
• “Organizational models help you identify business goals, practices, needs, and cultural assumptions to help make a better match for your enterprise system.
• “Concept maps help you make sure that the right objects and actions get built into the system.
• “System models help you achieve consensus regarding the planning and mechanics of complex features.”

Robert delivered a wealth of useful information, providing an overview of methods for modeling enterprise experiences and conveying many possibilities for taming the complexity of enterprise systems.

Resilient Enterprise Design

Presenter: Craig Villamor

Craig Villamor, shown in Figure 22, is VP, Product Experience, at AppDynamics. While at Salesforce, Craig led the Lightning project from its inception to its launch, making him one of the foremost authorities on creating the design systems that are so essential to today’s enterprises.

Craig spoke about some of the unique challenges of enterprise design, then introduced the concept of resilience as a means of dealing with those challenges. In Figure 23, you can see MJ Broadbent’s sketchnote of his talk.

Consumerization

Today, there is a strong trend toward the consumerization of IT (Information Technology) and enterprise software, “applying consumer thinking and consumer experiences to the enterprise. This really has created a new class of enterprise applications. Things like Slack, Asana, Google’s G Suite, Dropbox, and many others,” said Craig. “Now, there’s this new reference for even traditional enterprise companies to follow, creating a lot of competitive pressure in the market. So the big guys like SAP, Oracle, and Salesforce are really paying attention. This becomes a business imperative, and UX is finally getting a seat at the table inside these larger organizations.

“Is this idea of consumerization over-hyped and over-simplified? How far should we go with this consumerization concept? The needs of the enterprise are not identical to those of the consumer. That doesn’t mean we shouldn’t create great and delightful experiences for our users. It just means we shouldn’t ignore these differences.

“Designing for the consumer is really about making that individual happy. If you can do that at scale, you’re doing a pretty good job. If you can figure out how to make money doing that, you’re doing a great job.

Context

“We don’t become different people at work, but our context changes and our behavior changes. The reason for that is that you have other people to answer to—your peers, your boss, the executives, the company, the culture, customers, shareholders, and Legal. The software you use at work needs to account for the context and realities of your life at work because enterprise software is there to help you get work done—not just make you happy. But, if we can do both of those things at the same time, we’re really getting somewhere.”

Craig shared an example of what he means by context, showing the AppDynamics application in Figure 24, which monitors the performance of critical applications for companies and informs them about issues. “The real value of this product is what you see in red,” said Craig. “Things that are in green are working perfectly. Things that are in red are things that an IT operations person needs to pay attention to.” When Craig’s team ran a usability study recently, they decided to ask participants whether, in the interest of simplification, they could remove everything in green. “We got a consistent and strong response from everybody that we asked: ‘Absolutely not!’ So we asked, ‘Why not?’ One [reason] was really consistent: My boss might be looking over my shoulder while I’m working and, [seeing] nothing but red, … think I’m not doing my job. Context really matters.”

Constraints and Compromise

Designing software for the enterprise is really about making the people who use our software more effective, as shown in Figure 25, and “making sure that people don’t look like they don’t know what they’re doing. Protect their reputation. Protect their career goals,” advised Craig.

Craig shared this quotation:

“Designing for the real world means dealing with the practical constraints of that reality and trying to make refinements in the face of compromise.”—Steve Vassallo, GP at Foundation Capital

“Constraints and compromise are part of every designer’s life, but this is especially challenging in the enterprise, where we need to balance the needs between the company that has bought the software and the user,” Craig told us.

The Changing Role of Design

“As designers, we’re really passionate about our craft. We’ve done a lot of research, and we have a very specific idea of what the right experience is. And we’ll go to great lengths to ensure that experience makes its way into the real world,” observed Craig. “But the truth is, we’re not in control. This has been especially true since the introduction of mobile—or at least the introduction of the iPhone. Now, we’re dealing with thousands of different types of device, different display sizes, and different input types.” Craig shared this Karen McGrane quotation:

“With the rise of mobile devices and now tablets, we have to give up this shared hallucination that we have all been operating under, that we have any control over the presentation.”—Karen McGrane

“As designers, how have we responded to this challenge?” asked Craig. “In about 2010, Ethan Marcotte introduced the concept of Responsive Web Design (RWD),” as shown in Figure 26. “Using fluid layouts, media queries, proportional grids, and flexible images, he made it possible to render content across a variety of devices without breaking the experience. This is now the de facto standard for designing for the Web.”

Sharing some examples of RWD implementations, Craig noted that, “These are all relatively static sites. So they have content they need to flow across a variety of devices, but that content isn’t super dynamic. There’s a known set of content. But what about Web applications? Responsive Web Design is awesome, but it’s only focused on layout, and for us, as enterprise designers, it’s really only the beginning.

“Why?” Craig asked. “Customization. People love to customize. Each of us is unique, and we often want to express our unique needs and desires in the products that we use and consume. It’s driving a ton of business. What does this have to do with the enterprise? Every organization is unique. In the enterprise, customization isn’t just nice to have, it’s a must have. Companies want to express their brand, their culture, their values, their workflow, their terminology, their processes inside the software they use. The larger the company is, the more important it is for them to have customization to express this.

“Salesforce, my former employer of ten-plus years, is an example of a company that has embraced customization and really made it much more approachable to the ordinary user—to their customer. They built a platform around it. The way Salesforce is structured is [around] objects and, because Salesforce started as a CRM (Customer Relationship Management) company, the most common objects in the system are the ones you would expect: Accounts, Contacts, Opportunities, and Leads. But there’s one that’s very popular that you might not think about, and that’s Custom—anything that the product does not yet track for an organization. You can also customize workflows, field names, requiredness, and visibility—and even the layout of pages.

“Imagine that the page you designed looks nothing like you intended because somebody has since customized it. When users have control over the experience, what kind of experiences will they create? When you give customers the power to build anything that they want, they will do exactly that. They get really excited about this power, and the things that they build will often surprise you. They may not reflect very well on you, as the designer, or on your Design team, or on your organization.

“So this presents a really big challenge: If Responsive Web Design lets us manage the lack of control over layout, how might we manage the lack of control over the application experience itself? How might we design for a universe of outcomes and not just a single outcome? If we think about customization from the beginning and we think about this idea of resiliency, can we actually create even better designs?”

Resilient Application Design

“How do we design with flexibility in mind?” asked Craig. “When I think about resilient application design, I really think about four core ideas:

1. Design principles—These principles help you to “drive design decisions.”
2. Platform mindset—Working with this mindset lets you “solve the specific, then generalize.”
3. Design system—Executing on a design system creates flexibility, consistency, and scalability.
4. Influence > control—“With this concept that influence is much more important than control, it’s really important now, if we don’t have control, to make it easy to do the right thing.”

Design Principles

“I love design principles, and they have a lot of benefits,” said Craig. He highlighted just a couple of them:

1. “Indecision equals debt. The more decisions you put off, the more expensive they become. The longer you wait, the more expensive they become, and you start to build up a lot of debt. So having a solid set of design principles that everyone agrees on will dramatically reduce indecision debt.
2. “In the absence of having principles and insights about your users and your customers, you really just have opinions.” When you can’t make a decision, going to the HiPPO (Highest Paid Person’s Opinion) for a decision is not a great way to make decisions. “With principles and insights, you can make these more informed and more structured decisions and quiet that HiPPO.

“Lots of teams have design principles. Not all of them are effective. Some primary things that make them effective” include the following:

• prioritized—“They need to be prioritized.”
• distinct—“They need to be distinct from each other and unambiguous.”
• consumable—“They need to be highly consumable by everyone—not just the Design team, but the entire organization.”

Craig presented the Salesforce design principles shown in Figure 27: clarity, efficiency, consistency, and beauty. These principles were born out of the Lightning experience project. “At the time, [Lightning] was the largest design project ever undertaken at Salesforce,” related Craig. “We realized there was tremendous scrutiny around every single decision we would make.—both from executives and our peers. So we needed to have some principles to ground those decisions.”

“The order in which these [principles] appear is extremely important,” said Craig. “They are clarity, efficiency, consistency, and beauty, in that order. And each one below clarity is in support of that top goal. So these are in priority order. They’re all quite distinct from each other, and this is really important because what you want to do is pit them against each other. Which one is going to win between clarity and consistency? It’s going to be clarity every time. So that really drives decisions. There are only four principles, and they can all be described with a single word. That means they are extremely portable and memorable, which is really important when you want this to grow outside your Design team.

“If your design principles don’t drive decisions, rework them until they do.”

Platforms

Platforms are really important when dealing with radical customization and scale. “When you’re designing for a platform, don’t think about the platform first,” advised Craig. “If you look at the most successful platforms in technology, they all started as apps. They all started with really concrete use cases, then generalized.” Craig shared this quotation:

“If you design for everyone, no one is satisfied.”—Kat Holmes, Principal Director of Inclusive Design at Microsoft

When designing for a platform, follow the guidance in Figure 28. “Think about where your feature fits inside the greater ecosystem,” suggested Craig. “Going beyond just the standard idea of edge cases, start thinking about what happens when someone customizes the user interface that I’m specifying? What happens when a field gets removed or someone makes it required or they change the order of the fields? Does this experience break?”

Design Systems

“Design systems and platforms really go hand in hand and are really important to each other,” said Craig. Then, he quoted Nathan Curtis, who had given a workshop on design systems at the conference.

“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap and backlog, serving an ecosystem.”—Nathan Curtis.

Craig noted that ecosystems “can actually also include your users. In the case where you’ve given your users control of the experience, they are part of your ecosystem in terms of design.”

He spoke briefly about the Lightning Design System, which started as an internal project “to ensure that the designs we were specifying were actually manifesting in the product.” Lightning consists of a combination of guidelines and the actual code that implements them. “We very quickly realized that [Lightning] serves our entire ecosystem—designers, engineers, partners, and customers alike. There is an entire team dedicated to maintaining this as a product. It is not a side project.

“At Airbnb, they’re doing great stuff around design systems,” said Craig, sharing a quotation from Alex Schleifer, VP of Design at Airbnb:

“We’re investing in code as a design tool. Moving closer to working with assets that don’t only include layout and design, but also logic and data. This helps bridge the gap between engineers and designers.”—Alex Schleifer

“They recently introduced the React.js Library, [which supports] bidirectional communication between code and Sketch, [the tool] most folks are working in. You can do all sorts of what-happens-when scenarios.”

Influence > Control

“This idea that influence is more important than control is a critical one because we’ve sort of lost control over the specific experience,” Craig acknowledged. “Make it easy to do the right thing. But don’t just make it a little bit easier. You need to make it a lot easier—at least ten times easier.”

“If you want to introduce a new concept or you want to get people to change their behavior, you need to create something that is at least ten times better than what they use today.”—Andy Grove, former, long-time CEO of Intel

Craig told about how Josh Clark introduced a design system at a major retailer, increasing productivity so they were able to build Web apps ten times faster with just one quarter of the team size. He said, “We’re talking about huge productivity gains, and when you have huge productivity gains like this, you really don’t have to do a lot of convincing.

“It’s really important to provide support to your entire ecosystem and that means publishing your design guidelines in your design system and making sure your code is accessible to the public.

“Model the desired output—the things that you want to see in the world.” Craig told us about a company called Kony that creates an enterprise application platform on which other companies can build applications. They provide starter solutions for specific industries that let you work within some kind of norm.

In Conclusion

“So we can adapt and change, enterprise design needs to become more resilient,” advised Craig. “We need it to bend without breaking. If we can apply some good design principles to make solid decisions and we can publish the work that we’re doing in the form of design systems and guidelines, we can help our users and our customers create great experiences themselves.”

Craig is an excellent speaker and put together a beautiful, highly pictorial presentation. This was one of the best sessions of the conference.

Afternoon of Day 1: Highlights from Conference Sessions

Sessions that took place in the afternoon of Day 1 of EUX 2017 focused on this theme:

Leading Teams That Execute—“Design leaders need to do more than hire, train, and mentor great craftspeople. They must get people to work together as an interdisciplinary team, bound by a shared vision of what a successful enterprise experience can be. We’ll explore how successful enterprise UX teams work to create, own, and execute their visions.” Phillip Hunter was the theme leader and led a discussion on topics relating to this theme.

Scaling the Human Center

Presenter: Gretchen Anderson

Gretchen Anderson, Head of Design at Pacific Gas and Electric, “the largest energy company in America,” is shown in Figure 29. The topic of her presentation was keeping it human at scale, as shown in MJ Broadbent’s sketchnote of her session in Figure 30.

The applications Gretchen’s team designs are for PG&E’s workforce—“the people who maintain, build, and operate the things that keep the lights on.” “For enterprise, bad product design can cause core business functions to fail. Delivery is a must. Failure is not an option.” cautioned Gretchen. “In the enterprise, everyone’s idea of good enough is not quite like your own. Being user centered can be at odds with business-outcome thinking. Envision the unimagined and it becomes more possible—then work backward from there.

“Design systems and pattern libraries, processes and playbooks are essential at scale, but they’re not going to guarantee success. They’re simply guard rails to keep you from going too far afield. There can be a natural inclination in the enterprise to lean very heavily on systems and processes.

“Quoting Greg Petroff, ‘Designers can be paranoid’—and I’d add to that precious. [Often, designers say], ‘Why don’t they invite me to the table? I don’t feel valued. Nobody’s listening to me.’ I think that stems from the paranoia. How do we make designers feel empowered while still delivering impact? Things that I’m finding useful to combat some of these challenges” include the following:

• “We’re human-centered designers, and we need to keep that part of our craft at the forefront—even at scale, even in the enterprise.
• “In the world of digital design, it can be very tempting to think that two designers, if given the same inputs, will arrive at the same output. [Designers] all have a style. The way you solve problems is unique, and that’s a great thing.

“We have our challenges:

• What’s good enough?
• We love our hierarchies and our analysis paralysis.
• Processes proliferate.
• Designers can start to feel isolated and a little paranoid.

“What do we do about that?

1. “Do pair design. When I say pair design, I don’t mean a senior designer and a junior designer—one kind of bossing the other around. For me, pair design is about two people who are different coming together as peers. Whether it’s a visual designer and an interaction designer. A content strategist and a product manager. The core [element] of pair design is two perspectives that get you to a great place. We’re better together, and we’re better different. Navigators versus drivers. One person generating ideas and the other person evaluating them. Diversity helps the designers to be happier, and it democratizes the critique, so it’s not always about the Creative Director.” Pair designers try a lot of different ideas and evaluate them quickly—challenging those ideas in real time—so they get to a great solution. They learn from one another.
2. “Lead through making. No one is going to invite you to the table. Invite yourself to the table. Do that by supplying actual things. To the bullet points, I offer storyboards. To the analysis, I offer prototypes. Invite yourself to the table by bringing actual deliverables. I’m constantly surprised at how good stories work. Stories are medicine for the enterprise. Prototyping is not about usability [or] evaluating the idea. It’s about exploring the idea [and] risk mitigation. Use that leading through making to keep your stakeholders and executives on their task: the so that I can part of the user stories. Ask, ‘What are you trying to enable from a business perspective? What is the outcome you’re trying to achieve?’”
3. Make your team “design operators—the people behind the systems, behind the pattern libraries. Don’t leave teams behind. Patterns and systems need ambassadors. Keep your design sprints focused on the big picture, the strategic vision, and keeping the thing coherent. Then, use patterns and refine the details during development sprints to get the microinteractions right. Deliver that work in a more consultative fashion, nor redlining and wireframing every little detail.
4. “Build strong relationships. What are those relationships that keep the paranoid designers feeling tied to the mothership—to keep them from feeling ostracized. These relationships need to be authentic [and] facilitated. Workshopping is a great way to [build community]. Your responsibility with your tech lead and your product owner—in that virtuous triangle—is to make sure the tech debt, the UX debt, or the feature debt is appropriate at any point in time. You need to be there representing the full picture with your counterparts. What’s the right MVP (Minimum Viable Product)? Facilitate that relationship that you have with your triangle and that your team has with the business by engaging them throughout the organization, not just your own team.

Gretchen concluded her talk by saying, “Think about the experience that others have with your team. Design the experience that others have with Design to be human, fun, and just a little bit magical. Design is a different way to solve problems.” Gretchen made some really important points, and I enjoyed her talk.

Customer-Centered Design Organizations

Presenter: Peter Merholz

Peter Merholz, shown in Figure 31, is VP of Design at Snagajob and gave a great talk on organization design. Since the publication of his book Org Design for Design Orgs, coauthored with Kristin Skinner, he’s spoken at many conferences, and I’ve heard him speak on this topic several times. Figure 32 shows MJ Broadbent’s sketchnote of his presentation.

“For me, execution is in service of the user,” said Peter, “ so how do we shape design organizations to deliver on that? When starting out [in this industry], I thought: ‘To deliver great experiences, I just need to get the design right. If I do my job as a designer, talk to users, understand them, create great designs, will get them out in the world, and all the experiences will be great. That is not true. I realized that I don’t just need to get the design right, I need to get the strategy right. If I engage with the strategic challenges the business is facing, help with the upfront decision-making, then use that to inform the design, then put those great designs out in the world, I’ll be delivering great user experiences. A lot of people go through this, and their organization is still delivering crap. What I came to realize is that, in order to deliver great user experiences, you need to get the organization right. You need to think about relationships within a Design team and relationships with other teams in order to great experiences out into the world.

“We often think that, in order to deliver quality design, we need to have the best people. While you need to have great people, it’s not enough to have great people. You need to create the space in which you can bring the best out of those great people.”

Organizational Models

Peter’s talk focused primarily on the organizational models for design teams shown in Figures 33–36. “The most common organizational model, where a lot of companies start when they first embrace design is the Centralized Internal Services Model, or a Shared Services Model, where you have a single Design team [and] designers [are assigned to] projects throughout the business. They do the work, then they come back and are sent out on something else. The team itself tends to be organized by function”—interaction design, visual design, and user research teams. Figure 33 shows the pros and cons of the Centralized Internal Services Model. “When I think about this model, I tend to think of designer as short-order cook. There’s no real room for innovation, creativity, trying new things, or pushing the boundaries. [This] is not anything we want to be part of. We’re not getting into this to simply execute on the most basic design practices and methods.”

“After having frustrations with the Centralized Internal Services Model, companies will often shift into a more Decentralized and Embedded Model, where everybody gets a designer. This is more of a program-based model, so instead of designers being shipped out on projects, they remain with the program for a length of time. You have a set of teams dedicated to [application] functions. You have your sacred three in a box of Design, Product Management, and Engineering. The way this model often works is you’ll have a level of leadership—a Design Lead, a Director of Product, and a Director of Engineering—overlooking a series of teams that are dedicated to each feature. Those teams often have a Designer, a Product Manager, and four to eight Engineers and are able to work fairly autonomously and solve the problems.

“This is a fairly typical model. This is how Spotify has organized. A lot of Silicon Valley companies have adopted a Decentralized Model. This model ends up having a lot of benefits—particularly in contrast to the Centralized Model.” Figure 34 shows the pros and cons of the Decentralized and Embedded Model. “So are you screwed either way? Centralized didn’t work. Decentralized didn’t work. A lot of companies just go back and forth and that isn’t good.”

“Think in terms of Design teams. Teams is an important concept that I don’t think gets enough recognition. Instead of having a series of unicorns working independently, expected to try to do everything on their own—instead of having [designers] embedded in [feature] teams—you pull them out into their own team that works across a set of contiguous feature teams. They’re working across a coherent experience. The Design Lead and Senior Designers maintain direct relationships with Product Management. You can engage in a spread of skills, so instead of everybody being a designer with roughly the same set of skills, you can now have, say, a Content Strategist on the team. You can have some designers that are more interaction focused, some designers that are more visually focused. It allows you to let people play to their strengths instead of requiring everyone to be equally skilled, [which] doesn’t work. It also allows these designers to go where the heat is. You can have one or two designers dedicated to [a feature that’s hot], then move on to something else when it’s hot. So you can load balance your design effort across this team, which helps deliver a more efficient use of folks.

“I refer to this model as a Centralized Partnership. As shown in Figure 35, the Design team itself is centralized. This team is typically part of a larger Design team that is centralized up to a single leader. But the Design organization is organized into a series of teams. The Partnership speaks to the commitment that this team has to the feature teams. The Senior Designers and the Design Lead remain committed to their Product Managers and Engineers that they have that partnership with. Figure 36 shows the benefits of a Centralized Partnership Model.

Design Teams

“Hire design leaders—Managers or Directors—that [you] can build teams around, as shown in Figure 37. Each of these teams has roughly four to seven people. If you have a Design team that’s more than seven people it’s probably too big. At that point, you should probably split it up. But key to the success of teams is team leadership, having that strong Team Lead that allows a team to do its best work. Finding these people is really hard because you need them to do three things:

1. They need to be able to manage down, get the most out of the team, create a space where they’re really engaging them in their creativity.
2. They need to be able to manage across, own those relationships with Product Managers and Engineers.
3. They need to be able to manage up. They need to have the communication and persuasion skills to engage with stakeholders and executives.

Focus design on specific, end-to-end customer experiences. “We need to organize our teams around customers and their journeys. That is what we need to optimize for.

Quality Standards

“Once you have the team in place, how do you make sure they’re doing the right work? When we talk about design quality, we don’t have a really good, shared understanding. One of the challenges that I think enterprise design teams probably face more than most is being able to articulate what quality means to them and make that clear to others. When you don’t
have a strong way of articulating quality, it can paralyze the team because they don’t know which direction to go or how to deliver. When you want your teams to be bold, you must [establish and uphold] an explicit set of quality standards,” as outlined in Figure 38.

“All of you are going to be asked to do more work than your team has the capacity to deliver on. So it is important for design leaders to be comfortable with the word no. To push back and say, ‘We’re not going to do that. I’m not going to spread my team so thin that we cannot deliver quality. I’m going to focus my team’s efforts on those things that are important, and we’re going to do them really well, and you’re going to see what it takes to deliver great work, and you’re going to see the impact of that great work, and then you’re going to give me the resources I need so I can deliver quality across a broader part of the organization.

“Process is not a proxy for quality. One of the challenges you see in enterprises is that they end up relying so much on process and, if you follow the process, it’s fine. You abdicate the quality question because you did it the way you’ve agreed it should be done.”

Executing Against All Odds

Presenter: Kim Lenox

The final presentation of the day was by Kim Lenox, Director of Product Design at LinkedIn, who is shown in Figure 39.

In speaking about executing against all odds, Kim focused on five lessons she wishes she had learned before becoming a design leader, as follows and as shown in Figure 40:

1. If you want to change the way of being, you have to change the way of doing.
2. Empathy breeds alignment and understanding.
3. From service to scrum.
4. Living life through fear is surviving.
5. Living life with joy and optimism is thriving.

Figure 40 shows MJ Broadbent’s sketchnote of Kim’s talk.

Enterprise UX Storytelling Sessions

Led by: Dan Willis

The afternoon closed with some enterprise UX storytelling. Dan Willis moderated. Figure 42 shows MJ Broadbent’s sketchnotes of the EUX storytelling sessions.

I especially enjoyed Lada Gorlenko’s dramatic delivery of her advice to young researchers—stakeholders are as important as users—and Audrey Crane’s story about the vulnerability she experienced as a nursing mother in the workplace.

Conclusion

Despite the venue’s experiencing some audio-visual issues in the morning, Day 1 of EUX 2017 delivered great value to attendees. In Part 3 of my review of EUX 2017, I’ll cover highlights of Day 2 of the conference.

EUX is the conference for UX professionals, product managers, developers, marketers, and other decision makers to come together to share their learnings about how to deliver great enterprise software experiences to their customers. If you create enterprise-software systems, I highly recommend that you attend this conference. 

Discount for UXmatters Readers—To attend EUX 2018, register using the discount code UXMATTERS and you’ll get 15% off the price of your conference ticket.