First of all, I do not like to write.

Not just in English, but in any of the 3 languages I speak.

And for my fellow designers who do like to write (and are probably good at it), I have some bad news: no one likes to read specification documents. Even if the spec. is written in Tolstoy language, people prefer to enjoy Tolstoy language in a novel, in their spare time, and not at work, while developing or testing a complicated product full of hidden features and details.

So, I'd rather name my entry "How do I create my UI specs".

This is what a typical page of my spec looks like:

I use mostly Fireworks and Dreamweaver. I create my images (wireframes or mockups) in Fireworks, then place the image into a pre-made HTML table. The table consists of a nest for an image on the left, and an annotations column on the right.

UI Spec sections that I cover in my annotations column are the following:
1. Page Details: (project name, file name, release #, dates, version, designer name, and page type). Seems like a lot, but some of our products have very similar pages, and spec readers tend to print or bookmark one page here and there, and then have a difficult time recognizing the page they are looking at. By dedicating the top portion of annotations to housekeeping, I make this info always accessible, yet not in your face, so to speak.
2. User Scenario: here I indicate how the user gets to this particular page. Usually by performing an action on a previous spec page, or by opening an application, or both, so there could be several scenarios, and I believe it is necessary to mention all of them.
3. Interaction Rules: The most important part of the spec, of course. As you can see, the wireframe/mockup image is covered with numerous geometric shapes of different colors. These are snippets.

I drag a snippet from the Snippet Panel, give it a number (or a letter), and place it next to the component I'm about to describe in Interaction rules. Note, snippets live in HTML, and NOT in png world. I am not changing the image. Think of it as a sticker. If I have to change the button placing for example, I do not have to redraw the indicator in my png, just simply move the icon when I'm in Dreamweaver. Basically, my images and annotations live in different castles, which is quite handy for editing.
The fact that I place my annotations to the right of the image, makes it very easy to scan and find the appropriate number. If the spec reader is looking for the description of a particular component, he just has to find the right number in the Interaction Rules column and ignore the rest of the information.
4. Page Revision Details: I keep this section to indicate the changes that have been made during numerous revisions of my work. I also use this section to call out uncertainties and TBD areas that need my spec readers' attention. The icon for this section is a lettered blue triangle.
5. Notes: the least visible section - I keep the notes for myself here.

That's for the UI Spec sections.
Of course, there is an index page of all the pages in the spec, a brief description of the project, and special messages to the reader. I sometimes interlink the pages, especially if they are consequent steps of a particular use case.


If some of your spec readers can't access the spec online, you can always create a pdf using Acrobat. It is super easy: choose 'Create PDF doc' > 'From Web Page' > 'Entire Site'. If you are planning to create a PDF, don't forget to name your pages appropriately. Actually, even if you're not planning to create a PDF, still name your HTML pages appropriately - it's like good table manners.

Oh yeah, I use bright orange circle icon to indicate where the text had been changed: we all know that text changes come last, and developers appreciate it if I tell them exactly where they need to retype.

I think that's pretty much it, leave comments if you want to know more.

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

Recently I've been noticing a bit of difficulty among my peers at Sun, as well as other friends I have in the business of design. It seems somewhat widespread that creating good designs, and then having them correctly implemented is a bit of a battle. It makes me think about how leaders of unpopular political resistances must feel as they fight for their position. Speaking their minds, and deploying their Guerrilla fighters to lead the resistance. And here I am, on the side of the Usability Resistance, trying my best to convince the people, overthrow the "usability want-nots", and keep my Guerrillas fighting the good fight.

Guerrillas...

This reminds me rather of a method I and my team have used in the past to design user interfaces. I call it "Guerrilla Interaction Design". It's a way of creating usable GUIs quickly, under pressure (and sometimes under fire). To describe it properly, I should outline a more conventional user-centered design timeline just for reference - which goes something like:

1. Talk with your local, handy-dandy product manager about what they'd like create as a new program, or what they'd like to do to improve an existing one.

2. Get out of the office and go observe users doing what the new program might do, or using the existing one.

3. Figure out what might meet their needs, or improve the experience.

4. Go back to the office and document what users are doing today, and what might be an optimized way of doing it in the future (or possibly what they really need to do).

5. Draw some pictures and create a story.

6. Discuss this with the folks from step 1, and iterate, iterate, iterate.

7. Iterate.

8. Create a paper storyboard, or medium fidelity prototype that someone could review or use to attempt the task with the new, optimized design.

9. Go back out to the field and usability test the design with similar (or the same) users. Observe and document the results and then...

10. Iterate.

11. If you're lucky, all the rough edges are smoothed out and you have a design that delights the users, makes the product manager happy, and is possible to implement by the developers.

12. Deliver your design, and remain "on-call" for potential "gotcha's" that may come up and need quick decisive design action!

Whew! That's a lot of steps! It approximates what most designers might tell you when explaining how to produce a good design, and is a pretty consistent and standard way of achieving a predictable result.

Now... do it in three days...

To be continued...

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.

Again, I have a question for you. I have tons of unused Sun swag to exchange for my favorite answers -- a Java gym bag, a Sun CD case, a Sun coffee mug, a desk clock, a laptop bag ... too much to list. Send me a great response to my question, and I'll let you pick.

Here's the thing ... we all have mobile devices: cell phones, laptops, PDAs, nav systems, pen tops, tablets, hand-held game consoles ... and they all provide some value to us. That value may be access to a resource, the ability to perform a new task, the ability to perform an old task in a new way or at a new location, entertainment, productivity, connection to our friends, immersion, or escape.

So in my mind ... I have a vision ... if I took all the functionality of all those disparate devices and combined it with all the benefit that I get from my non-portable devices (for example, my SunRay, my iMac, my cable box, and a Wii) I know what it would look like and what it would do for me. I imagine it every time I look at the iPhone. I want it not only to supplement the cadre of devices that I already have, I want my next mobile device to replace them. All of them.

But I realize that, along many axes, I am not in the majority. As desperately as I want an iPhone, I just refuse to buy one until it meets some of my other demands.

So my question to you is ... when you dream of the mobile device that you wish you had, how is it different from what is available now? Write me your answer in email: jenm at sun dot com.

Leon Barnard is an Interaction Designer in xDesign, who is working on SOA/BI and NetBeans products. He recently moved from Los Angeles to Prague and is enjoying Czech food and not needing a car.

My job as an interaction designer is to create designs that help users accomplish their tasks more quickly and/or more easily. Sometimes this is done through surface-level changes like adding emphasis to frequently used actions, adjusting spacing and layout, or by using clearer instructions. The most successful projects, however, often involve taking a very complex task and changing its components so that achieving the desired result becomes less complex. This is much more difficult to do, yet more fun and rewarding. I was recently tasked with making the development and design of WSDL files easier. Since the task is so complex, I wanted to try to devise a better way of accomplishing it that would help novices learn the technology, as well as help experts focus on what they care about most.

WSDL ("Web Services Description Language") is a complex language used to create web services. Web services are computer programs that can be used by many different organizations or individual programmers, to perform a function they can’t perform themselves or perhaps that they don’t want to try and recreate themselves. An infinite variety of transactions and queries can be conducted quickly and efficiently without requiring any special software or network configuration. WSDL has a standard format for taking a request, processing the request, and then providing a response to the source of the request. The processing part is where a company, like Google, would provide its program’s function (called a “service”, or “web service” in this world). While the format is standard and predictable, it’s also created with the computer, not the human, in mind. So the syntax is relatively complex and unintuitive for most less-than-expert folks.

These characteristics of WSDL syntax distract users from their primary task and add confusion, especially for novices. The precise 'what', 'how', and 'where' that the user is concerned with takes up relatively little space in the code. Ideally, this content would take precedence, and the rest would go to the background or, even better, be handled "behind-the-scenes" automatically.

Our design addresses these issues. The biggest change that we made to the existing editor was to move to a more visual, connection-based presentation. In this way, users can see, even at a glance, which pieces were connected to which, allowing them to follow the stream of connections across the file. It prevents errors of mis-typing the names of objects to be connected, because creating a visual connection automatically writes the appropriate code for the user. Next, the core 'what', 'how', and 'where' elements are represented as salient visual objects that draw the user's attention, while the container objects are shown simply as dotted lines surrounding their contents. These visual representations allow users to easily see what they care about most, yet also understand how they are grouped. Finally, some workflow improvements were added to train novice WSDL users and save time for both experts and novices. These include: dragging-and-dropping from a palette, previewing valid drop locations, automatically creating objects and their containers (if necessary) when a connection is made, prompting for necessary configuration information when certain types of objects are added, and being able to collapse groups of objects that are not being worked on, among others.

In summary, the new design offers the following benefits:

• Uses a flow/connection-based model for visualization.
• The focus is on the meaningful elements (not the "container" elements).
• Follows the principle of "recognition rather than recall".
• Drag-and-drop for faster and more intuitive use.
• Multiple steps can be performed at once.
• Is more discoverable and approachable for novices.

Here are some more snapshots of the new design:

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.

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...

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.

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.