Blog of Much Holding

If you are a member of a user experience design team, you are probably very busy right now. UX design is in high demand many companies have finally realized that a focus on design and the user experience is the “secret sauce” that improves customer satisfaction, increase sales, and generally separates their offerings from the competition.

But with this increased demand often comes increased pressure – multiple projects and multiple stakeholders vying for the same limited resources. How to cope? Well, I have started to adopt some methods that will (hopefully) allow me to grow a UX “SWAT Team” that can better adapt and deal with such demands.

SWAT, as you may know. stands for special weapons and tactics, and SWAT teams perform high-risk operations normal police officers are not equipped to handle. Therefore, I think of UX “SWAT team” as one that can be pulled into any situation, execute quickly and affectively, and then quickly move on to another project. Here are the methods that I am applying to set my team up for success:

Know your limitations – and define the rules of engagement

I’ve seen many projects where the roles and responsibilities of the project were ill-defined, and the project went on and on and on…. Don’t let that happen. SWAT teams always have clear objectives and define who does what when – not having such coordination could cost lives. While a UX project usually doesn’t have such high stakes, not having the rules of engagement defined will usually lead to unneeded stress, missed deadlines and miscommunication.

Take the time to form your plan and define EXACTLY what your team will do to support the project. And don’t overdo it – find out exactly what deliverables the stakeholders need and provide them – don’t spend two weeks producing a findings document when developers need design specifications.

“Specialization is for insects”

The above is one of my favorite quotes, from author Robert A. Heinlein, and one that I have tried to apply in my own life. The idea behind it is simple – be good at many different disciplines instead of being great at only a handful of things. Having a UX team filled with people with varied skills allows you to react to the needs of any new project much better than if you have a team who only does one or two things well.

Get Things Done

I’m a big David Allen fan, and Allen’s Getting Things Done action management method has been incredibly useful to me and several of my colleagues. If only some of Allen’s approaches are applied across your UX team you will see a marked increase in productivity – and a significant reduction in stress.

Test quickly, and test often

If you are revising an existing design, do informal usability tests as soon as you can, even if it’s with friends and family – to get sense of the “baseline” of the system. It will give you much-needed context – or “intel” – to see what design challenges you may be facing. Then test again – even if it’s thin wireframes sketches. Finally, interview end users as soon as you can, even if its by phone, to understand their perceptions and needs.

Use the right tools (as applicable)

I’m a big fan of the Axure rapid prototyping tool, which allows you to both mockup UI designs and document them (in fact I wrote a case study on a project that successfully leveraged the software) – if you have not tried it, you can download a demo from axure.com (and thankfully a version for OS X is being developed). But you shouldn’t tie yourself to this (or any) tool if it doesn’t work for you – you should be focusing on the design problem, not the process of figuring out how to make things happen in a software program. Use paper, pencil, and whiteboards to iterate and ideate quickly.

(Speaking of whiteboards, take advantage of a great new service called Qipit, which allows you to send photos from your phone or computer which are then converted to PDFs. You can send several photos at once and they will be integrated into a single document. It’s free, so try it.)

Over-communication is key

Never operate in a vacuum – always keep project stakeholders in the loop, even if you don’t think they need to be. At worse, they will ignore your e-mail updates… but I have found that more often than not such constant communications increases confidence in the abilities of your team and whatever results they produce. Over-communicate internally as well, to make sure everyone knows who is doing what and that they are on the “same page.”

Use the Scotty method of estimation

NEVER underestimate how long it will take to do something… apply the Scotty method. Scotty (from Star Trek, of course) always overestimates and then… well, just read this chunk of dialogue:

Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
Kirk: “Your reputation is safe with me.”

In my job I have had the opportunity to work on many different products, though most are in the same “product family” – the basic functionality and processes are similar, though sold for different customers/audiences. After executing many different designs and usability tests, I amassed a tremendous amount of information: findings, best practices, user expectations, etc.

I had been relying on my own (all-too-human) memory to keep track of and apply all this understanding for new design projects – obviously, that doesn’t “scale.” So, what to do with all this “stuff?”

