I am not one of those people who sees service design as the grand catch-all for multi-touchpoint multi-/omni-channel experiences.

I feel the same way about “service” as I did in the early aughts about the term “user”. These words imply relationships between what is designed and the person whom it is designed. Designing for the wrong relationship means misframing the design problem. “User” implies a tool relationship. Users use things as a means to accomplish something. Of course we can apply the word ‘use’ broadly and see a movie as something an audience uses for entertainment or a concierge as something a visitor uses to get local information, but this breadth is purchased at the cost of consequential subtleties. What we need and expect from a word processor is different from what we expect from a concert or a bank. Discovering exactly what those needs and expectations are and developing satisfactory resolutions of those needs calls for different methods. The mistakes UX have historically made were often tied up with insufficient sensitivity to these distinctions. The same is true of “services”. We can reduce a drill to one component in hole-making service that spans a journey from discovering a need all the way to resolving it, and, yes, much is gained from seeing it this way, but if we are not careful, important distinctions can be lost.

And in fact I do believe certain things are currently being lost by this framing. Software as a service (aka cloud computing) has changed norms around how software is supposed to behave. We are now accustomed to think of web-based software as something that belongs to someone else that we are licensed to make use of. A decade ago, users were more likely to perceive software as tools to own, learn and eventually master. Upgrading was a purchase decision resembling the decision to replace a pen or a hammer with an improved model — not as a periodic change that just happens and requires us to adapt.

This seems mostly OK in many cases, especially where tools serve as front ends to services, for instance banking and accounting, or databases. But for software tools used for making things — word processing, image editing, ideating, music creation, even blogging — changes, especially subtle ones, distract from the tools purpose which is to be an invisible extension of a user’s abilities. It is important that such tools be utterly predictable, controllable and unobtrusive so the user can exercise mastery over the tool to keep complete focus on what is being produced. I am concerned that software designers have lost all awareness of this goal. They are focused on different problems.

Years ago I was struck by the elegance of James Spradley’s research method typology, defining them not by technique, but rather by the role played by the research informant. Surveys are performed with respondents, tests with subjects and ethnography with informants. I think a similar approach could be helpful for classifying design methods. Perhaps we could gain clarity by paying less attention to medium or channel of delivery and more attention to the kind of relationship we are trying to develop through our design between the designed thing and the people for whom it is intended.