Thursday Apr 03, 2008

Thoughts: Helmet Hair

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

Being an amateur "Cool Hunter" means I'm always on the lookout for Cool. Today I saw a note on the Hightech-Discuss alias from an esteemed colleage and friend of mine, Andrea Kendall who found an interesting article on FoxNews about a brainwave actuated input device:

This is the sort of thing I could definitely get my head around (or around my head as it were)!

Being the closet gadget-geek juvenile I am, I couldn't resist placing a pre-order for my own, limited edition "God of Warcraft" online game player punisher.

It's due to be released later this year and so I'm anxiously anticipating my new power of MMORPG supremacy.

Beware you villains of WoW and Unreal Tournament!!

From a more professional perspective, my mind is spinning from the implications of this sort of input device. It reminds me of older movies like The Lawnmower Man and Disclosure. These movies both incorporated VR in very futuristic, but do-able ways. And since they weren't set too far into the future, you could see yourself using the gadgets they had.

It will be really interesting to see how you might be able to integrate it with your operating system, for things like reading eMail and web-surfing, or perhaps with more real-time applications like simulators and maps.

Now that I've come across something I didn't know existed but obviously must have, I can't wait to see how well it works!

I'll keep y'all posted!

Monday Mar 17, 2008

Goodbye to an old friend - hello to a new 'smart phone'

Andrea Kendall has been a Graphics and User Interface programmer and designer for over 20 years. She is passionate about designing for the user and is currently working on implementing a Web 2.0 GUI using Woodstock.


Well after 10 long years of faithful service my Sharp Wizard died.

 10 Sharp Wizard


Question: Why did I keep this so long?

Just look at that keyboard.   It is so easy to type on.

Anyway, I dropped it last week and the plastic hinge broke.    

While I was really tempted to get an iPhone, I decided to go with the Sprint HTC phone. The first thing I like about the phone is the nice keyboard.  The other thing I like is that it is based on an OS I am familiar with -  Windows XP.

Sharp HTC 'smart phone'

Things I don't like about the phone are:
  • It can be hard to tell if you have closed a program (and it can only run so many)
    • You have to go into another program to check for running programs and stop them (I do this every time I go to turn off the phone)
  • It can be hard to tell if the actual phone is on or it is in  flight mode
  • It seems a little too easy to make a phone call when viewing contacts
  • It does not come with enough memory to actually use the built in camera and run anything else
  • The sales person told me it had everything it needed to back up the phone but it turned out I needed Outlook  if running on Windows XP

Now to be fair the sales person did warn me that this was a more 'geeky' phone.

Yes, I could return the phone and exchange it for the Palm OS one but I figure I will get past the learning curve.  However, it will never be the same as my Sharp Wizard..

So goodbye to an old friend.  

Note: I can still turn on the old Sharp Wizard which I am doing because I have to get all the important data off it.  The Sharp was so old it used a COM port and had proprietary software (long lost)  to back up the data.


Tuesday Feb 12, 2008

All Aboard! : Usability of Public Transit Signs

When people tell me about their travels to foreign countries, I generally ask how they get around, especially if they don't speak the language. Personally, I've pored over paper-based tables with highlighter, gesticulated and tried to interpret the ticket booth attendee's broken English, or followed blindly when I'm visiting a friend who knows the system.

In a recent visit to Tokyo, I was very pleased to find the public transportation signage easy to follow and more useful than I expected. Newer trains in the Tokyo subway system include a LCD display above each door like the following, which alternated between the Japanese and English (unfortunately, this picture was taken when the Japanese characters were up):

Wow! An indication of minutes to arrival, where the train is, and where it's going ... in real time! But wait.. there's more!

To make your trip even more efficient, while at the station, take a glance at the guide to train cars, transfers, stops, and services available at each station on the line. I feel like Edward Tufte might have had a hand in this guide.

These examples are the more "high tech" ones that I saw, but even older trains and buses had some ability to display the current location and upcoming location, which is a far cry from what we find in U.S. public transportation, which consist of mostly garbled announcements.

Here's just one example of public transportation snafu of the many I've experienced in the U.S.. The San Francisco International Airport "AirTrain" shuttles people between places like terminals and rental car lots. A few years ago, I spent minutes quizzically looking at an all-English map that showed the two AirTrain lines - red and blue - which go in opposite directions, around mostly the same loop route. However, it missed a key feature - the direction which each line took! This looks approximately like part of the map I was looking at:

