We let the business users drive the discussion. We listen to their stories, pain points, and suggestions. This allows them to define and use their specific terms (ubiquity is the enemy of efficiency) to shape the initiative. It sometimes leads to discussion threads that shed light on entirely new (to IT) aspects of the project, business process, user experience, etc.

We understand that it’s easy to roll through decisions in the middle of design without consulting users. Unfortunately, not everyone views a problem in the same way. Things that aren’t impactful to some, may be impactful to others.

 

To avoid delays that arise from this disconnection, we facilitate decisions with all stakeholders. We ensure that we explain how each option aligns with requirements, the cost to implement, and how those factors impact the each area. This enables your team to own the decision with full understanding of the expectations.

You never have to convince an architect to draw a diagram. We ensure our diagrams are simultaneously business-legible AND technically useful. This makes it much easier for new eyes (business or technical) to consume and understand the design.

 

Our portfolio of diagrams are organized, structured, and technical enough to communicate important aspects of the architecture, but segmented and simple enough to quickly train any level (or lack) of technical aptitude to read and understand. This results in less time bridging communication gaps and more time executing.

We don’t just “toss things over the fence” when users are performing project functions. We engage them and observe their behavior and/or process. This allows us to pick up on things that aren’t articulated in meetings or requirements. People tend to overlook minutia that may be second nature to them, but impactful to the project. This goes a long way to avoiding the “you didn’t tell us about this” or “we thought you knew about that” conversations when an issue arises.

We engage users in discussing how the new system will work within their processes. Even if it appears to be a 1:1 switch to IT, users will invariably have different—and valuable—points of view.

 

IT sees projects through a fundamentally different lens than users, and something that might seem miniscule (“Oh, they’ll just have to open the file from a different folder”) – could cost time in testing (false positives), support (ticket requests), or even push-back from the project team. All of this costs IT time—something you do NOT want.

No matter how technically savvy your user base is, we approach every interaction with the intent to ensure your users fully understand the impact. We don’t get caught up in solving the problem that’s right in front of us, only to overlook some impact that might rear its head later in the project. Everyone wants to avoid this.