Problem-solving in design is less about the screens, and more about the relationship of the person using your solution to what they consider a successful outcome.
Early in my career, I designed screens by leveraging my background in debate. I would take a series of observations, outline a plan and then describe projected benefits. It was very efficient and structured, and had it's justifications built in. The problem was, as in a debate, there are always two sides, and having the design advocate for one solution based on cherry-picked observations is missing the point. We are not our users, and need to fall in love with the problem, not the solution.
More recently, my problem solving has more to do with storytelling. I need to understand the characters, their background, their motivations, what is holding them back and what they dream of. Not every character is the same, but every character is the hero of their own journey, and our role as designers is that of the mentor, guiding them through their experience to achieve their goals.
Finding that journey, and understanding I am not at the center of that journey, is critical. Once you really understand the journey, laying out screens to support it is nearly secondary.
In 1959 Donald Kirkpatrick introduced four levels of evaluation to the learning profession: reaction, learning, behavior, and results. These same levels can be massaged to describe the impact of XD. Thirty years later, Gloria Gery courageously informed us all that we might as well just weigh our students before and after learning, rather than use the metrics we were still using to determine the effectiveness of what we do for organizations.
It was time to update the Elsblog. It may look a bit bare here for a while as I've torn the site down to the studs to rebuild bigger and better.
When I was in college, one of my best friends, Kevin, was an English Lit major. I often asked him what he expected to do with a degree like that and his answer was simply, "Tell stories."
He did eventually publish two books (I have copies of each on my bookshelf), but held many other jobs before that happened.
Once upon a time, boys and girls, we had a computer. In my case, it was an Apple IIc with a floppy drive and 128k of internal memory. It was a large and bulky thing with a lot of wires and a heavy green-screen CRT monitor and stuff, and even though it had carry handles and was billed as “portable,” we left it on a desk at home. If we wanted to do something on the computer, we had to go home to that desk. When we wanted to show what we were working on to someone else, we either printed it out or copied it to a floppy disk and prayed that the person we were sharing it with had the same kind of computer with the same version of software. If they didn’t, we were out of luck.
Knowing where you're going does not always required you to know where you've been.
I teach orienteering and GPS navigation to Boy Scouts, and hear a lot from older Scouters on both sides. Map and compass guys always tell me they would never trust themselves to a battery-powered device when they are in the wilderness, and GPS guys scoff at the sets of directions like “go 342 degrees for 120 feet” and can’t believe anyone still does that.
The thing about best practices is they never stay the same.
Long ago, best practices told us fixed-width websites using table-based design were the way to ensure a consistent experience for users (of course, all users were surfing using desktop computers, and you had to choose 800×600 resolution to get all of them). Best practice also led us to the era of “looks best in Internet Explorer” or Netscape Navigator. Back then, I thought I was keeping up with the trends to help anyone who came to my site see things the way I intended.