Map of BART at SFO

Thankfully, I notice that at least the SFO airport website has addressed this.


I credit the usability of the Tokyo transportation system to a few things:

  • The Japanese are culturally aware of time, efficiency, and technology.
  • The Tokyo public transportation and related signage has had time and iterations to evolve, unlike places that lack good mass transit, such as the U.S.
  • The Japanese want to foster good relations with their international businesspeople and tourists so they translate key signs for non-Japanese speaking, especially for those who read and understand English.

Some nice side effects also come into play when increasing the usability of signs. It fosters good feelings about the country and people and helps those hard of hearing for whatever reason (Japanese or otherwise) by having clear visual diplays in addition to audio feedback.

Arigato gozaimas, Japan!

Thursday Dec 20, 2007

Emotional design and mobile devices

Now that would be a great blog entry ... how emotional design and mobile devices overlap ... maybe next time, but for now they are two different questions.

Emotional Design

First, a couple weeks back, I asked What design has strongly resonated with you emotionally?... but I didn't get a lot of responses to that question, so I'm asking again now: "What design has strongly resonated with you emotionally?" It could be a car, a light fixture, a cabinet pull, the architecture of a building, or in my case a kitchen faucet.

Another example from my life is when we visited Barcelona, Spain. The pictures of Gaudi's architecture never did a thing for me ... but to stand inside an apartment building or on a rooftop that he designed or to walk around and inside the Sagrada Familia ... those were experiences with his design that cannot be captured in two dimensions. Of course, they can be, but they don't evoke the same emotional response from me as being right there inside of them. My last example (I promise) is a vase that I own. It's a replica of the vase that inspired Keats' poem, Ode on a Grecian Urn, and the moment I saw it, I knew I had to have it ... it's not even a particularly lovely vase, but it generated an emotional response in me that I couldn't ignore.

So here's what I'm asking: send me an email (jenm at sun dot com) and tell me what design resonated with you, and yes, my stash of Sun swag (coffee mugs, travel bags, hats, desk sets, and more!) is up for grabs -- in return for my favorite responses.

Mobile Devices

Then, last Friday, I asked, When you dream of the mobile device that you wish you had, how is it different from what is available now? Thankfully, I received a tremendous response to that question. Far too much to tell you about here; I'll have to give a presentation to cover all that data :) But many people have asked, so I'll happily summarize some of the trends that I saw in the responses:

  • People most frequently asked for a good navigation system on their portable device -- after all, it's a mobile device, so you are likely away from any system that could give you real time map data.
  • Next, people wanted their address books on their mobile device to either sync with their partner's address book (on another device) or not be located on the device at all, but somewhere on the web.
  • There was little agreement regarding the size and weight of the mobile device, but they all fit into the range of smaller and lighter than a laptop computer.
  • There were several people who expressed that they only wanted their mobile phone to be a phone, and to function well -- but they were far outnumbered by those of us who would like our mobile device to do more and be more.
  • People who were avid cyclists not only wanted the phone to go with them on their journeys, but to track their time and distance, their vital signs, be the bike computer, and to use that data to compete with other people at a distance.
  • Not surprisingly, other frequently requested features included seamless integration with WiFi and Bluetooth, removable memory chips, large screens (or the ability to project large), and bigger QWERTY keyboards. People wanted to used a stylus to write, not to type.
Mostly those are the trends, but there were a ton of both incremental and large-scale suggestions. I'm going to have to write that talk, aren't I?

Jen McGinn is an interaction designer in xDesign who is working to improve the user experience with software installation and registration. She has an MS in Human Factors in Information Design and works out of Sun's campus in Massachusetts.

Monday Dec 17, 2007

Design and the Installer

Nalini Kotamraju is a user researcher in xDesign, and holds a Ph.D. in Sociology. She has a penchant for research methods and telling it exactly like it is.

Anant Kartik Mithal, Ph.D. is the Director of xDesign (Software User Experience Design Group) at Sun Microsystems.

I recently spoke with Kartik Mithal, Director of xDesign about the reasons behind the success of the New Solaris Installer.

Nalini: The redesign of the Solaris installer has received wildly positive reviews, both from within Sun and, most important, from our customers. Can you tell me what made the redesign such a success?

Kartik: What was so important in this instance was looking at the complexity of the existing Solaris installation and:

1) Figuring out how to get the team to understand that the designers understand the complexity; and

2) Breaking up the design process into pieces that the engineering team could handle and get on board with.

