Dani Nordin on Transitioning a Team from Comps to Interactive Prototypes

Introduction

Change is difficult, but not changing is fatal. So goes the anthem for many a business leader looking to innovate and stay ahead of the curve. Dani Nordin, UX Director at Pegasystems and author of several O’Reilly design books, shares her recent experience in introducing change at one of the world’s most venerable corporate brands, the Harvard Business Review.

Her mission: transition a design team from static mockups for large screens to interactive mobile-first prototypes with Axure. Easier said than done, it turns out. In this case study, Dani candidly outlines her missteps and successes, offering hard-won lessons and insights from her experience.

The Project

During the fall of 2014, HBR.org launched a major responsive redesign after months of intense effort. I was hired shortly after launch to help the business “live into” the desire to take a more human-centered approach to its design and development process.

Being able to create interactive prototypes gave developers and other stakeholders more immediate transparency into the intended behavior of our designs, while also providing a single link—through the Axure Share prototype—that could remain constant throughout the project.

During my first several weeks, I noticed a disconnect between the way the design team created documentation for the development team and the way the development team built things. In order to iterate designs more efficiently using their established workflow, static comps were created in Photoshop or Illustrator. Unfortunately, short timelines and an impression among the design team that stakeholders couldn’t “think in mobile” meant that the majority of design work was focused on the larger screen experience and presented in static comps. As a result, the front-end team implementing the designs was left to interpret how the designs would adapt to smaller screens. The resulting experience was inconsistent across devices, and members across the team were frustrated by the communication breakdowns that resulted.

As I reviewed our current process and made recommendations for how to incorporate UX into our workflow, one of my key recommendations was to shift from static comps to interactive, adaptive Axure prototypes. The resulting work would allow us to think about how our designs would adapt to different devices and screen sizes, rather than treating “desktop” and “mobile” as distinct environments. In addition, being able to create interactive prototypes gave developers and other stakeholders more immediate transparency into the intended behavior of our designs, while also providing a single link—through the Axure Share prototype—that could remain constant throughout the project, rather than having to continually upload new versions of a static document.

Meet the Team

As Senior UX Designer and resident Axure expert, I led the charge in bringing Axure into the design team. My mission included getting our two interactive designers up to speed on using use Axure, and helping the team strategize how to incorporate prototyping into our workflow without losing the momentum of projects. Our respective bosses provided support and mentoring through the journey.

Getting Started

There were two big steps involved in bringing Axure to HBR. The first step was getting leadership in Design and Product on board with the transition. By showing the advantages of prototypes, both in clarity and in responsiveness, we were able to get sufficient buy-in to send the designers to training on how to use the tool.

The second big step was to show the Design team how prototypes could be used on a project. We did this for two big projects: the first was a redesign of the Webinar section of the website, which focused initially on the large-screen experience with no Adaptive Views. The second and most significant project was a redesign of My Library, a set of internal features that readers get when they create an account on the site. This was our first experience with truly adaptive prototypes, Team Projects, and attempting to bring a higher level of visual fidelity to our prototypes.

First Speed Bump

In both projects, the tech team and stakeholders saw an immediate benefit to the interactive prototypes. Iteration was fast, and didn’t require uploading new screenshots; the intended behavior was easier to see in a prototype than in a static comp.

In both projects, the tech team and stakeholders saw an immediate benefit to the interactive prototypes. Iteration was fast, and didn’t require uploading new screenshots; the intended behavior was easier to see in a prototype than in a static comp.

The Design team, however, was not sold on the concept. While the prototypes were intended as medium-fidelity documentation that could quickly be implemented using existing design patterns, the Design team needed to see a higher level of visual fidelity to feel confident in the design direction. As a result, they created separate, static comps to represent their intended “final” design and added them to the tickets for implementation.

This duplication of effort was particularly problematic during the redesign of My Library, where entire sections of functionality were created as a static, annotated PDF by the Design team, independent of the prototype, while the prototype showed an entirely different interaction pattern. This caused confusion and frustration in the development team, who couldn’t tell what they should be referencing for what to build. It also caused some internal conflict between the Design and Product/UX teams, who struggled to determine who “owned” the prototyping and UX process.