After consulting with my colleagues I decided that a formal knowledge base was needed and, after looking at various content management systems I settled on a more direct and simple solution – Wordpress. Setting up the paid version of Wordpress on an OS X server that my team acquired, I was able to quickly configure a site that allowed any of our UX team to add content about the projects they were working on.

Wordpress was the perfect solution for this need. The built-in search fucntion allowed for quick access, meta tags could be added to postings to assist in grouping like content, and categories can be assigned to chuk like content (“UX test findings”, “Best Practices”, “Personas,” etc.). We could also upload attachments and even applied a plug-in that allowed for postings to exported as PDFs for sharing this content with individuals outside our team. Our UX Knowledge Base has become a part of our process, and an incredibly useful one.

If you are in a UX design team and have created a lot of content and legacy research findings, I strongly recommend trying out a similar solution. It has really helped my group, and it can assist yours as well.

I love movies. Obviously, that’s not a distinguishing characteristic – lots of people love movies, and many are far more rabid and knowledgeable about cinema than I am. But it’s part of my personal DNA – I sometimes randomly quote The Godfather, or Goldfinger, and I’ll defend my hero Orson Welles’ body of work to my dying breath… It makes me, well, me.

As I mentioned in a previous post, I have always been especially interested in the screenplay – the art of writing it, the style of it. I read stuff like Robert Towne’s fantastic script for Chinatown, and clearly see why it is STILL being studied 35 years later. And I’ve read several books on screenwriting, on how the good writers have a through-line for their characters, how they write a backstory that is usually never seen on screen, how they build their motivations and how the best screenplays are written around character actions and goals, not stilted dialogue…

Well, today, I looked at my desk and I saw two books, sitting side-by-side. The first, Syd Field’s Screenwriter’s Workbook, is a classic reference to what to do to write an affective screenplay. The second, Kim Goodwin’s Designing for the Digital Age, has become my new ready reference when it comes to all things User Experience.

And then the obvious point slapped me square in my (metaphorical) face.

To a great extent, all of us in the user experience design domain – we are all screenwriters. All the ideas on how to create affective designs and support the best possible user experience – research the domain, understand users needs and motivations, create representative personas and detail user stories… all of this is what our best screenwriters do as well.

Obviously, there are differences in the two disciplines – the tools we use, the documentation we create to tell our stories… but there are enough similarities that I think it provides us an opportunity to look at our craft as designers in a different light. And, honestly, it’s such an obvious thing I’m sure someone else has written about this before (if so, please forward a link and I’ll add it here as an update to this piece).

So,what are ways we can use some of the approaches of screenwriting in design? Here’s some ideas:

Know your characters. If you have any questions or doubts about your users needs or motivations, go talk to some of them. Do the necessary leg work to understand your users (preaching to the choir for many, but still important to note). Create personas to represent your users based on this research. The writer the recent movie The Wrestler spent days meeting with and talking with retired wrestlers to understand who these men were and what the life in the ring was costing them in their lives today. It worked – his screenplay was nominated for an Oscar.

It’s not about the plot. Too many movies focus on pushing the ball down the field, moving from point A to point B to Point C because the writer (or, sometimes, the producer of the movie) has these GREAT IDEAS on scenes A, B and C. That fails more often than not, because it’s not “organic” – It’s not driven by the characters, and the writer sometimes has to make the characters do stupid things to make these bid scenes happen. So, the next time a great new feature just HAS to be in a product you are designing, ask yourself – is it true to your characters (your users, or the appropriate personas)? Will they get any benefit from it?

Write action, not dialogue. Lots of movies are based on plays and in the majority of cases these films are very very heavy on dialogue and light on action. This sometimes works (Neil Simon’s The Odd Couple), sometimes doesn’t (Deathtrap, Hair). Movies are about action, about visuals – “moving” pictures. Dialogue is obviously important, but they should be driven by character and not replace the action. I’m not talking about action movies, I’m talking about using visuals to extend and supplement the story being told. If you watch Bonnie and Clyde, pay close attention to the use of mirrors and lighting, especially in the early scenes – these visuals (as well as how scenes flow together) adds flavor and help tell the story visually.