In other words, you need to earn credibility with the team. The team needs to understand that you know where they’re coming from and the challenges in what they’re currently working with. And you need to figure out the path of least resistance. At the same time, you need to make it something that fits together. The user doesn’t and shouldn’t see the challenge in installation. There’s a lot of planning to make it that way for the user, to plan around the "gotchas."

Nalini: Can you say more about how designers, such as Frank, can get teams to believe that they understand the complexity?

Kartik: So if you sit down and design an installer, often the engineering team looks at the proposal and says "Yeah, we can’t do that. You’re so completely unfamiliar with what we’re grappling with that it’s not useful for us to talk to you." What designers like Frank do is go into the installation process and understand — it does this, it does that, you can do this at this point. You basically build a flowchart and say this is what’s happening now and this is what it’s doing. For example, suppose you want to have a GUI-based install, but you need to have a window manager running in order to get the GUI install to work. The designer needs to know as the installer is chugging along that this is the capacity of an installer at any given point. My understanding is that Frank put together a flowchart that helped him understand the process, and the installation team could look at it and say "He really understands what we’re doing." And that’s the really important part — gaining credibility with the team.

Nalini: You also mentioned the importance of creating a design that can be broken down into pieces that the engineering team can get behind.

Kartik: Yes, for me, the other big thing that Frank did is chunk the project in a meaningful way, working with the team to break it down for implementation and in meaningful chunks.

Nalini: You’ve talked about the importance of the designer’s credibility with the engineering team. What about the engineering team’s role in making this redesign such a success?

Kartik: The biggest thing the team needs is to want to make the usability improvement, and, in this case, the team really wanted to fix it. They could see similar installers – Linux, Windows, Mac – that were much smoother than ours. Frank did a lot of comparative analysis of what’s out there, and he presented it to the team. The team’s role was in accepting the design early on, giving Frank feedback and working with his prototype like bats out of hell and basically implementing in a really short amount of time.

Shortly after Frank had done the prototype, he could point and say this is running code. The team also split things up so that the GUI part was built separately from the infrastructure part. There was a point that Frank would run the GUI, it would say something like "install on this disk," and it would pretend to install. It freed up both pieces so that the people focusing on the GUI could move as fast as they needed and the people working on infrastructure could move as fast as they needed. And they came together when they needed to connect.

Nalini: So xDesign does redesigns quite often. What makes this instance exceptional?

Kartik: What's unique about this situation is the Solaris installer itself; getting Solaris to have a nice graphic bootable boot-up. There are systems that haven't been reviewed for a long time. You make some decisions about what the software can do, and then you layer on more decisions, and then you end up with this gnarly piece of code that is doing a whole bunch of things you want it to and some you don’t, but fixing it means fixing a whole bunch of code. And people don’t want to do that.

We put designers like Frank on this so that they can go and work with the team to pull the whole thing apart and redesign it in a way that solves both the code/architectural problems, as well as the user experience/design problem.

In this instance, the correct answer for the user is really obvious: should I install or not? But we ended up before with an installer that asked lots of questions. It’s easy to conceptualize the answer, but it’s hard to figure out how to get to the answer, figuring out how get from here to there.

That's the thing that I value most in this design. Not the actual design – it’s excellent, of course – but it's getting to the pieces that then fit together that is the rocket science.

Nalini: What would need to be in place to replicate this kind of design success?

Kartik: First, you need a problem with the original amount of gnarliness. We know we have the same problem in some of our software. We were in a situation that we had a bunch of gnarly code, and it would scare people. Everyone knew what the right answer was, but how do we get there? Everyone needs to agree that the problem needs to be solved.

When designers go into work with teams that are not familiar with them, they have to establish credibility at two levels. First, that the designers can design. Frank established this through his prototype. Second, that the designer can understand the problem. In this instance, understanding how the installer worked, documenting, doing competitive analysis and being able to say that other products handle something a different way. Designers go into teams that have been doing that job for many years, and designers need to establish, as quickly as possible, that you have the design chops and the credibility as people who can understand their problem space. Frank was able to do that.

Tuesday Nov 20, 2007

Of Notebooks and Pens

Maya Venkatraman is an Interaction Designer at Sun Microsystems. She started working in the area of Human Computer Interaction in graduate school, where she earned her Ph.D, and has been working in the industry for almost a decade, designing software that is easy to use.

