Testing Complex Enterprise Software with Matt Meeks | Episode #41

Matt Meeks began as a graphic designer more than 30 years before this conversation, working on corporate identities, marketing materials, websites, trade shows, and exhibits. Designing physical spaces and digital kiosks drew him toward experience design. Work at an internet startup and later in his own company deepened that interest, and in 2013 he returned to the corporate world as a full-time UX designer.

He is especially drawn to enterprise software because the use cases and systems are complex. At Jitterbit, an integration platform as a service, that complexity includes connecting software products, transforming data between them, and supporting configurable workflows. Matt explains how interactive prototypes, candid critique, and early testing help a team address complexity before expensive platform work reaches production.

What you'll learn

• How graphic design and storytelling skills transfer into enterprise UX

• Why small interaction changes can alter a user's understanding of complex software

• How product, UX, engineering, and customer-facing specialists contribute to critique

• Why teams should start simply, test early, and expose disagreement before delivery

• How to stop researching once there is enough understanding to begin designing

Prototype the behavior, not only the screen

At Jitterbit, a feature generally starts with the product manager. Product, UX, and engineering refine the requirements until they share a workable understanding. Matt then turns the requirements into wireframes or prototypes, choosing low or high fidelity according to the project's scope.

He uses UXPin to create interactive prototypes that behave more like the actual application. This matters in enterprise products because even a minor change in interaction can either clarify or obstruct a complicated workflow. A static screen may look convincing while hiding the exact point where a user will not know what to click, what changed, or how one step affects the next.

The team reviews product designs in a weekly meeting that includes engineering, the product management group, and product leadership. Matt walks participants through the prototype, invites direct opinions, and uses the discussion to identify concerns and possible changes. Sales engineers and professional-services colleagues provide another valuable perspective because they use the product on customers' behalf. Customer feedback extends the review beyond internal expertise.

Test early within enterprise constraints

Enterprise testing carries practical limitations. Security can prevent a team from letting customers use unfinished software, important workflows may require a login, and a prototype may not be intuitive without the context of the full system. Matt tries to get as close to real behavior as the constraints allow.

He can send an interactive prototype to an existing customer or internal stakeholder, explain how clickable areas are revealed, and ask the person to complete a task. Watching the attempt shows where the participant gets stuck, what is confusing, and whether important functions can be discovered. Matt takes extensive notes, often records the session, and shares the evidence with the broader team.

His rule is to start simple, test early and often, and move quickly toward failure. Finding confusion in a prototype is useful because the team can iterate before investing in production code. Waiting for a complete design makes every newly discovered problem more expensive.

Matt applies the same principle to stakeholder conflict. Smart colleagues often hold strong opinions, and several perspectives may each be correct in part. Bringing those opinions forward early helps the team investigate the underlying tradeoffs rather than carrying hidden disagreement into implementation.

Balance depth with forward motion

One of Matt's hardest tasks is uncovering the full depth of requirements. Complex platform behavior may take several people to interpret. The desired user experience also has to be balanced against the cost of changing platform code, alongside business and marketing needs.

That environment amplifies a tendency Matt recognizes in himself: he likes to understand a problem deeply and can feel unable to design until the understanding is complete. Thoroughness is valuable, but it can become a form of procrastination around the blank canvas. His improvement is learning to notice when he has enough knowledge to begin.

For enterprise teams, that is a practical boundary. Do enough discovery to make the first prototype meaningful, then use the prototype to learn what additional detail matters. Research and design become an alternating cycle rather than two phases separated by an impossible standard of complete understanding.

Listen to Episode #41 for Matt's full conversation with Dwayne Samuels.