So, the applicable lesson in UI and experience design? Don’t rely on text to communicate how to use and work with your design, use visual cues and interactivity, when appropriate, to help the user along – to help them understand the story you are trying to tell.

Finally, go read books on screenwriting. Just as some painters sometimes read up on architectural theory to give them a better sense of how to accurately represent weight and gravity in their work, we should reach outside our discipline to see what lessons we can learn from other craftsman. Screenwriting is, to me, just the most obvious example of such an opportunity. At the very least, it gives us a way to look at what we do from a different perspective.

The future has arrived…. Our popular fiction just has a hard time keeping pace with reality.

I kind of feel sorry for the designers and writers of the new Star Trek movie, because of all critical challenges they faced when making the film – how do you reboot a 42 year old franchise? How do you make it interesting to new viewers? How do you please the old fans, some of whom are rabid in their love for the property? Finally (a question that comes to mind because of my profession), what would stuff look like? How would stuff work?

Keep in mind that the movie is a prequel/sequel that is set in the 22nd Century, just like the original series, so as part of the plot we will again be seeing settings, like the bridge, first shown to TV viewers in 1966. What was a sleek vision of the future then… well, to Generation Y? It looks… quaint.

And the sets aren’t the half of it – You compare the communicators, phasers and tricorders Kirk and Spock used, well… as classic and iconic as those original designs are… we can buy an IPhone now. For $200. At Wal-Mart. In comparison… Oh, who am I kidding. There IS no comparison. The iPhone, basically, is the stuff of science fiction, made real.

In many ways, the makers of Star Trek are in the same “problem space” that the makers of the James Bond movies are in – how do you show cool, cutting edge technology (a staple of both franchises) when people have (or have seen) Kindles, Netbooks, smartphones, and touch-screen computers?

The latest Bond film Quantum of Solace had a very interesting early scene where gestural technology (similar to ideas shown in Minority Report) is used in a briefing. The effect was impressive, and you can tell that some thought went into the design. It LOOKED like it would have actually been functional and useful (though, of course, neither I nor any of my colleagues in user experience had a chance to do a heuristic review or usability tests with it).

What is interesting about the scene is two things – first, it looked credible. It is not a great “leap of faith” by today’s audience to think that such a system could be built and used. Second, this movie was set in our TODAY – with such interfaces feasible now, how in the world does a moviemaker project how users will interact with computers in the 22nd Century?

Which brings me back to Star Trek. Knowing full well that the future wasn’t what it used to be, the designers in the new movie updated stuff – the ships, the bridge, the “field gear”… to make it more advanced, more “cool”. And I haven’t seen the new movie yet, but what I have seen of some of the sets leads me to believe there may be some gestural components to the way the systems in the ship are controlled. (Interestingly, many have compared the new bridge to an Apple store.)

But, is it enough? They still have a small black box with a small view screen that allows the characters to scan alien worlds, a “tricorder” – and this, when rumors are flying that Apple will be selling a color tablet that will look, for all intensive purposes, like the data PADD device we saw in Star Trek: The Next Generation. A show that was set in the 24th Century.

Like I said, I don’t envy these designers.

All this reminded of the scene in Back to the Future II when Marty, in the year 2015, shows off his skills at the classic 1980s arcade game “Gunslinger.” Brandishing his lightgun, Marty beats the game handily, and two nearby kids who were looking shake their heads.

“That’s lame. You have to use your hands.”

The exciting notion to me is the idea that, just like we look back at the original’s view of future technology, in 40 years we will look back at this movie’s concepts of the future and chuckle at how “quaint” everything looks.

THAT, to me, is… fascinating.

In construction, there are “weight bearing” support structure – if this support is knocked down or otherwise compromised, the whole building can come down on your head. Also, if you “overload” these weight-bearing supports with two much weight – well, same thing can happen. Obviously, this is a Bad Thing.

