I had an appropriately distanced lunch with someone in my field whose main internal client is reorganizing. That client wants training that will, among other things, help employees understand the latest version of the strategic plan.
Coincidentally, I recently came across materials from a long-ago workshop led by Joe Harless. The materials were for the topic of “front-end analysis,” a term Joe coined.
Front-End Analysis is about money, first and foremost. It’s about how to spend money in ways that will be most beneficial to the organization and the performers in that organization.
It is also about avoidingspending money on silly things like instruction when there is no instructional problem, or training everybody in everything when you can get by with training fewer people in a few things, or flying lots of trainees in for a course when a send-out checklist would do.
J. H. Harless, “An Analysis of Front-End Analysis,” Improving Human Performance, 1973 (4)
Joe’s workshop in part looked at how to translate a “soft request” into something that would pass the Heydad Test. (“Hey, Dad, watch me while I understand the strategic plan” does not.)
One page from the workshop:
What was behind these requests?
“A sense of organizational history” — the client wanted to address the problem of loggers cutting down too many of the wrong trees.
Soldiers who “appreciate their cultural heritage” would be better at cleaning their rifles.
The problem of workers not appreciating “the internal beauty” of the widget operation turned out to be the problem that workers did not know how to operate the widget-making equipment.
As for the request to make students more globally aware? The actual request was showing foreign service personnel how to avoid violating local customs.
Which leads to Harless’s prize, the world’s softest soft request:
Educate everyone in the company in communicating, believing, and using common sense to creatively engender the new MBO principles.
In this sentence he found nine different reasons why the request is soft (and thus clues for what you’d need to clarify):
EDUCATE: the request includes a specific solution.
EVERYONE: a non-specific “who.”
COMMUNICATING: a collection of behaviors.
BELIEVING: an affective state.
USING COMMON SENSE: covert behavior (how can you recognize this when you see it?).
The actual situation that the request was describing? Supervisors needed to negotiate individual-level objectives with their subordinates. To deal with actual problems, Harless and his associates developed a two-hour workshop in which participants practiced using a job aid to help cover the key elements of the negotiation.
Göransson is visually impaired, and his screen reader comes across lots of what he calls alt-text-fails, like image file names or photographer credits. As he says:
An alt-text is a description of an image that’s shown to people who for some reason can’t see the image…
Alt-texts are super important! So important that the Web Content Accessibility Guidelines (WCAG) have alt-texts as their very first guideline…
For a long time on my blogs, including this one, I treated alt-text as a way to show a kind of cleverness: many of the images here have alt-text that was intended as a pun or a side comment; it doesn’t describe the image at all. So it was no help to anyone.
Describing: it depends
Göransson points out what should be obvious: what you put in the alt-text description depends on context. Here’s an image from his post:
If the context was about a TV series, he says, the alt-text might be:
Star of the show, Adam Lee, looking strained outside in the rain.
In an article on photography, though:
Close up, grayscale photograph of man outside, face in focus, unfocused background.
The top items for me from Göransson:
Describe the image in context.
Keep it concise.
Don’t say it’s an image (as in, don’t put “image of” or similar in the alt-text).
End with a period (so the screen reader will pause for a moment).
Always include text labels with icons.
That last point is about alt-text, in a sense: he’s saying put text on screen next to an icon, and not in alt-text. Icons shouldn’t stand alone, as users who didn’t create the icons could tell you. (That’s a whole other story, as this link from his article illustrated.)
This post briefly describes kanban in terms of personal planning and management, and then explains how I combined a kanban tool (Trello) with Google Sheets to give me an easy way to record the things I get done so I could review them and reflect on how I’ve been doing.
Not nearly enough about kanban
Kanban (“sign” or “billboard” in Japanese) began as a system for improving efficiency in manufacturing by making tasks and progress visible. Here’s a simplified kanban board:
The “to do” column, sometimes called the backlog, shows all the tasks that need to be done. The next column is “in progress.” One rule of kanban is to limit the work-in-progress, because you can only do so many things in, say, a week. At the beginning of a work cycle, then, you move cards from “to do” to “in progress” based on your capacity. As tasks are done, you move them to the “done” column, and you’re now able to move another task from “to do” to “in progress.”
There’s a lot more to this, but since I’m not a manufacturing plant, for me it was extremely helpful to read Personal Kanban by Benson and Barry.
The following video explains kanban in terms of software development. You can cheat and watch just the segment from about the 1:00 mark to about the 2:15 mark; that’ll be plenty for this post’s purposes.
A kanban board to plan
I’d seen coworkers using Trello on projects at my last job, so I got myself a free account. Trello has three levels: a board (think of this as a high-level category), a list (a stage in progress), and a card (a specific task). The following image is a board I set up for a trip I’d like to take.
Here’s the same board with some cards added.
At the beginning of this imaginary week, I looked at the backlog — the pool of all cards — and dragged the “check visa requirements” card to the “in progress” list.
In real life, I might set a work-in-progress limit of four cards, forcing myself to prioritize items from the backlog.
When I finish a task, I drag it to the “done” list. Over time, that’ll be a big list, and it’ll be hard for me to see what I did when. One recommendation from Personal Kanban is periodically to review your accomplishments and reflect on your process, which is harder with a constantly growing list.
Laziness, the road to efficiency
I knew I could create a spreadsheet to record those completed tasks somehow, but I didn’t want to be copying and pasting all the time.
So I poked around in IFTTT (“IF This Then That”) to see if I could create a little app to do the grunt work for me.
Of course I could. The start of an IFTTT app is the trigger, the thing that kicks off an action. In IFTTT, when Trello’s part of the trigger, you spell out which group of Trello boards, which individual board, and which list on that board you’re talking about, as you can see in the example on the right.
In other words, the trigger is “if I drop a card here…”
That’s the IF THIS. The THEN THAT is an action. Trello’s already set up to take action with Google sheets. In fact there were two or three, and one was “add a row to a spreadsheet.”
Click the image on the right to see the default setup in IFTTT for adding a row to a spreadsheet based on a Trello card.
The format confused me quite a bit, and I had to play with it for a while to figure out what the options were, and which ones I needed. All those labels in the formatted row section, for example, are the names of fields used by Trello; you can pick from them to make column headings in Google Sheets.
What the action section of IFTTT is really asking is:
What sheet you want to add rows to?
What do you want to put into each row?
What’s the path to the sheet?
I made a lot of practice cards, dragged them around, checked the results, moved columns in the sheet, and so forth.
What did I end up with? A spreadsheet cleverly named COMPLETED. In the “formatted row” section, you specify the names of the columns, and those names come from the field names in Trello.
I was interested in when a card moved to “done,” what board it was on, the card’s title (the short description on the Trello card), and the URL in case I ever wanted to see it again.
Strictly speaking I didn’t need to specify the done list, since the whole app is about cards that got moved to a done list, but I put it in in case I ever want to add other lists as well.
If you don’t have a spreadsheet named COMPLETED, IFTTT will create one the first time the app gets fired. I made the sheet ahead of time and practiced with dummy data. That seemed a lot easier.
What does the record look like?
The first five columns were spelled out in IFTTT. Because Trello’s timestamp (date) is so clumsy, with help from an online colleague I learned the formula you can see in the formula part, which parses the long-form date and turns it into a more searchable, sortable one.
Details on making it work
At the beginning of the month, I (try to) go to the spreadsheet and create my own monthly archive. I copy the completed items and paste them onto a new, month-labeled sheet. On the main sheet, I then hide the rows I’ve just copied, so I’m ready to start recording the new month’s completions.
Usually, looking at a month at a time is better for me. If I wanted a longer slice of time, I can unhide rows on the main page and look at whichever I want.
I haven’t figured out how to automatically insert my date-simplification formula mentioned earlier, so every now and again I visit the sheet and just copy the formula to rows that don’t yet have it.
I have half a dozen kanban boards — one for professional concerns, one for personal development, one for household items, and so on. It’s a way to compartmentalize things; it works for me. That’s why, in the BOARD column of my spreadsheet, I have conditional formatting that changes the color of a cell based on the name of the board it came from. It’s a little stunt that I like, and I can use those labels to filter the display as well.
(This is my second post related to destination-dispatch elevators.
Here’s the first.)
“What IS this stuff?”
Having encountered the touchscreen call panels and the buttonless cars of the Hyatt Regency Vancouver, I tried to find out what this approach was, and why it was.
The condensed version:
Destination dispatch systems (sometimes called, tellingly, destination management systems) assign passengers to particular elevator cars based on their destination rather than by when passengers entered the elevator lobby.
Example A, taken from an online course on DD, shows a standard elevator system: passengers are waiting in a building lobby served by four elevators. When one arrives, everyone who can will enter, guaranteeing a maximum number of stops.
What’s more, until people are inside the car and select a floor, nobody–except the individual passenger–knows who’s going where. Out of a dozen passengers, eight could all be going to the 11th floor, but they’ll have to stop at 3, 4, 7, and 8 along the way.
In a “conventional destination system,” as shown in Example B, people first choose a floor, then get assigned to an elevator based on that choice.
If this example were the Hyatt, when I selected the sixth floor, I’d get assigned to elevator C. There’d be no point in boarding elevator A or B or D–at least on this trip, they wouldn’t be stopping on the sixth floor.
If you compare the images, the four elevators in example B make fewer stops total, for the same passengers, than the elevators in example A.
The first-time passenger wouldn’t know that, of course; she’s mainly concerned with getting to the sixth floor so likely isn’t pondering the rationale. Though if three other elevators arrive before elevator C does, she might start wondering why.
The reasons why
The goal is to move people through the building faster and use the elevators more efficiently. Here’s an example from a Thyssenkrupp fact sheet for one of their offerings:
It took me a while to read the left-hand example: there are four people traveling to each floor; they are color-coded by floor. Take the elevator on the left, three people get on in the lobby. The yellow person gets off on the third floor; the dark-blue person on the fourth, and the light-blue person on the fifth. In the right-hand example, four light-blue people get on the second elevator and travel straight through to the fifth floor.
The more I read, the more complexity I found.
Types of buildings: how you apply destination dispatch is one thing for a hotel, another thing altogether for an office building. And in the latter case, do you have a lot of within-the-building traffic, like from the finance department to the sales department?
Types of access: you can combine destination dispatch with a security system. For an office building in lower Manhattan, employees of Lochaber Amalgamated might have floor access determined by function — if you’re not in IT, maybe you have to be escorted onto the 9th floor by someone who is.
Destination dispatch might allow you to have fewer elevators with the same level of service as a greater number of traditional-technology elevators.
What I’m thinking (now)
As Don Norman said of design, everything is a tradeoff. Because this is (relatively) new technology, I think most people aren’t accustomed to it, and as noted early, each morning during my three-day stay, I was surprised to step into the car and find no destination buttons whatsoever.
For my wife and her fellow conference attendees, the switch between two hotels where events took place meant they were regularly shifting between the Old Way and the New Way, elevatorially speaking.
Still, the initial learning curve is relatively low. Yes, you’ll be a bit pokey on your first few rides (“Oh, right, gotta choose my floor”), and especially in the lobby you’ll learn quickly not to jump into just any open elevator–because not only is this one not going to the tenth floor, once you’re inside there’s no way to make it go there.
The most striking drawback, I think, was the lack of status information for people waiting, especially during busy periods like lunchtime. I waited on the sixth floor with eight or ten people wanting to descend to the lobby. We heard elevator noise and even voices in the elevators, but we had no idea when our elevator would show up, nor where it was in the meantime.
It doesn’t take long to get impatient at that point and to lose faith in a newfangled system. Yes, this might be more expedient for the average passenger, but I’m not the average passenger — I’m just me, and I’m wondering when I’m going to get off this damned floor.
I don’t have any big conclusion. Ultimately I enjoyed this real-life user-interface experiment. It left me with more appreciation of what a challenge it can be, trying to make new technology work in the real world.