A cable is a useful corrective to a software engineer’s optimism.
It can be plugged into the wrong socket. It can be too short. It can work perfectly on a desk and become a nuisance once the equipment is installed where somebody actually needs it.
Hardware makes context difficult to ignore. There is light on the screen, dust around the connector, somebody wearing gloves, somebody reaching from the wrong side. The design has to survive those conditions as well as the ones in the specification.
Building software and hardware solutions for clients was part of Partech’s work for more than twenty years. The equipment and applications varied. The underlying obligation was steady: the parts had to work together in a place where people had other things to do.
Beyond the successful test
It is possible to test a component carefully and still misunderstand the system it belongs to. A device may produce the right reading while its display is hard to see. A program may save a record correctly while giving the operator no confidence that the save happened.
The gap is often at a boundary. Between the physical action and the software’s response. Between what the engineer meant and what the person understood. Between a failure and the explanation of how to recover.
That is why I like asking what happens immediately before and immediately after a feature is used. Where did the information come from? What does the person need to do with the result? What happens if they are interrupted halfway through?
The answers bring the work back into view.
A phone is a place, too
Our own apps live in physical circumstances just as surely as a piece of equipment does. A phone can be used in poor light, with one hand, at the end of a tiring day. A document can have small print. The person opening a game may be looking for a few undemanding minutes.
Larger corner numbers can make a card easier to distinguish. Reflowing a page can make a document fit a smaller screen. Those are decisions about the circumstances in which the task happens, and they can be as important as the capability underneath.
Neither example needs an elaborate theory. It needs attention to the part of the experience that is easy to overlook while building it on a large monitor.
Leave a useful way back
Physical systems also make recovery very concrete. If something stops working, somebody has to notice, understand enough of the problem to act, and get back to useful work.
The same standard belongs in an app. An error message should tell you what could not be done. An undo should reverse the action you think it reverses. Saving should give you a clear result. A temporary interruption should not become an unexplained loss of work.
These are engineering decisions with a human shape. We learnt to care about them in client systems. They remain worth caring about when the entire product fits in somebody’s pocket.