I watched the amazing movie Pan's Laybrinth recently. I wandered over to the Pan's Laybrinth website (a webby award winner!) and found pictures of pages from the directors notebook. Apparently, he is in the habit of putting his thoughts into a journal. Years later in the midst of a project he will remember something he sketched that would be perfect for what he was currently creating. Take a look at this snapshot of the journal. Talk about content rich. Maybe I am a Luddite, but I just don't see someone being able to do this using, say a blackberry.
Now if they had  a FlyTop  pen (or the more grownup version by Logitech) and the paper that goes with it - they would have best of both worlds. The flexibility of paper, combined with all the goodness of Digitality(tm). I stumbled onto this product about a year ago, and am surprised that it has not yet taken the world by storm. (...all it needs is a wireless chip..) Maybe sometime in the future, the notepad portlet/widget, will also connect to my physical notebook. Maybe I will be able to throw some of my web pages on to the wall or white board, and some to my real desktop (surface of four legged table). I could place my digital pen notebook on top of the notepad widget area, to upload the pages I have written. Maybe I am more of a Futurist than a Luddite.


Thursday Oct 18, 2007

What's Right With This Picture?

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

Things done right in the darndest places...

Every once in a while I imagine myself and Andrew Zimmern from Bizarre Foods trotting the globe, he's searching for strange cuisine and I'm searching for usability blunders. I can see us chatting over the table, smiling for the camera, and me wincing while he chokes down some bizarre-bug-bisque. I would then comment on the strange design of the spoon he's using.

Yes, I know what you're thinking - "What a fantastic idea!!" Change the name of the show to "Bizarre Foods and Users", or "Eat-a-usability", or my personal favorite "Bizarre Food Usage". Funny thing is he still hasn't called me back on it yet. It's going to happen though, and I can be patient.

While I was waiting for that call though, I went down to my local library to find some ideas on potential destinations. And then, while waiting in line to check out my books, I saw the most amazing newfangled contraption ever. It was beauty and simplicity defined, an ergonomic eros of non-error. I was rapt with attention while I watched some brave soul actually use the thing.

I had to try it myself!! It was just so... um... usable!! I approached the lady whom I'd just seen use this usable thing -- a kiosk at the public library -- to check out a book, and then realized she didn't speak English. Her books were in Russian! It was amazing to me that a non-English speaker could go to this public library and check-out books without any assistance!

I immediately found my favorite librarian and asked for a demo. This video shows her showing me how to use the most usable kiosk I've ever used.

Notice that even though the interface is in English, the video instructions are so clear that even someone who cannot read them can see what needs to be done. And, if you listen carefully, you can hear auditory feedback as well, letting you know something happened and you succeeded.

Every once in a while, you'll find something that's really well designed and thought through, and in the darndest places.

Technorati Profile

Friday Sep 21, 2007

Journeys in Design

Andrea Kendall has been a Graphics and User Interface programmer and designer for over 20 years. She is passionate about designing for the user, and is currently leading the Sun B2B Platform Dashboard in the SOA/Business Integration Composite Applications group.

Designing a Business To Business Dashboard

My team and I have been on a journey to design a “Business-to-Business” dashboard. Like any traveler going on a journey, I didn't go alone. This project required a team of international programmers, our director, the Software Experience Design (xDesign) Group and, most importantly, our customers.

What is B2B?

Business-to-Business is “the exchange of information to support commerce”. This is a world that requires businesses to send standardized information. It's a world that allows a doctor to look up information about a patient or allows a factory to get the best price on steel from its partners. It's a world that spans large businesses and small mom-and-pop shops that want to do business together.

Identifying the Users

The first and most important step was to identify our users: the people who the dashboard had to serve by supporting their tasks and making their lives easier.

  • Business users
    • Dollars and cents — cut waste and increase profits.
    • Who is costing us more/less and why?
  • Operations users
    • Make sure the end-to-end system is up and running correctly.
    • View alerts about something that was expected to happen but did not. For example, "Purchase order 99587 has not finished processing".
  • Business-to-business centric users
    • Track transaction status for standard messages
    • Drill down to lowest level of a message and show:
      • The Message Hierarchy
      • Errors
      • The actual data sent
    • Resubmit messages back to the system after correcting errors
    • View audit information

Designing for the Web

I had sent off some of our best technical minds to explore what options we had for creating the Web application. This exploration brought into sharp focus that design a Web application is very different than designing a desktop application. It was like the difference between working with bronze or clay: you can create works of wonder using each material but you can not expect the materials to respond in the same ways. Using Swing to create a desktop application was like working with clay: very flexible with a rich set of widgets. Working on the Web was like working in bronze, more restrictive.

