By
Tristan Plank
Our best advice for enterprise design projects
If you're 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 user experience (UX) projects.
Here at Blink, we spend much of our time using our UX skills to work on the front lines of these types of projects. Here are some things we have learned about navigating the challenges of enterprise products, including complexity, collaborating with stakeholders, meeting users’ expectations, and handing design off to development teams.
What are the benefits of great enterprise UX design?
Performing enterprise UX research at the beginning of these projects gives us a better understanding of the end-users — namely, the company's employees — and their needs and pain points. This data allows us to help enterprises develop software that achieves the following:
- Boost productivity and revenue: Good UX saves users time by making applications easier to use. When employees can spend less of the workday making unnecessary clicks and puzzling through user manuals, the organization becomes more profitable.
- Streamline data processing: Effective enterprise UX works with users rather than against them, creating ways for employees to understand and process organizational data more quickly and efficiently. As a result, they're better equipped to make informed business decisions and avoid potential mistakes.
- Facilitate smoother internal interactions: Simplifying communication and cooperation between employees is more important than ever due to the popularity of remote work. Great UX finds a way to use employees' natural communication behaviors to remove digital barriers for efficient teamwork.
One of our recent projects is a great example of how we overcome the complexities of enterprise UX research and design. Read on to learn how we did it.
The challenge
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 its outdated, clunky legacy system. This endeavor is a true enterprise project with internal teams defining and creating custom tools and developing the user interfaces other internal employees will use.
Part of UX for enterprise applications involves developing products that address common pain points for specialized users with specific domain knowledge.
Enter complexity. The new platform would need to support customized views for several different job roles, and we were working with at least 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 UX 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 off product design knowing we had identified the following:
- How we would hold foundational research sessions to discuss complex business requirements with stakeholders and collect information.
- How the UX design team would present and collaborate on designs with multiple stakeholders and analysts, especially when we were in three time zones.
- 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. We see this issue in many enterprise tools, but we were still a bit astonished by the amount of discussion needed for even the smallest of business requirements.
One seemingly simple feature request could rapidly become a dozen-person email thread as various business owners chimed in with their own tribal knowledge about how the business software should look — and as designers and developers sought clarification about the various acronyms being thrown around.
But these conversations were a good thing. As enterprise UX designers, we needed these detailed discussions to happen so we could fully understand the scope and implications of what we were designing. With this understanding, we can more accurately create an optimal user experience.
As we got used to the complexity of these conversations and learned the organization's internal jargon, 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. Input from enterprise users is incredibly valuable, but making sense of all the insights and information from stakeholders and users needs an organizational system beyond email.
As a team, we all decided to move these detailed, in-the-weeds discussions to a venue that allowed us to cleanly separate discussions and clearly track their progress, ownership, and resolutions. Product development would move much more smoothly with optimized user research.
After reviewing several tools out there, such as Trello and JIRA, we decided to use Asana. Asana is a web and mobile design system that helps teams, including UX designers like us, organize and manage product development. This choice ultimately came down to preference and availability for our project, but I can confidently state that Asana was a saving grace for such a large, complex project.
The speed with which we got the entire project team up and running on Asana was astounding. Our design team consisted of several dozen people in diverse roles, including an array of visual designers and developers who worked on everything from information architecture to product management. The ease of onboarding and availability of design resources made all the difference in making Asana a powerful prototyping tool.
Getting our conversations out of email and into a tool built for these discussions helped us move forward strategically. We could prioritize tasks and assign ownership, as we placed due dates on requirements and discussions and weren’t shy about assigning questions or tasks to the right project team member. By minimizing issues of clarity, we could keep the project moving forward despite many, many inputs.
Everyone likes pictures
It's a cliché, but a picture really is worth 1,000 words.
When one sentence can mean five things to five different stakeholders and product designers, providing everyone with sketches or wireframes can rapidly clarify a conversation. In past projects, I have seen attempts at collaborative graphic design passed around in PDFs, as images in emails, or versioned in a shared folder. These methods can work for some smaller projects, but a large, complex enterprise application can have more involved aspects, such as:
- Multiple role-based views
- Unique user interfaces (UI)
- Several dozen screens or more
That means that 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. To address these issues, you need to implement some type of design collaboration tool that can keep everyone connected.
We used a web prototyping service called InVision for this project. If you are a UX designer, InVision is probably nothing new to you. This interactive, collaborative prototyping software offers wireframe tools, UI design elements, and other resources for product and front-end development. 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 into the wireframes and quickly understand the design being proposed. From UI kits to mobile app development and other aspects of the development processes, InVision helped us make things clearer and communicate more effectively.
We also made it a habit to drop InVision links right into Asana tasks when we sensed a conversation veering toward misunderstanding or ambiguity, which quickly brought everyone back onto the same page.
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, as there often are in enterprise products, this process could take weeks of an experienced designer’s time — valuable time that would be better spent on other things (such as complex, messy discussions about requirements!).
Around the time our project got up and running, our design team at Blink had started tinkering with a relatively new tool called Zeplin. There are a few other similar options 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 automatically add redlines, making them viewable in a browser-based web app.
It offered us two significant benefits:
- Time savings: At the 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.
- Consistency: The other nice aspect of using a tool such as Zeplin is that these screens can become the new “source of truth” for everyone on the design team. So, as the design process moves from sketches to wireframes and finally to Zeplin, we can ensure all stakeholders are looking at the latest version. Zeplin also allowed us to support design delivery 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 UX designers would add redlines by hand, we could fib — pixel perfection wasn’t necessary at this stage of the UX process. With a tool such as 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) with Blink
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 enterprise applications can be extremely rewarding.
And that's what we do at Blink. We help our clients identify effective ways to discuss and track requirements, collaborate on designs, and deliver exactly what is needed so they can improve speed and efficiency throughout your project.
If you're starting your enterprise UX strategy journey, we're here to help. Reach out to us online today for more information about our UX services.