3.5 Lean UX hacks to help you succeed in large organizations

Greg Nudelman is head of UX research at GE Digital Oil and Gas based in California, USA. Author of four UX books, Greg has over 21 years of experience in the industry under his belt. Before his talk at UX New Zealand 2017, Greg shares 3.5 Lean UX hacks for large organizations. You can reach him on Design Caffeine for more information about his work.

Not every UX strategy meets with instant success in complex organizations, especially at companies in a transition from traditional heavy industries, or those whose culture is dominated by engineering. The 3.5 Lean UX hacks described in this article are hands-on, practical strategies to help you make your design and research practice more collaborative and productive in a large organization, while also preserving your sanity.

1. Understand the goals of your audience

The key to success in a large organization is staying flexible: there just is no one “right way” to do something, and even the best Lean UX techniques do not universally apply to every case. Take sketching for example. While sketching is an essential technique and remains the cornerstone of a successful design practice, in a large company, sketching is far from being the most compelling way to communicate one’s vision to the larger team.

I recently attended a “weekly design review” (rescheduled so often that this meeting, in essence, became a “quarterly design review”) where one design lead presented a paper prototype. Although this UX Lead had undeniable enthusiasm for his idea, the executives had a tough time picturing what he was talking about, and ultimately punted on the concept as “needing more work.” Why? The managers were unfamiliar with the design space, pressed for time and forced to make the decision quickly, so they funded a different idea instead – the idea that another designer presented as a fancily animated prototype.

Now, under “traditional” Lean UX practice we try to match the fidelity of the deliverable to the stage of the project and avoid investing in overly elaborate deliverables too early in the process. Thus under the “traditional” Lean UX practice, such an animated proposal would have to be considered wasteful. However, understanding the goals of your audience could also mean understanding how to best communicate your design regardless of where you are in the design process. So at least in this case, and for this audience, the expense of making the elaborately animated prototype was justified because it helped the executives understand the idea and make the decision quickly.  Instead of sticking to “what’s right,” the key to success is to focus on what is most effective in your organization by understanding and internalizing the needs and goals of your audience.

2. Start with a design framework

Understanding the goals of your teammates sometimes means investing a bit more time into documentation. Many UX people mistakenly assume that “running Lean” (especially when mixed with Agile development processes) means minimal documentation. Unfortunately, what works great with a five-person on-site Tiger Team may not function nearly as well in a 70,000-person organization, with your team distributed all over the globe and among all possible time zones. 

Consider this example: I typically assign at least one of my UXers to a particular scrum team – this key person acts as an engineering liaison and is required to participate in daily engineering standups. However, I recently worked at a company where the overseas development team insisted on holding daily stand-ups at 2 a.m. in the morning our time (less unusual than you would be led to believe.) Even in cases like this, you have to be an effective communicator and an advocate for your design work. Which means that even in your absence, your design has to be self-documenting in a way that serves the goals of engineers, not your own. Because if the engineering team does not understand something, they will not wait until the next day to ask you. Instead, they will implement something of their own devising –  the page that will be almost, but not quite, entirely unlike the brilliant design you painstakingly worked on for over a month.

Often, the difference between success and failure to communicate your requirements is just 5% more communication, or rather a more considerate method of communication: the design framework.

The idea of a design framework is simple: as your design evolves, you must always refactor to maintain four or five pages of basics: navigation patterns, widget behaviors, a short content guide and a visual design guide. Together, in one place, accessible and communicated to all engineering team members (and not just development leads), these items represent your design framework. This framework is the law. While the UX team may change wireframes and flows several times a day, they should change the design framework only rarely and with great reluctance, and communicate the changes widely to the entire product team. If you add a new design pattern, style or widget, be sure to update the design framework – it always overrules and supersedes every other deliverable you make.

The design framework has additional benefits: in one development organization I worked at, we had no fewer than five design teams in five different time zones. Having a shared minimalistic framework allowed all of the design teams the freedom of independent operation while maintaining consistency in the design look and feel across the entire suite of products under rapid development by five disparate teams.  

A design framework should ideally be created in close collaboration with the engineering leads and architects and describe widget classes needed to implement various objects. That way, it quickly becomes an indispensable reference and a unifying force for the entire product team.

Many practitioners point to Google or Apple Human Interface Guidelines as an example of a design framework. Personally, I think that’s overkill for most organizations. Instead, try a simple plugin like Zeplin.io: it creates a self-describing visual framework of red lines, sizes, and styles directly from your Sketch 3 file, minimizing any additional work. At one of the companies I recently worked at, my team’s Zeplin.io design framework site became sought-after by other design teams who wanted to implement our new design framework in their own projects. So much so, that the design framework gained far more company-wide importance than the relatively minor project my team delivered.

It’s often helpful to include 5-10 sample pages (home, search results, form, modal window, etc.) as part of your framework. Just be sure to make those pages feel abstract using lorem ipsum in content and titles so that developers do not mistake these sample pages for your actual wireframes (which should never have lorem ipsum in them, for reasons I describe in my 4th book, “$1 Prototype”).