However, the rewards for working on the Web were also richer. One reward is that the Web is more available to users than a desktop. Our hectic business user would have access to statistics about his enterprise even while on an important trip. Our brilliant business-to-business-centric user would be able to communicate status about orders to our other users. Our crucial operations user would be able to ensure the smooth running of her business-to-business enterprise even at home. And best of all, they would all be using the same Web-based GUI.

Identifying Example Charts and Tables

Having read the requirements, our team knew that we could not possibly know every chart and table that would be needed to shown on our dashboard. What we did know is that we needed good examples that could be shown in a Web 2.0 application, and which contained data that each type of user would care about. Given these examples the customer could add their own charts and tables. Our team to came up with the charts and tables shown below.

Example charts for B2B Dashboard


Working on the Mock-Up

With the example charts in hand and an understanding of our development material (bronze), we started to tackle the next major task of designing the user interface. Working with Sun's Software Experience Design (xDesign) group was key, especially given that we had to create a way to allow our users to explore their data. This would require that we invent a way to show a hierarchical structure where a node can have thousands of children — a paginated tree. These experts quickly created screen designs and acted as much-needed guides on the path to creating a mock-up that we could show to users.

Message Structure

As of this writing we are exploring several other looks for this widget by creating a working prototype. However, ultimately we may follow one of my rules of thumb, ‘ when in doubt let the user decide what works for them ’.

Not the Final Destination, But a Good Stopping Point

At the end of this part of the design journey, we had several things to show for our efforts. The mock-up and some running code. We were able to see how the mock-up fulfilled the needs of our users and knew we were at a good stopping point.

  • The business user could find out how much money was sent/received.
  • The operations user could monitor the health of the system and check key tasks.
  • The business-to-business-centric user could find the data they needed to track, fix it and send it back to an enterprise.

We are confident that the design work we have done will help us create the right application for our users, and that, after all, is the point of any journey in design.

Monday Sep 10, 2007

What's Wrong With This Picture? (Burning Sensations)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

Is someone burning, or is it just me?

Some time ago I realized that my shower fixture was really out of date. I came to this realization just moments after one of my shower knobs broke off in my hand. Actually, it was probably the moment after the valve shot from the pipe, hit me in the leg (!!!), and sprayed really HOT water at me non-stop. It was like one of those movies where they’re torturing the prisoners in their cell by spraying them with a fire hose, only it was my own home and I was being tortured by my 1950’s bathroom.

Not a problem – close the main valve, have a quick dip in a waist-high vat of Aloe-Vera (which I keep handy for just such emergencies), and then off to the hardware store to find a new fixture.

Modern Design Meets "Huh?" ...

While perusing the many styles at my local store, I came across one that had me scratching my head.

At first glance I was already remodeling my bathroom to work around this beauty. It was shiny, sleek, and smooth. But then I really looked at it. What the...? Which way is "on"? I liked the "anti-scald" feature because I certainly couldn't figure out how to get "warm". The design was so dangerous that they actually had to engineer in safety measures?

There were other problems as well...

  • The knobs (of which there are two) would be slippery when wet and soapy - hard to manipulate
  • There was no indication which knob is "flow" and which one is "temperature"
  • There was no way to determine which direction to move the knobs
  • Whatever the smaller knob did would be hard to do in small increments as the leverage afforded is minimal
  • And like any other single-control shower knob, if you accidentally bumped it during a soap frenzy, there's no telling if you'll go to scalding hot, icy-cold, or just "off"

In this situation, the design is unfamiliar and despite the neat-o looks, it would be hard to get your shower the right temperature at the right rate of flow. Also, if I know myself at all I'd be cleaning it after each use as the finish would immediately show water spots. Sleek, smooth, shiny, and poorly designed.

I kept looking and found several others, not nearly as bewildering, but with similar problems. Some were nice looking, but hard to manipulate. Others, you needed a printed instruction sheet to figure out. At that point I decided the "old-skool" designs were still the most usable.

Older Fixtures Make for Better Showers

This one wasn't as snazzy looking, but it solved a number of the problems with the previous one.

  • You would be able to grip the knobs with soapy hands
  • You could tell which was hot and cold (by placement as well as the letters on each)
  • There was no mystery about how to activate the shower-head.
  • No "anti-scald" feature required for normal use

