Design Follies — ‘It’s all about the technology’
I recently described the method I use to pick topics for posts as “some posts I plan and some just grab me”. The topic for this post seems to be in a class all its own — it stalks me. In previous posts I’ve mentioned how customers are looking for answers to problems, not technology, not artistry. Recently, however, the principle keeps popping up, prompting me to re-visit it.
Just a couple of weeks back, I was chatting with someone on the information systems faculty for a local university. One of the things she mentioned was the importance of understanding that the technology was secondary. Success comes from determining what the customer wants/needs to do, and then providing the how. It’s about finding a place in the customer’s narrative, not finding a way to use a particular technology. After that conversation, I dutifully added a note to my future posts list that it was time for a post on technology as a means, not an end. There it sat for two weeks, when Tom Graves posted his “My ‘EA Masterclass’ coming to Australia”, complete with a slide deck that included this (slide #4):
Okay, I get it — time to write the post.
In this line of work, you need to have a deep appreciation of and interest in technology. If you lack that, I sincerely doubt that you will have the drive necessary to remain current, particularly in today’s environment. Bearing that in mind, however, all the technological brilliance in the world does no good if the product in question fails to meet someone’s needs. How we do so is far less important than whether we do so. Empathy is critically important, because as Jeff Sussna observed in his “Failure == Failure to Empathize”:
When you see things from another’s perspective, you instinctively want to do something useful based on what you see. Empathy naturally drives action in response to listening.
A large part of what makes empathy so important is the architecture of the problems we commonly deal with. Rather than a single context (set of stakeholders sharing similar goals and concerns), most of what we deal with involves multiple, often competing and conflicting contexts. These conflicts are a source of challenges (obstacles to delivering desired value). As Charlie Alfred observed in “Contexts and Challenges: Toward the Architecture of the Problem”: “Tradeoffs between challenges in a context are often subordinate to tradeoffs between similar challenges across contexts”.
Technology belongs to the architecture of the solution, which, to be effective, must follow from the architecture of the problem. When an aspect of the solution does not trace back to some aspect of the problem, this disconnect should be considered a red flag. Choosing a technology for the wrong reason (“this looks cool!”) is a disservice to our customers. Design decisions not only give structure to, but also limit a system. Form follows function initially, but then function is constrained by the existing form.
As always, the most important question when making design decisions, is “why”?
[Photograph by Humanrobo via Wikimedia Commons.]
Originally published at genehughson.wordpress.com on July 2, 2014.