Second & Third Speed Bumps

As we reflected on the challenges of the My Library project, we uncovered some important frustrations among the members of the team. Designers liked working with Axure, but found the learning curve frustrating. As a result, they hesitated to think of it as a design tool, and felt that the additional static comps were needed to ensure the level of visual fidelity they were going for. This frustrated Product/UX, who felt that Axure could readily help the design team achieve their visual fidelity goals, and were concerned that continuing to duplicate efforts would derail our goal to make interactive prototyping a key part of our UX process.

Further complicating matters was a growing tension between the lead designer and myself. Throughout the redesign of HBR.org, the Lead Digital Designer served as the team’s UX designer; my arrival at the company signaled a big change in her role, and my involvement in changing the design of the site, something that had long been under Design’s control, was deeply uncomfortable. By not involving her and the other interactive designer in the process earlier, I had inadvertently made things much worse, making it seem that I didn’t value the role that the Design team played in improving the website.

Outcome

After several weeks of discussion and a bit of trial and error, we’ve come a long way towards a primarily Axure-based workflow. As the designers’ experience with Axure has grown, they’ve gotten more confident in creating higher-fidelity prototypes that can serve as primary design documentation for stakeholders and the tech team. For a redesign of our primary navigation, the designers did “sketches” of the intended design in Illustrator, and worked together to put those designs into Axure—at full visual fidelity—for testing and documentation. For our latest project, an upgrade to the video experience on the site, the designers are working together in Axure from start to finish, iterating from medium-to-high fidelity as feedback is collected. Meanwhile, I’ve shifted my role to one that is focused more on advising and guiding the UX, providing workflows and design research to support the Design team’s decision-making.

As the process continues to evolve, the team is starting to incorporate a mobile-first approach earlier in the design process, and to more effectively use annotations to support the developers as they implement designs. The Design team is also actively working with the tech team to shift their expectations away from static comps towards interactive prototypes, as a way to make the process more efficient. The effort to move towards an Axure-based workflow has paid significant dividends in the improvement to overall design and interaction within the site. During the redesign of the navigation, the Design team was able to envision and get stakeholder buy-in on the complete experience, rather than asking them to imagine how a design would adapt to different screen sizes. For key interactions within My Library, we were able to demonstrate complete interactions for the tech team, helping them understand intended behavior as well as visual design.

Lessons Learned

Looking back on this experience, there were three major takeaways:

People build up expertise with a particular toolkit over time, and getting them to switch to something else is disruptive and uncomfortable. Being empathetic to what your team members are going through, and providing support and coaching during their learning process, is essential for helping them make the transition.

Learn and build on each other’s strengths. Some of my biggest mistakes during this process came from not taking more time to appreciate Design’s role and mission in making the site better. Once we were able to understand each other better, I leaned back a bit and let them take on more of the prototyping work, while advising on interaction and user behavior.

Remember that it’s a process. When working in an Agile environment, it’s easy to get caught up in “fast, fast, iterate, fast!” But learning a new tool, and a new way of working, takes time, and generally involves a lot of bumps in the road. Taking time now and again to reflect on how you’ve progressed goes a long way towards making things stick in the long run.

About Dani Nordin

During her 10 months as Senior UX Designer at Harvard Business Review, Dani Nordin helped introduce key user-centered design practices to the organization, including usability testing, shared design principles, Axure prototyping and interaction design, and cross-functional collaboration between UX, Design and Front-End Development. Her tenure saw significant improvements to the usability and usefulness of HBR.org’s account features, navigation and key interaction flows such as registration and checkout.

Dani is now the Director of UX in the Digital Engagement Group at Pegasystems, supporting both Pega.com and the Pega Developer Network. She is the author of several books for O’Reilly, including Drupal for Designers, Planning and Managing Drupal Projects, and Drupal Development Tricks for Designers. She is also the author and presenter of two O’Reilly video series, Learning UX Fundamentals (2015) and Designing with Empathy (forthcoming in 2016).