And... probably the best bit here was the fact it would fit with my vintage bathroom without having to completely remodel it. Not that I'm lazy, mind you, but the time and expense would keep me from being able to shower regularly -- which was what I was trying to do in the first place!

Thursday Sep 06, 2007

Feature rich or easy to use? Yes.

Jen McGinn is an interaction designer in xDesign who is working to improve the user experience with the Java Enterprise System installers. She has an MS in Human Factors in Information Design and works out of Sun's campus in Massachusetts.

Over the last week, a usability email list that I belong to has been discussing Don Norman's article, "Simplicity Is Highly Overrated".

In this article, Don Norman talks about his experiences with consumer electronics in Korea, which illustrate something that he has seen time and time again during his 40-some years in the usability field: people choose products with more features at purchase time, because people interpret more features to mean that a product is more powerful and prestigious, and that the features give them more control. Likewise, people will pay more money for products with more features; even when the buyers understand that more features mean more complexity, and as a result, lower usability.

I wasn't as shocked by Don Norman's article as were some of the usability professionals on the email list, because I'd read the Harvard Business Review article, "Defeating Feature Fatigue" (February 2006), which discussed the trade-offs between features and usability, and the relationship between initial sales and customer satisfaction over time. It cites one study as finding that 85% of returned home networking products were returned because people couldn't get them to work.

Barry Schwartz, in Paradox of Choice, describes our anticipation of our experience with a thing as "expected utility" and the actual use of the thing as the "experienced utility". When our experience (experienced utility) is too far removed from what we expected it to be (expected utility), we are confused and uncomfortable (the technical term is "cognitive dissonance").

So while a product with more features appeals to us at purchase time, if our expectations of it conflict with our user experience of it, that tension can make us feel insecure about using the product, feel less satisfaction in owning it, or lead to returning it all together.

Tuesday Sep 04, 2007

What's Wrong With This Picture? (Lockdown)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

Design isn't all about aesthetics, but aesthetics certainly make a difference. To me, design is part thought process, part style, and part usability; thinking about the problem you intend to solve, creating your solution with style and verve, and then making sure it works well for its intended task and audience. However, much too often in my everyday life I come across something that makes me growl — especially when that something encourages me to make a stupid mistake. Right about then the laugh-track goes off in my head, and I feel a bit like Jerry Lewis, only I'm not intending to do something goofy.

The Pull-Me, Pull-You Problem

I once locked myself in a skyway running between the second floors of two buildings in Des Moines, IA. Because of its cold winters, downtown Des Moines has connecting glass hallways that allow you to travel from building to building without actually leaving an enclosed space. It's great because it can be bloody cold outside that time of year. So how did I manage such a feat?

Well, the picture on the left shows a doorway similar to the one that confused me. And, while it was my error that caused the problem, it was the design that really encouraged it: door handles like these say "Pull-Me" to the person approaching the door. If you watch 100 people approach this door, I'll bet you 50 $imoleans they all try to pull the door toward them.

It turns out though, that the doorway had handles like these on both sides, so folks on either side of the door will likely end up pulling on the handle, which is exactly what I did.

The problem occurs when the door only opens one way. In this case, the "push" side (shown right) also has the "Pull-Me" handle, and in my case, so did the skyway. I pulled open the door at one end of the skyway, to enter, and then pulled (in vain) on the other side to get into the next building.

I then went back and pulled the handles on the door through I had just entered, and sure enough the door didn't open. I assumed that, since it was late in the day, the doors had locked between buildings. I was trapped like an ant in an ant-farm.

Eventually, someone else came through the door on the opposite side of the skyway, and I made my escape. Only then did it occur to me to try again and that's when I figured out the doors only opened into the buildings. I could've pulled on those handles all day and never gotten the doors open. Thank goodness it was a weekday, and I wasn't the only person working late.

The point of my story is the same as the story Don Norman used in 1988 to first describe what "affordances" are: the perceived and actual uses of a thing. In my example above, a C-shaped door handle around waist height indicated a grasp/pull action. This design is fine for two-way doors, but one-way doors could better indicate their functional direction by having a handle on one side, and a push-plate on the other. Norman suggests that "a good conceptual model allows us to predict the effects of our actions." So, in the absence of an affordance, at least put the word "Push" on the correct side for all skyway doors in Des Moines.

Wednesday Aug 29, 2007

Helping to Eliminate Mistakes in Medical Treatment: What We Found (Part 3)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

