Interaction Design "moves the pain up", and worth it

I was talking with an interaction design consulting client last week. After a few weeks of working on this project, I asked him about his experience of it -- was it proving valuable enough to keep working together. He answered in an interesting way: he said that the work was painful, and more specifically that it moved pain to the front of the design and build process.

Some context:

Our engagement roughly amounts to a selective teaching and coaching relationship where I try to understand what he needs to get done and I teach him how to do appropriate interaction design activities. Between his budget and his wanting to "learn to fish", he's planning to do the interaction design work itself.

The outcome that he's aiming for is that the system that he is programming and wants to offer as a commercial product has the appropriate relationship with the users of the system, particularly around teaching concepts in the work and an appropriate division of work between person and system.

He knows a good deal about users and their domain, having previously worked with a couple of user on consulting engagements and an early incarnation of the system he's developing. So he's calling the user and domain research work done enough for now and wants to work on the interaction and technical design of the software system. In particular

So, guided by the approach described by Kim Goodwin in Designing for the Digital Age, we started with context scenarios. At a high level, these were pretty straightforward for him to describe and me to outline on a whiteboard. After doing some work on his own to get done at a high level (like "user X reconciles information"), I suggested going to a fairly fine level of detail along these lines:

user X: sees 71 transactions in account CAT in system 1 and checks that against account CAT in system 2 and approves" 

system: records approval of account CAT and updates totals

note: need to check algorithm for updating to avoid double counting 

My client said this was painful. We talked about it a bit more. He said it was uncomfortable, even painful but also seemed worthwhile. I asked: what seems makes it worthwhile?

He said that all these details were going to be addressed anyway sooner or later (they were inherent in the work), and he knows that once code starts to be written, it carries momentum. Thinking through these issues in a text document, rather than in code and data, gets them addressed flexibly, without worrying about code that's already been written and how to adapt it or replace it. Since he knows something about finance, I suggested that there might be something like a "net present pain" that he's dealing with. Postponing the pain often makes it more costly to deal with, but just like large up-front payments rather than variable interest later, there can be savings and confidence.

He also explained that finding challenges in a scenario early gives time for inspiration for how to deal with them to come to him. (Since our discussion, it occurred to me that another way to put this is that finding challenges earlier gives you more showers for inspiration to strike before the challenge needs to be addressed.)

In The Simplicity Shift by Scott Jensen, one chapter begins with a pithy statement along these lines: "Months of programming effort can save days of critical thinking." Agreed.