That being said, I’m here to argue that without integrating the needs of our ecological and social fabric, design thinking is obsolete. Not only does it generate less value, it also directly contradicts the “human-centered approach” that IDEO claims since its beginnings in 1978. I will go as far as saying that Tim Brown himself, consciously or not, knows it.
FXPasquier – Design Thinking misses a fourth circle. Ikigai comes to the rescue.
Here are a couple of stories I’d like to share on the idea of shared understanding. The first, a conversation between me and my son, Zeke, highlights the importance of being aware of and understanding the context of a situation from different people’s perspective. The second, a story about a friend of mine, shows the importance of ensuring shared understanding in a shared context and how easy it can be to not have it.
You know the way home, right?
My son, Zeke, and I were in Milwaukee for the Midwest Gaming Classic. As we were walking from the hotel to the car getting ready to head home on Sunday morning, Zeke asked me, “You know the way home, right?” A reasonable question, and one that I could honestly answer with yes. Which was the right answer, though as it turns out that was not the question he was actually asking. What Zeke was really asking was, “Can we listen to the radio on the way home?” A little background may be in order.
On the drive up to Milwaukee I used Google maps on my phone, connected to the car audio system, as a navigator to get us from home to the hotel. Because I wanted the navigation to come through the audio system, we were limited to listening to music or podcasts (or other apps) from my phone and couldn’t listen to the radio. So when Zeke asked if I knew the way home, he was really wondering if I needed to use Google maps to get us home. If I had said, “No, I don’t know the way”, then he would have known that we wouldn’t be able to listen to the radio, and if I said “Yes” then we could listen to the radio. (If you’re wondering, we listened to a couple Premier League soccer matches and the first half of the Cardinals / Braves game.)
Because of our long history (nearly 25 years) together, I knew that he didn’t care whether or not I knew the way home. He knew that if I didn’t, I would simply use Google maps as my navigator. I did know that he cares about what we listen to in the car, that he prefers to listen to talk (usually NPR) or sports over music, and that he usually watches Premier League soccer on TV on Sunday mornings. So understanding where he was coming from allowed me to answer the question he was actually wanting an answer for. It’s probably worth noting at this point that Zeke is autistic and, while able to communicate verbally, has some unique challenges and methods in his communications. Developing this shared understanding has been critical for both of us to understand each other.
DO NOT LET GO, YOU ARE NOT ON BELAY!
Some friends were out rock climbing. It was an especially nice weekend, so there were a lot of people out taking advantage. There was one route my friends wanted to attempt so they waited while another pair were climbing. While most of my group of friends were relaxing and just generally hanging out, one friend – we’ll call him Dave – was watching the other pair climb. And good thing he was.
When a climber reaches the top of a route on lead, he will typically clip directly into the anchors and go off belay so that he can fix a rappel to get back down. Sometimes, though, he will set some gear and run the rope through the gear so he can be lowered down and the next climber can then top rope the route. In this case, the climber did neither; instead, he down climbed to the last piece of protection he had placed on the way up, apparently with the expectation that his belayer would then lower him from that point. The belayer, however, was not aware of any of this, having expected that the climber had gone off belay at the anchor. (I think you can see where this is going.)
Dave, my friend, was watching all of this and saw that 1) the belayer had taken the climber off belay and 2) the climber was getting ready to let go of the rock and lean back to be lowered to the ground, which meant that 3) the climber was just about to plunge to his death. At which point Dave shouted at the top of his lungs, “DO NOT LET GO, YOU ARE NOT ON BELAY!
The route this pair was climbing was an overhanging 5.11c, meaning that this was an experienced pair of climbers (5.11c is hard) and that when the climber is on the top half of the route the climber and belayer cannot see each other. The typical exchange when the climber gets to the top and clips into the anchor would be for the climber to shout down, “Off belay” (to let the belayer know that they can take him off belay) and the belayer shouting back up, “Belay is off” to make sure that the climber knows he is on his own. In this case, the climber shouted something down, the belayer thought it was “Off belay”. The pair thought they had a shared understanding of the situation, but they obviously did not. The climber had broken from the routine, while the belayer was following the routine because she didn’t know of the climber’s change.
Fortunately for this pair, and everyone at the crag that day, Dave’s warning was in time and successful in stopping the climber from letting go and leaning back.
The point?
There is no real definition of what “shared understanding” entails; it’s more of a “know it when you see it” kind of thing. These two stories, hopefully, show what shared understanding might mean in different situations; one being a situation where two people are coming from a different context and one where they are coming from the same context.
Would love to hear some of your stories about shared understanding, or the lack thereof.
I was at a local big-box store the other day picking up some hardware for a home improvement project and had the need to visit the men’s room. It is a large store and so has a relatively spacious men’s room, with the sinks just inside the entry followed by a row of four urinals. As I walked in I was struck by the fact that the four urinals appeared to be exactly the same, except for one detail. If you can see the featured image of this post, I’m sure you know what I’m talking about.
I couldn’t help wondering, “Why didn’t they just install them all that low to the ground?”
Of course, that was a somewhat rhetorical question to myself because I can easily visualize how the design process went.
Based on the size of the store, the building codes require us to have four urinals. Let’s go ahead and put them along this wall here and install them at the standard height. Oh, except for one that needs to be lower because, well, you know, the “rules”. Left or right side? Doesn’t matter, as long as we have a short one.
And as a result only one of the urinals was installed lower to the ground, because that was all that was required.
It would be easy enough to say that “accessibility” was not considered in the design process for this men’s room, or that it wasn’t sufficiently considered. I would argue, however, that this design is very much based on a consideration of accessibility. It’s just that the accessibility considered was exclusionary and not inclusionary.
Here’s what I mean.
Back when modern urinals were first designed to be more than an open depression or slit in the ground that men stood around to, well, you know, the only people who would ever use them would most likely be adult men. There was little or no effort made to make it possible for those with physical handicaps to even get into the building, much less any thought given to how they might use the restroom. So the urinals were designed to be exclusively accessible to adult men who could stand up in front of the urinal. (To be clear, this is just an assumption, my impression based on my understanding of history in general.)
Fast forward to today when we know better and make more effort, at least on paper, to make access to spaces and facilities more inclusively accessible. The exclusionary approach is so ingrained in the culture and in design that making something accessible for the “other” is seen as something separate, something that needs to be done because someone somewhere said it had to be done.
An inclusively accessible design for this men’s room would have, in my mind anyway, had four urinals closer to the ground than the old standard (it should become an old standard, anyway). To take it even further, the design and construction standard (and building codes, to be sure) should be changed to reflect this inclusive design approach.
If one of the urinals is going to be lower to the ground than the “usual”, why not just make them all lower to the ground? In this way you are meeting the needs of all (or at least more) with one simple change.
To be sure, inclusionary accessibility is more difficult in some situations than in others. The urinal example above is relatively straightforward compared, for example, to the challenges software and website developers have. Unlike the physical example of the urinal, which can easily accommodate all users with a single configuration, software developers have to understand and contend with often competing and contrary needs.
A basic example is the user interface of a web site in a web browser. Just take a moment and consider how you use the web browser on your laptop. Now, close your eyes and think about how you would use the web browser on your laptop if you couldn’t see it.
For the person who can see the screen, visual cues are typically sufficient and they would likely not want to hear a description of the screen or the layout read to them as they navigate the page. But for the person who can’t see the screen, the actual visual design of the site is unimportant and, for all intents and purposes, of no value. They need another way with which to navigate and to consume the content.
Which gets us back, once again, to the prevalence of exclusionary accessibility in design.
Blind people aren’t going to use a web browser, how would they see it? So we’ll just design it based on people being able to see what they are doing.
I am encouraged by some recent examples of incorporating accessibility in digital design. WordPress, for example, requires that “all new and updated WordPress code must conform with the WCAG 2.0 guidelines at level AA”. The upcoming St. Louis Service Design and UX Conference has accessibility as a focus; I hope that the speakers will at least touch on this idea of inclusionary design. And I am especially encouraged by the growing (slowly growing, but growing) awareness and use of human-centered design principles.
But none of this matters if “accessibility” continues to be seen as something separate from the main design, an add-on for the “others” that can’t use the “real” version.
We need to become inclusionary not just in our design work, but in how we see the world as a whole.
One common frustration about the process of customer journey mapping is the lack of organization-wide or even industry-wide standardization. What are the key steps of journey mapping, and in what order should they be completed? Effective customer journey mapping follows five key high-level steps:
As someone early in the second half of my first century I, like many in my situation, have had conversations with my mom about how she wants to live out her life as she gets older. We (my wife and I) have had similar conversations with her parents. There are no easy answers, because you never really know what’s going to happen until it happens, but you do need to plan.
Earlier today my mom shared this video on Facebook. (A hint, maybe?)
Now I don’t know if the numbers in the video are accurate, and to a certain extent it doesn’t matter. What matters is the point that the video is making, that we can do better by our parents and grandparents than warehousing them in “homes” that are more hospital than home.
I wrote about this over ten years ago after hearing an interview with the makers of the film Almost Home. Here’s what I had to say about it then.
– – — — —–
On the other end of the age spectrum, adult children often must make care decisions for their aging parents. Many times this results in these elderly parents living out their final days in a nursing home, with every aspect of their lives controlled by the administrators of the home. Again, not a decision to be made lightly. (I think we’ve all heard the horror stories.)
The film Almost Home, recently aired on PBS, talks about a different kind of way to run a nursing home.
ALMOST HOME offers an inside look at the lives of these residents, their families and those who care for them as each adjusts to the challenges of growing older. ALMOST HOME filmmakers Brad Lichtenstein and Lisa Gildehaus introduce couples bonded and divided by disability, children torn between caring for their dependent parents and their own families, nursing assistants doing difficult work for near-poverty wages and visionary nursing home director John George, who is committed to transforming his century-old hospital-like institution into a true home.
Under George’s leadership, Saint John’s On The Lake is reinventing its 135-year-old medical model of care (think hospital) with a social one (think home). His goal is to transform the way people see nursing homes—not as institutions of boredom and despair but as vibrant communities where residents live rich and fulfilling lives. To succeed, he will have to win over skeptical managers, resistant nurses, overworked and underpaid nursing assistants, complacent residents and often-overwhelmed family members.
The key change in my mind is that the residents here retain as much control as possible of their own lives. They can wake up when they want to, instead of the usual scheduled wake-ups. Meals are tailored as much as possible to what the residents desire, not a typical bland hospital menu. (If someone has lived a good 90 years, and wants some bacon for breakfast, they should be able to get bacon for breakfast!) They have a cocktail hour every Monday where *gasp* they can drink cocktails.
—– — — – –
Basically, a human centered approach.
I’d like to think that a lot has happened in the ten years since. Time to do some more reading and research.
Service design is getting more and more attention in government at the moment, but many people still don’t understand what it is. The most common question I hear – from people both inside and outside government – is: “Isn’t that just UX (user experience) design?” Let’s be clear: service design and UX design are not the same, because a service is different from a user’s experience.
Source: Service design: Isn’t it just UX with a different name? | GDS design notes
It has been many years since I’ve really given my resume much thought. I have, of course, kept it (and my LinkedIn profile) up to date in terms of my actual job, and mostly up to date in terms of the work I’ve done in the course of those jobs. But it is a straight ahead chronological resume, following the standard (if there is such a thing) configuration of most recent job first and going back to the last x number of jobs and listing various responsibilities and accomplishments in those jobs. Not necessarily the work I’ve accomplished, but more the “important” tasks I completed. (The full version currently weighs in at a solid 7 pages.)
A key factor in my neglect of the resume is the fact that I’ve worked in the same environment for all of my adult career, and that type of resume is how you are judged, the primary consideration when looking for a new position (and how the company for whom you work demonstrates its range of skills to potential customers). A focus on what you’ve done in the past, with a demonstrated progression of skills and responsibility within a (generally) narrow specialization, not to mention specific education milestones and certifications specific to that narrow field.
My recent online reading (and writing) and involvement with various meetup groups, communities, and organizations (including a nascent startup) here in St. Louis and around the world (online) got me thinking about this resume, and how I present myself and what I do as opposed to simply what I’ve done). And the books I’ve been reading this summer, including Rise of the DEO, Service Design for Business, Managing for Happiness, and Liminal Thinking have got me thinking about what exactly it is that I do do. But it was a book I haven’t read yet (bought, dispatched, not yet delivered) that really got me thinking about what I do, and how to explain it.
From the back cover of The Neo-generalist:
Have you encountered difficulties describing what you do to other people? Yep.
Have you ever labelled yourself in order to be understood? Double yep.
And even more to the point from the Preface (posted on the book’s website):
Since the advent of the Industrial Revolution, our society has remained in thrall to the notion of hyperspecialism. This places constraints on the ways in which we are educated, the work we do, the people we socialise with, how we are recruited, how our career progression is managed, how we label ourselves for the benefit of others’ understanding. To counter and challenge these social norms, the neo-generalist has to learn how to give expression to their more generalist tendencies, even as they practise various specialisms, guiding others as they do so.
Which is exactly the conundrum in which I find myself.
To give you an idea here is a list of some of the things I’ve done through the years, in (not reverse) chronological order:
I think you get the idea. Like most people, especially most people in the Army, I started out in the jobs that my career field said I should start in. While I didn’t have a choice in the job, I did have a choice in the work. As my career progressed, especially after leaving the Army, I did have a choice of job, and often based my decision based on the type of work I’d be able to do. And, as importantly, how I’d be able to do it.
Though I didn’t have the words or terminology for it back then, I realize now that I’ve always had a human-centered approach to my jobs. Although getting the job done was always important, how it got done was very important to me. Though not to everyone. A story from my first job….
On my unit’s first deployment to a field exercise after I had joined, one of the comms links was just not coming in. It was a training exercise and so, naive me, I was using it for training. What I didn’t realize is that others (my boss and his boss) saw it not as a training exercise for me and my team but for them. (This is, if you are familiar, the curse of the Signal Corps.) So when my boss came out to the rig and saw me in the door, he started chewing on me before he even arrived. “Why are you out here, why aren’t you in their making this work!!!” I had no words except, “This is [her] job, she needs to do it. Besides, I don’t know how to make this work.”
When I was in the Army, it was easy to tell people what I do – “I’m an Army Signal Officer.” Once I left the Army, it was a bit less straightforward. “Systems Engineer” is no help to most people, and the tasks I was performing weren’t any better at getting across what I did. So, for the most part, I was “in computers”. Even now, that is pretty much what most people think I do, though it might be a bit more expansive, “He does corporate IT.”
Which is kind of true. My current job title is Solution Designer (Enterprise Social Networks) and Community Strategist, whatever the hell that means. Again, a lot of tasks I perform on a daily basis, but listing those doesn’t really get across what I do, nor how I do it.
Which gets me back around to neo-generalism. Though I haven’t yet read the book (dispatched, not delivered), what I’ve read from the authors leads me to believe I am a neo-generalist. Which makes sense, because I’ve very often found myself acting as both generalist (connecting the dots) and specialist (building the dots). The chronological resume format doesn’t – can’t – really convey this to the casual reader typical hiring manager / resume screener. Which gets us, finally, around to the functional resume.
Nearly everything I’ve read about functional resumes, as I’ve been thinking about and doing research for revamping mine, paints them as a last resort, something to be avoided unless absolutely necessary. As I’ve gone through this process, though, I’ve come to realize that this is because most people look at jobs, at work, in terms of specialization. That if you don’t have a good cohesive chronological narrative of tasks, there must be something wrong with you.
And, to be clear, if you want a job that builds on a specific specialization, it is probably a good idea to have a chronological resume with some good details on what you’ve done.
But I’m starting to think that for me, and for other neo-generalists who are interested as much in how they work as the tasks they perform, the work they do and not just the job they have, a functional resume may be the way to go.
tl;dr I’m going to update my resume, and it is going to be a functional resume.
no straight lines 