DesignOps: UX-Driven System Architecture

Building foundational models that drive a great user experience

System infrastructures built to drive a customer’s journey are just as critical to delivering best-in-class experiences as the interactions surfaced to users in the front-end. Creating synergy between (UX) User Experience and [deep] DevOps can maximize the design of the end-user journey, as well as help streamline feature development, avoid missed opportunities, and minimize tech debt in the product development lifecycle.

Is UX really UI? 

Despite the general consensus that user experience encompass all elements of an end-user's journey, UX Designers are usually positioned to focus primarily on the surface-level details of what end-users see in a product’s interface—layout, color, imagery, and interactive elements like form fields and navigation. Mature UX models maintain deeper integrations with DevOps, adopting Agile and Lean methodologies to build timely, viable solutions, while mitigating tech debt, and level-setting expectations for design, function, and form. While the gains from these integrations are significant, many UX teams still have little access (or input) into a critical component of the well-rounded user experience—the foundational logic. 

Architectural models define the reasoning behind the structure and behavior of data—the foundation that supports how data is gathered, moved, and viewed throughout the product. A flexible, scalable architecture grasps the intentionality of the product, combining the functionality and scope of the software elements it supports and the relations between them. Most approaches and methodologies begin with the straightforward question—"What is the intended use of the architecture?” It’s in the process of finding that answer that we uncover a critical opportunity to build foundational models that drive a great user experience.

Like systems architects, UX Design practitioners (originally called Information Architects), are required to synthesize abstract and complex concepts into a chain of intentions that define interactions and flows between users, devices, functions, screens, and data. Although we are often only tasked with defining surface-level, taxonomy-driven details, such as navigation and sitemaps, a knowledgeable information architect could do a lot more. By combining the natural ability to analyze and synthesize information with the ability to communicate a holistic end-to-end experience (the intended outcome of the data)–well, that’s where the magic begins. 

Let me draw one example of how this could play out—

Sample Scenario: Clarity in the Middleware Conundrum

As organizations jump on the cloud bandwagon to improve everything from operational efficiency to business agility, DevOps is often tasked with creating a seamless ecosystem that integrates legacy, monolithic systems with multicloud environments. For this example, we’ll explore how Company A and Company B tackled their middleware projects. Both large, national, (and fictitious) companies, each project team is tasked with developing the necessary integration layers for a series of on-premise legacy apps, multicloud systems, and variety of deployment environments. The mission-critical information contained in these systems is generated and rendered in a variety of ways, such as C-level corporate dashboards, administrative payroll, and HR portals, in-field personnel via proprietary mobile apps, call center agents, and customer self-service account portals.

Company A: To devise their enterprise integration strategy, Company A gathers a core group of stakeholders (product owners, business analysts, architecture, development, and project management) to discuss the project. The business team rattles through their requirements, such as increased productivity for employees by reducing the number of systems they were required to touch, and reducing call center hits by offering more self-service capabilities for customers and more. The discussion quickly becomes highly technical and tactical, focusing primarily on the tech teams sharing in-depth systems knowledge, identifying and defining the constructs needed (such as identity, authentication, authorization, and directories), as well as governance, policy, and legal constraints.

The team ends their first meeting by setting up a variety of follow-up meetings to discuss implementation timelines and roadmaps. However, there is no clear consensus on what the enterprise integration platform is intended to accomplish, other than “getting systems to talk to each other.” Without determining the business logic, their ad hoc approach focuses solely on short-term integration needs, rather than long-term solution effectiveness. 

Many months (and hundreds of meetings) later, Company A managed to connect their existing systems. Although the services platform allowed systems to finally “talk to one another,” these layers of middleware remained disconnected from any business logic. The core team connected each system without optimizing the business’s’ touchpoints within the ecosystem, and thus, ended-up backed into a corner on many of the approaches taken. The architecture was left with chronic problems, unable to support business agility, provide ongoing flexibility, and lacking the services needed to manage business logic. They eventually created a middleware—for their middleware.