This is the third entry in a multi-part series (View Part 1) | (View Part 2). In this part, Loren describes the findings of the user research that was conducted.

To solve the problems that we found, we followed classic user-centered design methodology: we didn't start with design. Instead we started by learning about our users. We visited several health care facilities that were already using the current version of the system, and we observed. We learned that health care professionals are very careful and methodical in their work. When they create a "match" between records, they’re certain it is, in fact, a match. They are serious (serious as my Granddad's gun-locker).

It turns out that most of the records that the system can’t match are easily matched by a human. Some common sense, some knowledge of the history of the hospital or facility where they work, experience with mistakes of the past — all of these things make it easier for humans, rather than for computer systems, to match certain types of duplicates.

For the handful of records that aren’t easily matched, quite a bit of legwork is required to figure out what should be done. Researching files, making telephone calls, talking to people in their facility, all of these tasks may be necessary to ultimately resolve a single case. Sometimes the resolution can take days, so our users may have a stack of "pending" matches on their desk that require their attention.

To further complicate matters, there’s an important standard with which all healthcare facilities must comply regarding confidentiality. You may have heard about this standard: HIPAA (Health Insurance Portability and Accountability Act of 1996). Most physicians require you to sign a paper stating you’ve read about and understand it before they’ll accept you as a patient. In the context of our project, we found out that each time someone looks at anyone’s medical information that "viewing" is recorded as a transaction to ensure complete confidentiality. So nobody’s flipping through medical files willy-nilly — they’re doing it because it's important (see previous "gun-locker" note).

After learning about our users, the problem was distilled into "How can we help them match multiple records quickly and easily, while allowing them some way of reversing a match if it turns out to be a mistake?" We started the process of brainstorming and kicking around design ideas. We mapped out the health care professionals' tasks and optimized the flows so that the most frequent and critical actions took the fewest number of steps.

This work resulted in a few key design requirements to make the complex matches easier to perform and track:

  • The ability to quickly see just enough information to determine if further research would be needed
  • The ability to see all the information across multiple systems (and to easily highlight the differences)
  • Having some way of putting a case in a "to be researched" or "pending" stack so that it could be retrieved quickly when new information became available
  • …and, of course…

  • Some easy way to reverse a match if it turns out to be an error

This kind of meaningful design work doesn’t happen that often, so when it does it’s really cool. Designing something that makes a difference to a lot of folks, not just the technical community — it's enough to make a guy proud. Sort of reminds me why I decided to do this kind of work in the first place.

Wednesday Aug 15, 2007

Helping to Eliminate Mistakes in Medical Treatment: Our Challenges (Part 2)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

This is the second of a multi-part series (View Part 1)

For this project, our design task involves finding a way to help health care professionals match records that the existing automated system can't.

The system is made up of two parts. The behind-the-scenes part consolidates a patient's records from various data sources to produce a single, complete, and up-to-date record of a particular patient. The system is even smart enough to see that records match even when some of the data in the records don't match.

The second part of the system is a user interface that reports records that might match, but that can’t be matched automatically. In this situation, the system needs some help from a "live operator standing by." Working with non-technical end users and providing them with awesome tools is one of the fun parts of this project.

When the system can’t resolve a conflict, the user interface alerts the health care professional and provides decision support to resolve the conflict. For example, when a baby is born, the hospital uses the father’s social security number as the baby's social security number on the birth certificate. Once common, this practice is now quite a headache for health care professionals later on, because the father and baby appear to be the same person. It's also a hard problem for the system to fix since the records of the father and baby may share the same data in many fields (like social security number and address), but the data in key fields are different (like name and birth date).

While there’s already a tool that lets a live human review these potential matches, it has many usability problems. It’s hard to tell what portions of a record don’t match. It’s hard to see information across more than one duplicate record (such as three systems all having similar, but slightly different data that could all be part of one person’s medical history). And it’s just plain slow.

These issues make it much harder for people to quickly and effectively handle records that the system can’t, and, in many cases, it takes much longer than necessary. Today, the people who do this work full-time print out huge lists of duplicate records and then spend hours reviewing the hard copies to make sure they’re matching the right information. The existing user interface could resolve these issues, but it doesn’t support their tasks well enough to be useful.

To be continued...

Wednesday Aug 08, 2007

Helping to Eliminate Mistakes in Medical Treatment (Part 1)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