I have recently discovered a similar principal in UI design – each screen, based on its purpose, has a “bearing weight” it can maintain before failing the users. Let me explain…

I recently designed and tested three types of screens, and two of the screens tested well – the participants understood what the screen should do and were able to accomplish tasks with no questions or problems. The third screen was different. Users looked at this screen and were completely lost. They understood, to some extent, what they could “do” in the screen, but they did not know where to start.

It was cognitive overload, due, to a great extent, to exceeding this screen’s “bearing weight” – there was too much to process, and the participants “shut down.”

Was this the primary cause of the participant’s confusion? No – there were other usability issues observed and factors at play (for example, a different layout from the two “sister” screens was used). But the fact that it had one module too many was important, especially looking at the intended use of the screen. It was a forecasting/analysis screen that users would be able to access to do planning activities. Several sections of the screen DID NOT SUPPORT that task, and this extra “cognitive baggage” it reduced the total usability of the whole UI.

Naturally, this “bearing weight” of any UI will vary based on context and purpose – the screen for a mobile application, or a log-in screen, may have a “single-threaded” task that should have no distractions or additional design elements – it’s “bearing weight” is low, one widget at most. The opposite end of the spectrum could be software stock brokers use to track the market – these users want as much information as the screen can provide, and therefore the screen can “bear” a lot of content areas and/or functional modules.

When in doubt, start simply, and then add layers of complexity based on design reviews and usability testing. Just as architects have to make sure the proper materials are used when planning weight-bearing walls, application designers must also find the right combination of functionality and content to make the screen work… without crashing down on the user’s head.

I recently tested some designs for my company and thought that a screen design I came up with (a UI module that gives users better visibility into their finances – in a sense, “how are things going?”) was rock solid. It was building on a couple of earlier iterations of the design and I considered the testing to be a mere formality.

Boy, was I wrong.

Testing began, and before I showed the first participant the design in question I exposed the participants to other designs in the prototype system, screens which allowed them to move money around and do things. Then, I got to that “how are things going?” screen.

Blank stares. Confused looks.

EPIC FAIL.

Whenever you have to explain to a participant how something works when they can’t, after some consideration, tell you themselves… well, you see that big thing on the wall over there? It’s called a drawing board – get back to it.

(And, obviously, the majority of your users will not have the opportunity to have a tall bald man sit next to them and tell them how stuff works… though anything could happen…)

After seeing the same reaction occur, again and again, with the remaining participants it became pretty obvious the design was NOT “rock solid” and in fact had some significant issues. What was simple and obvious to me, the designer, was not at all to the participants, who all represented typical users of the existing system. Again, this is why you test designs with users (probably preaching to the choir, but still…).

After analyzing their responses and the notes my lab partner took, I discovered a major problem with the design. It was intended to be “interactive” – in that, if you saw a data point on this screen that was a cause for alarm, you could click it, open the item, and change it. The participants did not see this AT ALL. They thought, due to the location of the screen in the navigation structure and the content surrounding this design that the screen was only a helpful “report” – Informational, NOT functional.

Why? Well, it was because the navigation structure that was applied in the proposed design. The UI modules that supported the primary functions (moving money around) were on other pages – the participants expected that they needed to go to one of those pages if they saw something “wrong” instead of doing it on the “how are things going” page itself…

In other words, the participants separated the system into two spaces – the “doing” space and the “reviewing” space – and mixing them in this screen caused an unexpectedly high amount of confusion.

How to fix this? Well, I’m still working on it, but a possible solution is to place a smaller, more streamlined version of the “how are things going?” module on the functional pages, as a “thermometer” to help users understand their current situation (and making sure to not duplicate functionality that already exists).

This was a good reminder to me, and hopefully you, kind reader, to remember – Every screen, like a scene in a movie script, should have a point to it, a purpose, to help support the goals of the user. What I did was the UI design version of mixing a dialogue-heavy exposition scene with a big action sequence – it was a muddled mess. Live and learn.