Company B: Alternatively, Company B takes a different approach. They start with their core stakeholder group (product owners, business analysts, architecture, development, project management) but this team also includes a UX Strategist. As with Company A, the business team hopes the integration will increase productivity for employees by reducing the amount of systems users are required to touch. However, Company B also wants to extend functionality to their remote mobile workforce, as well as reduce call center hits by offering more self-service capabilities for their customers.

Company B’s architects know which systems hold which kind of data but are unclear how this data should be used to satisfy these businesses requirements. Then, the UX Strategist begins to ask the kinds of questions that paint a picture of how the end-game involves their users. How would it improve the customer/end-user’s journey? What would they see? What would they be able to do differently?

It becomes clear to each stakeholder that they each have a different expectation of what could be accomplished and delivered. Thus, the teams decide to focus first on defining the scope and business logic they are trying to target—meaning, the objectives that the enterprise integration platform is intended to accomplish. They start by developing an inventory of the teams, customers, products, and systems involved and then plan out a research and scope phase. Then, the UX team takes swift action.

[cue the action-themed background music]

Working with a variety of stakeholders, to conduct a variety of research activities, such as site visits, interviews, analytics, and data dumps. Their activities focus specifically on answering three critical details for the core team:

1. What is the current state of affairs (and all of its challenges)?
2. How is the platform intended to be used?
3. What is the ideal customer/end-user journey, including priorities?

During this phase, the UX team identifies a myriad of broken and ill-defined business processes that have spawned a stream of workarounds for users. Some more critical than others, these issues can cause a major headache for any business. For example, they discover a common practice of exporting customer’s Personally Identifiable Information (PII) to third-party applications for management and sharing via email. They uncover six additional and unnecessary third-party applications—apps that in essence, perform identical functions, each within their own vacuum. The UX team also reveals several monolithic legacy systems that house large stores of outdated information from an old company acquisition (only 10% of the data was still applicable to the current business). Finally, the team pinpoints critical gaps in the data needed to connect account management and customer self-service records with technician data from the field.

In the end, the UX team’s findings help level-set business expectations by raising awareness of just how much employee productivity is being impacted by disconnected and inefficient business processes, as opposed to technology-driven issues. The core team was also able to begin defining what the business logic looks like and how the middleware should support it. Finally, the team was able to efficiently prioritize the roadmap because the UX Team’s visualization of the critical business areas and processes supported by the integration.

A Strong UX Competency

While the UX discipline isn’t intended to define how architectural systems function (API’s, frameworks, data consistency, messaging, etc.), a strong DesignOps model should contain a robust UX Strategy-driven competency that understands enough of how the front and back-end systems holistically enable the end-user journey. This competency can help stakeholders fine-tune the scope of a system by providing the right kind of context—what users will (and won’t) do with its information and features—as well as uncover additional opportunities and challenges for the foundation. The ownership of this information and how it impacts the roadmaps still lies with the various stakeholders involved. However, this type of analysis and knowledge sharing goes a long way towards curbing some of the tech debt that arises during the product development lifecycle—especially as business leaders and designers seek ways to continuously change and improve the end-user’s experience journey.

A Sampling of Artifacts

Although, there are many types of UX artifacts that can be flexed and molded for any use-case, here is an example of the types of research artifacts that could have been created by fictitious Company B’s UX Team:

• Site Visit Summaries - written summary of key findings from in-person visits to real users of the system. Statistically defined to represent a balanced sample of the targeted user groups, these visits are meant to capture an unfiltered view of the user’s real working environment, including systems used, tasks attempted/completed, challenges, priorities, and system workarounds. While these activities use protocols that ensure the information gathered is focused, driven, and easily comparable with other data, some qualitative, open-ended discussions are also encouraged to “uncover nuggets” about the challenges end-users have with applications, automation, and process.

• User Personas - not your mom's personas, these straightforward write-ups describe the types of real-world interactions users expect during their journey, as well as identifying their priorities and challenges—all, without the fluff.

• UX-Driven Architecture Diagram - A diagram that conveys how the system's applications and data should interact with users along their journey.

You can download a PDF of these artifacts or view them in SlideShare