I love design; especially when I get to work on something that can make a difference in the lives of everyday people. My latest project is just that: an interface design for a health care tool. It's not a nerdy tool like I normally get to work on, rather it's a tool for health care folks to use to ensure that when I (or you) go to the doctor, the doctor knows who I really am. This kind of information can prevent a blood-type mismatch or having a kidney donated, when I was really supposed to have my toenails trimmed. The cool thing is that this kind of design also can make a difference for every day folks; a group I don't usually impact directly.

The problem that we're trying to solve is keeping the records of a person's various medical treatments connected to each other. Several different systems all have a unique record of a patient that's pertinent to the system-owner's service (the doctor, pharmacy, or hospital). And even though there are really smart people putting information into these systems, well, mistakes can be made — things like hitting the wrong key, misspelling a name, transposing a SSN, that sort of thing — small mistakes that can have a large impact.

A colleague of mine had the same first, middle and last name as another girl, who went to her high school. Coincidentally, they also had the same birthday, one year apart. Unfortunately for them, they also went to the same primary care physician, which they weren't aware of until the other girl's medical charges showed up on my colleague's insurance. This kind of confusion over identity could cause a problem for one or both of them for anything from blood-type to allergies.

So, when I go to my doctor and I need an antibiotic, she should know from previous visits and my health care records that I'm allergic to penicillin. When I go to the pharmacy to get my prescription filled, their records of me would ideally be linked to my doctor's records and I won't get any substitutions for the prescription that would cause me to, say, die of anaphylactic shock.

Monday Jul 30, 2007

Blogging by Design

Nalini Kotamraju is a user researcher in xDesign, and a PhD in Sociology. She has a penchant for research methods and telling it exactly like it is.

Recently, I had a conversation with Anant Kartik Mithal, who is Director of xDesign (Software Experience Group) at Sun Microsystems, Inc. xDesign provides a wide range of design services for Sun's software products including visual and motion-graphic design, interaction design, usability reviews, user research, web development and assistance with accessibility compliance.

Nalini: Why launch Design@Sun, a blog by and about Sun's Software User Experience Group (xDesign)?

Kartik: xDesign does an incredible amount of absolutely fascinating design work. As I spend time talking to all kinds of people across Sun — designers, engineers, managers — I listen to the problems they're trying to solve, and the problems are simply fascinating. I think a lot of people inside and outside of Sun would be interested in them. It’s interesting to understand what problems people are solving and how everyone solves them differently. And it’s fascinating to see how people think through the solution process. Look at the design for Solaris’ start-up, for example. I would have done it differently. It’s wonderful to see an absolutely fantastic design that’s different than what I might have done. And the same goes for the work in the Tools space, in the Web Admin space.

Nalini: What kind of problems and solutions will Design@Sun cover?

Kartik: The designers in xDesign, for example, are looking at how we can turn Solaris into a modern operating system and what that means. How can we get the Solaris start-up experience to be fun? Something like start-up poses an interesting design issue. It’s something a user has to go through; it's not something the user necessarily wants to go through. This kind of design problem that’s a little different than those users encounter when executing tasks. If I’m using JavaFX to create an animation, I’m actually getting work done. But if I'm doing start-up and install, these are wasted steps. So how can you make them interesting for users? How can you give the user something back while they're happening? If you take our individual software products, they’re all very different. What we’re trying to do is be as similar as possible across our products. So if you learn to use one of them, you can learn to use all of them. That’s something we achieved in the productivity apps a long time ago, and we’re doing it in the admin apps now.

Nalini: What will people get from Design@Sun?

Kartik: We hope to share with our readers a bunch of interesting problems that Sun is trying to solve. A lot of our stuff is open source so people can follow along as it shows up and comment if interested. Sun is all about making our customers more successful and more productive. And design is all about supporting that.

Also, one of the things that some people have lost sight of is that Sun invests a great deal in its user experience. Whether it’s the hardware or the software. It’s very important to us. It’s very important to us that administrators are able to assemble and disassemble systems as easily as possible. That system administrators are productive with Solaris. That developers are productive with NetBeans. That everyone is productive with StarOffice. We want everyone to be productive.

We were at CHI this year, as we are most years. I was a little shocked when a few people came up to me and said that they didn’t know that Sun had HCI (human-computer interaction) professionals. Very prominent people in the field of HCI work at Sun. Sun has been very active in this field, and maybe this blog can provide people with a better idea of what Sun is doing in design and user experience.


xDesign is a software user experience design group at Sun.
Follow us on Twitter : Flickr : Blog (see feeds below)


« February 2017