Wrangling Complexity: Collaborating and Delivering Design on Enterprise Projects
If you are a designer and have ever worked in the enterprise space, you probably know that enterprise design is a different animal altogether. Convoluted bureaucracies, highly-specialized user roles, and complex business requirements are some of the typical hallmarks of enterprise UX projects. Here at Blink, we spend much of our time working on the front lines of these types of projects. Here are some things we have learned about navigating complexity, collaborating with stakeholders, and handing design off to development teams.
Let me set the stage a bit. For the past 14 months we have been designing a new loan origination platform for a large lending company to replace their outdated, clunky legacy system. This is an enterprise project through-and-through: internal teams defining and creating custom tools for other internal employees to use.
Enter: complexity. The new platform would need to support customized views for several different job roles and we were working with no fewer than 10 business owners to define requirements for various parts of the system. Our client was fully committed to rapidly building their new origination platform and was prepared to dedicate multiple development teams to the work.
With only two designers working on the project, we knew we would need to establish some key strategies at the beginning of the project to manage the complexity that was surely going to arise. Specifically, we wanted to kick the project off knowing we had identified the following:
- How we would discuss complex business requirements with stakeholders.
- How to present and collaborate on designs with multiple stakeholders and analysts, especially when we were three time zones apart.
- The most efficient and useful method for delivering designs to multiple development teams.
Treat requirements like conversations, not commandments
Knowing we would be designing an internal application for the lending industry, we expected to encounter lots of messy regulatory requirements and complex financial jargon. Even with this expectation, we were still a bit astonished by the amount of discussion needed for even the smallest of business requirements. A seemingly simple feature request could rapidly become a dozen-person email thread as various business owners chimed in with their own tribal knowledge (and as designers sought clarification about the various acronyms being thrown around).
But it’s important to note that these conversations were a good thing – as designers, we needed these detailed discussions to happen so we could fully understand the scope and implications of what we were designing. As we got used to the complexity of these conversations and learned the internal jargon of the organization, we were able to be more pointed and efficient in our discussions thanks to our maturing “fluency” in the industry language.
Ditch your email for detailed requirements discussions
Having detailed conversations about requirements is all well and good. However, reply all only gets you so far before things get messy and difficult to track. As a project team, we all decided that moving these detailed, in-the-weeds discussions to a venue other than email would be much more productive, as it would allow us to cleanly separate our discussions and clearly track their progress, ownership, and resolutions.
After reviewing several tools out there such as Trello and JIRA, we decided to use Asana. This was purely a matter of preference and availability for our project, but I can confidently state that Asana was a saving grace for a project of this size and complexity. The speed with which we got the entire project team (several dozen people) up and running on Asana, and the ease of onboarding, made all the difference. Getting our conversations out of email and into a tool built for these discussions helped us prioritize tasks and assign ownership, as we placed due dates on requirements discussions and weren’t shy about assigning questions or tasks to the right project team member.
Everyone likes pictures
When a one-sentence requirement can mean five things to five different stakeholders and designers, getting sketches or wireframes in front of everyone as soon as possible can rapidly clarify a conversation. In past projects I have seen design passed around in PDFs, as images in emails, or versioned in a shared folder. These methods can work for some smaller projects, but on a large, complex enterprise project with role-based views and several dozen screens or more, designs may be updated daily as new stakeholders chime in. These methods of sharing design are also not conducive to discussion or collaboration, unless you want to revert back to the reply all problem I mentioned previously.
For this project, we went all in with InVision. If you are a designer, InVision is probably nothing new to you. Having one place to go to for the latest and greatest design, combined with commenting, easily shareable links, and quickly viewable versioning made InVision critical in our design process for this messy project. Our designers included their annotations and the occasional clickable element right within InVision, allowing any stakeholder to pop in to the wireframes and quickly understand the design being proposed. We also made it a habit to drop InVision links right into Asana tasks when we sensed a conversation veering toward misunderstanding or ambiguity, quickly bringing everyone onto the same page when we could all look at the same thing. It’s a cliché, but a picture really is worth 1,000 words.
No more redlines
Historically one of the most time-consuming parts of a design project is redlining the design files for delivery to development teams. If there were a large number of unique layouts and screens in a project, this process could take weeks of a designer’s time – valuable time that would be better spent on other things (like complex, messy discussions about requirements!).
Around the time our project got up and running, our design team at Blink had starting tinkering with a relatively new tool called Zeplin (there are a few others out there now as well, such as InVision’s Inspect feature and Avocode). This tool allows a designer to export their Sketch or Photoshop file and redlines are automatically added, making them viewable in a browser-based web app. That may sound simple, but the time savings is enormous. At last count, we had nearly 200 screens uploaded to Zeplin for this project. If a designer had spent the time redlining even half of those, I shudder to think about how far behind we may have lagged.
The other nice aspect of using a tool like Zeplin is that these screens can become the new “source of truth” for everyone on the project team. So, as designs progress from sketches, to wireframes, and finally to Zeplin, we are able to ensure all stakeholders are looking at the latest and greatest design that has been delivered. Zeplin also allowed us to support delivery of design to six development teams concurrently, as we uploaded style guides and pages as soon as they were complete.
One word of caution about using these types of tools: in the old days, when designers would add redlines by hand, we could fib – pixel perfection wasn’t necessary. With a tool like Zeplin, however, a developer can inspect the pixel dimensions and padding between just about everything you design, so either communicate some broad rules about dimensions to your developers and don’t worry about pixel perfection, or spend your time nudging everything just right.
Embrace the challenge (and prepare accordingly)
Complexity and messiness are inherent in just about any enterprise UX project. But if you can find ways to manage the process challenges so you can focus on design challenges, UX projects in the enterprise space can be extremely rewarding. Identifying effective ways to discuss and track requirements, collaborate on designs, and deliver exactly what is needed are a few of the key steps you can take up front that will reward you in speed and efficiency throughout your project.
Tristan is a proud member of the interaction design crew at Blink. In his off time he can be found sipping a cortado at Caffé Fiore in Queen Anne or taste-testing local IPAs in Fremont & Ballard.