3. Align across the organization using the key use cases

With large distributed product teams, how do you ensure alignment between UX, Product, and Engineering (not to mention QA, Sales, Marketing, etc.)? Turns out, that the use cases, stated in a typical Agile parlance (“As a Persona X I can do Y so that I can get some benefit Z”) are an excellent tool for achieving such an alignment. I always try to start the design project with critical use cases stated in this manner, for instance: “as a first-time customer, I can complete my purchase without registering, so that I can check out quickly and avoid the hassle of having to create and remember my password.”  Once the Product Management confirms these use cases, the UX team ideally validates them through early field research and user interviews.

As your team’s design progresses, these use cases are re-worded directly as our “user tasks” for the UX design prototype we take directly into RITE (Rapid Iterative Testing and Evaluation). For example, the checkout task, as shown above, might become something like: “Now that you found what you want to buy, complete your purchase. Is there a way to do so without having to register for the site? PROBE: For what reason you may or may not want to check out without registering?”

While the UX team is refining the design, the development team is working in parallel, utilizing these same use cases as agile Epics to guide the overall development progress. These agile Epics are recorded in Rally, Jira or a similar agile management tool and fleshed out with additional workflows and design improvements, validated by Marketing and Sales to confirm market interest, and finally, prioritized and delivered in staged releases to become your MVP. All the while, the prototype you used for testing with your customers, also acts the key specification for the agile Epics. Team-wide alignment around a few key use cases means that there is no duplication of work while documentation remains minimal, always pointing to the latest user-validated design. But how do you juggle the needs of the various internal teams?

3.5. Maintain two (or more) prototypes running at the same time, with different time horizons

A capable UX team frequently occupies a highly strategic role at the organization in transition. Often, the management which is driving the organizational transformation uses UX as a sort of versatile “Swiss Army Knife”: a combination of a Sprint planning tool, Marketing instrument, even to help assist the Sales organization. In all of these departments, UX becomes a point of coordination – and an excellent way to demonstrate the value of UX to the enterprise. However, nothing comes for free. To paraphrase the famous saying, “with greater influence comes greater responsibility.” The same UX team has to now operate with a variety of different time horizons, balancing the need to show a vast product vision to Sales and Marketing, while delivering clear, actionable software specifications to the development team for the next Agile Sprint.

For this reason, I usually instruct my staff to keep two (or more) prototypes running at the same time, with different time horizons. For example, one such prototype can be a fancy affair with all of the pre-requisite animations, bells, and whistles running in Axure, which represents the greater vision for the product. The Product, Marketing, and Sales executives sometimes show this “vision prototype” to customers and partners. My team maintains this Axure behemoth side by side with a light-weight, flexible prototype running in InVision, which represents the next two or three Agile Sprints’ worth of work that will get us to the next milestone. I customarily create both prototypes from the same core Sketch 3 files while addressing the same use cases. The difference is in the quality of execution and the time horizon for the proposed designs.

At first glance, this idea looks wasteful, especially if our focus remains strictly on delivering the MVP. However, it would be a mistake to assume that the management is always seeking UX help solely to create an MVP. I’ve led the teams that create UX prototypes for a great variety of purposes: to inspire the troops, impress customers, close long-term deals that provide the capital for operations… even to help conclude merger and acquisition deals. Sometimes UX is thrust into a role that is much more strategic – embrace this! It’s a tremendous opportunity for the UX team to influence the direction of the company to take a more human, considerate and ultimately more powerful approach to product development, one that is more likely to lead to success for the company in the long term, while converting customers into life-long fans.

In closing…

There is no “right way” to do Lean UX. Although minimizing waste and maximizing efficiency is an admirable and righteous goal for any Lean UX practitioner, in larger organizations, what constitutes “waste” is often itself a subject of debate. Early in my consulting design practice, an MVP was what a five-person team could produce in three to four months. In contrast, I recently led a design team at a large company where an MVP was a product of an 80-person development team working for the entire year!

Success in complex organizations requires UX leaders to possess uncommon flexibility and a collaborative spirit that embodies the practice of Lean UX. UX techniques and deliverables are not the goals in and of themselves: they are merely a way to create a compelling vision, and then get everyone to work together aligned around the larger organizational goals. Remember to stay flexible and focus on these company goals, while looking for ways to leverage the incredible amount of execution muscle, expertise, and relationships that exist within a large organization. Good luck!

Want to hear more? Come to UX New Zealand!

If you’d like to hear what Greg has to say about lean UX, plus a bunch of other cool UX-related talks, head along to UX New Zealand 2017 hosted by Optimal Workshop. The conference runs from 11-13 October including a day of fantastic workshops, and you can get your tickets here. Got a burning question for Greg about Lean UX? You can Tweet him here: @designcaffeine