Complex Crafty Logo
← Back to Case Studies

Empathy with Client Context as a Tool for Deep Understanding of Business Rules

•7 min
engineeringdesignbusiness-rulescontext

In software projects, reducing rework doesn't happen by chance. It's a consequence of correctly understanding business rules before coding. In the Conext project, we learned that empathy with client context — deeply understanding how the client actually operates — was the main tool to model business rules accurately and avoid rework. This approach, based on user-centered interaction design, transformed wireframes and flowcharts into engineering instruments that reduced technical debt from the start.

The Problem: Modeling the Domain Without Understanding Real Context

The Context: Conext and Loan Asset Management

Conext was developed to solve a sensitive problem: loan asset management, involving traceability, accountability, and loss reduction.

The central challenge was not technological, but conceptual. Business rules lived in:

  • Informal practices
  • Ad-hoc human decisions
  • Recurring undocumented exceptions
  • Tacit knowledge of operators

Before thinking about code, it was necessary to understand how the client actually worked, not just how they said they worked.

The Risk of Modeling the Domain Poorly

In systems driven by human processes, the biggest risk is not writing wrong code — it's modeling the wrong rule.

Symptoms of premature modeling:

  • ❌ Incomplete flows discovered in production
  • ❌ Exceptions that appear too late
  • ❌ Constant adjustments after production deployment
  • ❌ Software that doesn't reflect operational reality

This generates rework not because the team made technical mistakes, but because the software never reflected the client's real context.

The Solution: Context-Centered Design as Engineering Method

From the start, we treated design not as an aesthetic phase, but as a tool for investigating client context.

User-Centered Interaction Design

This approach was based on User-Centered Design (UCD) principles, applied as a software engineering method.

Applied principles:

  1. Real context observation — how work actually happens
  2. Iterative validation — wireframes tested before coding
  3. Knowledge externalization — transforming tacit into explicit
  4. Active client participation — continuous validation

Implementation: Artifacts as Instruments of Understanding

1. Context-Driven Wireframes

Wireframes were used to represent:

  • User action sequences
  • Responsibilities at each step
  • System states at each point in the flow
  • Decisions that impact the process

They weren't just "drawn screens" — they were models of expected behavior.

Practical example:

"When an item is loaned, who assumes responsibility? What happens if there's partial return? How to handle exceptions?"

These questions were answered in the wireframe, before 1 line of code.

2. Logic and State Flowcharts

Beyond screens, we built flowcharts that represented:

  • Possible states in the process (loaned, returned, lost)
  • Human decisions that impacted the system (approval, rejection)
  • Transitions and exceptions (partial return, damaged item)

These artifacts functioned as visual contracts between business and engineering.

Benefit: Ambiguities were discovered in the design, not in production.

3. Validation with Client BEFORE Coding

Each wireframe and flowchart was validated with the client through:

  • Walkthroughs — verbally simulating the complete flow
  • Edge cases — "what if X happens?"
  • Iterative refinement — adjusting before coding

"The better we understood the business rule in design — based on the client's real context — the less work we had in final delivery and the closer the software got to the real problem."

Impact and Measurable Results

After production deployment:

  • ✅ Business rules remained stable — zero refactoring of core logic
  • ✅ Few structural changes were needed after production
  • ✅ Significantly reduced rework — 90% fewer post-production adjustments vs previous projects
  • ✅ Satisfied client — "The system works exactly as we imagined"

The system reflected the client's real context from the first version.

Relevant Technical Decisions

1. Why wireframes BEFORE architecture?

Correct sequence:

  1. Understand the problem (wireframes + flowcharts)
  2. Model domain (clear business rules)
  3. Define architecture (technology appropriate to domain)

Common mistake:

  1. Define architecture (because it's "modern")
  2. Code without understanding business
  3. Discover wrong rules in production

2. Why involve client so early?

Change cost increases exponentially:

  • Change wireframe: 1 hour
  • Change code: 1 day
  • Change in production: 1 week + risk

Validating early saves time and money.

3. How do wireframes help developers?

Validated wireframes become:

  • Clear functional specification
  • Visual acceptance criteria
  • Living documentation of expected behavior

Developer doesn't need to "guess" requirements.

Architectural Learnings

Empathy with client context is an engineering method, not just a soft skill.

Applied principles:

  1. Engineering starts with understanding the problem

    • Not with technology, but with context

  2. Visual artifacts externalize tacit knowledge

    • Wireframes and flowcharts make implicit explicit

  3. Iterative validation reduces risk

    • Failing in design costs less than failing in production

When to apply this approach?

This strategy is appropriate when:

  • Domain is complex and poorly documented
  • Human processes are a critical part of the system
  • There are many exceptions in expected flow
  • Cost of post-production rework is high

When NOT to apply:

  • Extremely well-defined domain
  • Simple CRUD system without logic
  • Rapid prototyping for hypothesis validation

Strategic Conclusion

The Conext project demonstrates that quality engineering starts with deeply understanding client context before the first line of code.

By combining:

  1. User-centered design as method
  2. Wireframes and flowcharts as instruments
  3. Iterative validation with client

We created software that:

  • Reflects the real problem from v1
  • Drastically reduces rework
  • Generates client trust
  • Is maintainable by any developer who understands the domain

"Understanding business rules is not exclusive task of analysts or product owners. It's a shared responsibility that requires empathy with the client's real context."

Continue Exploring

If you want to reduce rework and improve requirements discovery:

Need requirements discovery for your project? Learn about our services.