Tech Savvy Designer

Goal-oriented Prototyping

2011-09-12T06:43:00.000-07:00

I have moved my blogging attention over to the MQ blog at blog.macquarium.com. Please see my 2-part article on Goal-oriented prototyping there. In it, I discuss when prototyping can be used as a valuable tool in the design process and how to choose the appropriate tools and fidelity for your prototype based on your goals.

You love to hate them - UI specs!

2010-07-08T18:04:00.000-07:00

User interface specifications can be a tricky undertaking. Over the years, I have written them to many degrees of detail and have, more often than not, been disappointed with the end result. There is a very delicate balance between *enough* information and *too much* information. The appropriate amount of detail is very dependant on the audience. I still haven't found that perfect balance, but here are some lessons I have learned along the way.

The Audiences

Offshore teams often need more

Let's just be realistic. We're talking about both language and cultural differences here, so it's important to be concise. I have worked primarily with offshore teams in India, but also in Russia and other countries. Ambiguous documentation can lead to scores of questions (and thus development delays) and/or an end product that does not meet the design intent or business expectations. As I understand it, many offshore development teams tend to fluctuate in both size and members to meet project deadlines, so there are a lot more people to communicate to with the documentation. It should be presumed that the development work will be split up such that at least some percentage of the resources do not attain accumulated project knowledge.

Americans hate to read

I'm American and resemble this remark when it comes to dry documentation like UI specs, so I can get away with saying this. Heck, I hate to write them even though I appreciate it as a necessary evil in many (not all) cases. So, here we have exactly the opposite problem that we may experience with offshore teams. The lengthier and more thorough (and textual) the document, the less likely it is to be read and followed. Does this mean that the text is unnecessary? Not remotely. Without the specifications to force consistency, it is likely that if you have 12 different programmers coding your screens you will get 12 different results. Some prime areas for inconsistency without a spec are: overall screen layout, form field orders, methods of handling form validation, wording of error messages, placement order of buttons, behavioral aspects such as hover and click states, etc. These may seem like minor things, but they can collectively have a large impact on usability and the perceived quality of the end product.

Playing telephone

I have worked with some teams with onsite leads and offshore development teams. This actually seems to work better than having an entirely offshore team since the local lead can help with communication, but can become a game of "telephone" where the message gets increasingly less accurate as it moves down the line. So, the need for documentation is no less under this structure, but it can take some of the onus off of the user experience lead in educating the development team.

Client stakeholders love/hate it

This is beginning to sound like a rant... and maybe it is a bit... but here is yet another audience inconsistency. I have had clients that love, love, loved the level of documentation that I provided and others that thought it a complete waste of time and literally asked me to somehow turn a 80-page spec document into a 2-page summary. With screenshots. You may gape now.

Leaving a legacy

Yet another audience to consider is the one that doesn't exist yet - the future design and development teams that will perform maintenance and add features to the product. These teams must understand the original design intent to ensure the consistency of the user interface as it evolves over time. I have never actually had the opportunity to speak to this audience to find out how they felt about my documentation, but I would guess that they either love it or completely ignore it.

Some Tips

1. Play nice with others

Decide who will document what

It's helpful to reduce repetition of the UI requirements as much as possible as this can lead to further inconsistencies and time burned in deciding (or arguing over) which document is correct. If you have a full project team which includes Business Analysts, User Experience Architects, and Technical Leads, it's important to decide which requirements are going where before anyone starts writing. My personal preference is something like this:

Functional Requirements and/or Use Cases
Maintained by the Business Analyst and should contain all of the business and high-level functional requirements. These should *not* contain user interface or technical requirements. Side rant: I could - and maybe will - write a whole article about how to write requirements and use cases without specifying UI.

User Interface Specifications
The responsibility of the User Experience Architect and should contain all user interface specific requirements such as design patterns, field lengths, form field orders, button locations, interactions and behaviors, state change transitions, etc. If it pertains to user interface behavior, usability, or visual design, it should be here.

Technical Specifications
These should be written and maintained by the Technical Lead and should contain specifics on technical implementation of both the business and UI requirements. Unfortunately, in my experience, documentation of technical requirements often falls off of the project radar. I think that it is very important for establishing coding consistencies on a development team - including technology platform, project structure, naming conventions, data management and error handling - just to name a few.

Decide what level of documentation is needed

You may still have some variation of the documents listed above at different degrees of detail. Depending on what else is happening with the project, you may not need quite as much detail. For example, if the User Experience Architect is working directly with the development team and delivering the front-end code, the UI Spec may not need to contain every aspect of the desired interaction. The field sizes, orders, and even some of the behaviors may be provided in the front end code so may not need to be documented. But don't forget about the QA team - they may be a consumer of the user interface specifications as well. I recommend following this rule: if it needs to be tested, it needs to be documented.

Present the UI to the development and QA teams often

These are really mini training sessions where you walk the development and QA teams through sections of the UI to ensure that everyone has the same initial understanding of how things should look and behave. This doesn't make documentation unnecessary, but should help to ensure at least a baseline understanding so that if the documentation is not consulted as often as it should be, the results will still be better. It also gives those team members an opportunity to ask questions and thus help you to make sure you haven't left anything important out. The earlier the Tech and QA leads are involved, the better. The Tech lead may be able to recommend user interface behaviors that are easier to implement which would still provide a good experience.

2. Simple and thorough at the same time

Be as visual as possible

A picture is worth a 1,000 page spec document.

Split things up

Come up with a logical divide for your specifications so that everything isn't in one huge document. I have found that splitting the documentation up into logical feature sets work best. This also seems to be how development teams commonly split up the work, so it works well for that audience.

Use bullets rather than paragraphs

Be as succinct as possible with specifications - bullets are great. This allows the reader to scan the details very quickly.

Use design patterns as much as possible

This is a good idea from a usability perspective as well as in documentation. The more consistency the user interface has, the more usable it will be. I have had the motto for a long time that even a bad user interface design can be usable if its at least consistent so that it can be learned. If you use design patterns, you can limit the amount of necessary screen-level specifications.

Find ways to limit updates

This one can be difficult in a fast moving project. I recommend reviewing the documentation thoroughly (maybe even a third-party review) before you deliver. This way, you will hopefully catch at least most of the holes before you pass it on. When you do have to make updates, make sure that they're communicated in detail and find ways to highlight them in the document so that the downstream team members can easily find them.

Keep cross-referencing down

Even if you have the same form field appearing in multiple screens, it may at times be necessary to copy the specification throughout the documentation. This sucks for you and there is more risk of creating discrepancies, but but it may be better for your audience. If they are constantly having to shuffle between documents to find all of the specifications they need, they're less likely to stick to them. And who can blame them? What a pain!

3. Do it yourself

The most successful projects I have worked on with the most consistent and highest quality results have been those where myself and my team has actually created the front end code. This is perhaps a bit controversial in the UX world and I agree that not everyone in the UX role will have the skills necessary to do it. I am a bit of an anomaly in that I started as a programmer. However, this can still be accomplished by including one or more front end developers in the UX process and developing the code as you design.

One advantage to this approach is that the UX designer as a front-end developer tends to be more passionate about design consistency. I have also found that it allows me to work out issues that would require some amount of rework if it got to a development team first and had to come back to the design team due to technical constraints. Having a front end developer working with the UX team and doing proof-of-concepts along the way could also mitigate this risk.

If your UXA doesn't have the front end coding skills and you just can't include a front end developer in the UX process, I think the best fallback strategy is to use a prototyping tool of your choice (could be as simple as wireframes) to draw out the intended behaviors in as much detail as possible. If you can make it even *seem* to work, you may be able to get across the intended behaviors without a lot of textual explanation - which is far too open to interpretation.

Facebook Brand Pages

2010-04-28T19:05:00.000-07:00

So I thought I should probably bet this out there before they change everything about Facebook fan pages. Should I even continue to call them that? What are they now... LIKE pages? That just sounds... like... 80's valley girl? Maybe they will evolve to be known as "brand pages". In any case, I think that this content is still relevant. These are some tips and lessons learned that came out of my first foray into designing a Facebook page for a client.

The page was for the Realize Adjustable Gastric Band (http://www.facebook.com/realizeband if you're curious). Perhaps the most notable thing about this project was that it was for a medical device for bariatric surgery - so, a heavily FDA regulated surgical device. Due to its nature, one may not think that a social networking site is a natural fit and it certainly created lots of interesting challenges when considering how to make something "social" when it would have to be monitored so carefully. Shortly after the launch of the Facebook page, I also designed a YouTube channel for the client which gained the attention of AdAge for just this reason. Read the AdAge article here: http://adage.com/article?article_id=137726 .

In any case, I think that these tips may relate to a lot of other brand pages (I'm coining the phrase now... if it hasn't already been done). Most are around content update strategies and frequency. I hope that you find some useful nuggets in here.

Content & Updates

Facebook users tend not to revisit Facebook pages unless an update is broadcast. Also, many new fans come from the "sharing" done by existing fans. Thus, some serious thought needs to go into content and update frequency to ensure the continued success of the page.

Types of Content Updates

Status Updates
Depending on the relationship that the company has with its customers, it might be a good idea to keep simple status updates to a minimum except where they will be meaningful to the audience. For example, a small company in which the owners have a personal relationship with customers might get away with frequent friend-style status updates while a larger company might reserve these for important messages only.

Links
Posting links as opposed to simple text-based status updates can be a better way to communicate and to drive Facebook users to the brand's other web properties. Facebook will automatically pull available thumbnail images and metadata from the link URL to create a link description or the description can be manually entered.

Events
Events do not automatically broadcast updates to page fans. Administrators can choose to invite fans specifically to the event or broadcast a message to fans about the event. A message can be targeted to local fans by country/state/city.

Photos
Photo updates will be broadcast to fans by photo album and date - one update per album/date combination. So, if the administrator adds 3 new images to a single photo album in the same day, fans will only see one update in their streams. Note: photos on fan pages *can* be tagged, but the tagging options consist of the administrator's friends - not fans of the page. The resulting broadcast will also be to the administrator's friends instead of fans.

Videos
Videos work similar to photos except that they are not contained within an album. Each video upload will appear on the page Wall tab and trigger a broadcast to fans.

Notes
A truncated section of a new note will also appear on the page Wall tab and broadcast an update to fans. This is a great way to communicate longer, more meaningful content than what might be posted as status updates.

Update Frequency

The frequency with which a brand should (or can) broadcast updates is highly dependent on several factors:

How close is the brand with its customers?
How compelling is the content of the updates?
How quickly can the maintenance team turn around new content?
How stringent is the brand's approval process for content?

Update Strategy

It's a good idea to develop an update strategy for a Facebook page prior to launch. Determine the types, frequency, and topics that will form updates for at least a few months out. The early updates should target increasing the fan base with later updates both increasing and retaining fans. Other marketing objectives may be tied in as well, such as external links and conversions. As the updates take place, the fan activity can be monitored to determine the effectiveness of the strategy, which can then lead to adjustments over time.

Lessons Learned

Be prepared for unexpected changes

Facebook changed its format for fan pages twice during the release of the aforementioned fan page. Due to the stringent design and content approval processes required by this client, this set our timeline back a bit. There was little warning and no clear definition of what the changes would be prior to the switch. Also, due to the nature of Facebook, updates can happen at any time during the life of a page. Administrators should try to keep abreast of possible changes coming and be prepared to react quickly should they occur without warning.

Promote the fan page

Facebook is not really a "if you build it, they will come" kind of thing. Depending on the type of product and its relationship with consumers, fans might find it by searching for it on Facebook, but most initial fans will find the page either via advertisements or links. Once an initial fan base is established, it will become more viral and there will be less need to drive links.

Here are some ways to get an initial fan base established:

Put a Facebook icon/link on all other brand web properties
Send press releases or emails to customers notifying them of the Facebook presence
Encourage employees and vendors to become fans of the page
Purchase external banner or search advertising
Advertise within Facebook
Create viral Facebook applications that link back to the fan page

Have some future content ready to go

Unless there is a resource tasked to create content for the brand page on a full-time basis, it might be helpful to create a large batch of content up front which can be posted as updates over time. Even a single post per week can be difficult to keep up with.

Monitor page and fan activity closely

Watch for these in particular:

Are you seeing fans remove themselves? If so, it is most likely that you are either posting updates too frequently or the content of the updates is not meeting your fans' expectations.
Fans posting inappropriate comments or "spam". If you have a page that allows commenting, you might need to create a strategy up front for dealing with these issues as well. Maybe the brand wants to be seen as more "honest" by allowing negative posts, but remove offensive posts and spam.
Fans requesting content. Try to meet these requests when appropriate. The fans will love you for it.
Fans requesting customer service or supplying product feedback. This may become an unexpected conduit for customer service and it may be very important that customers see that the brand is responding quickly and positively to the feedback. Be sure to create a process for handling of this feedback to ensure that the response is timely.

User Comments

Under normal circumstances, user comments cannot be disabled by page administrators. If there are special circumstances (such as FDA regulations), Facebook must be reached and must disable commenting on the back end before the page is published. Facebook will require proof that the product is FDA regulated. Having commenting suppressed on a fan page does not carry over onto standard applications that are included on the page.

Further Reading

A Facebook Campaign That Connected

How Adobe used Facebook to connect with students and spread awareness of student software discounts.

5 Tips for Optimizing Your Brand's Facebook Presence

Facebook API for Flash/Flex

Tutorials and code references for building Facebook applications using Flash or Flex.

Facebook Developer Wiki

Tutorials and code references for building Facebook applications (web-based, desktop, or mobile).

Facebook "Fan Box" Widget

A widget that can be put on any website to help drive traffic and increase fans on Facebook.

How To Develop A Facebook Page That Attracts Millions of Fans

Wordpress Email on CrystalTech

2010-04-27T14:32:00.000-07:00

I have an older CrystalTech hosted site and had a bear of a time trying to get WordPress emails working. I thought I would share the steps that finally brought me success in hopes that someone else may not have to spend so much time as I did sorting it out. I know that this is not the only method of skinning this cat and from what I have read, you may not have this problem at all if you're on a newer CrytalTech server. For everyone else...

1. Download the WP Mail SMTP plugin, upload it to your server and activate it via the Admin panel.

2. Log in to your CrystalTech Control Panel and go to Site Overview. Find the Mail Servername and copy it. You may also want to set up a new email address on your domain, but you may use an existing one. If you need to set up a new address, go to Mail > Log in as Admin in the control panel to set up a new email address.

3. In the Wordpress Admin site, go to Settings > Email:

From: Your crystal tech email address (youraddress@yourdomain.com)

Mailer: Send all WordPress emails via SMTP

SMTP Host: Use the Mail Server name you copied from your CrystalTech Site Overview like this MailServerName.webcontrolcenter.com. It will look something like this: MailA11.webcontrolcenter.com .

SMTP Port: 25

Surviving the UX Interview

2009-04-06T13:21:00.000-07:00

I have been debating for a long time about writing this and posting it on my blog. I do a lot of interviewing for my employer and I was afraid that if a candidate found this, it would give them an unfair advantage. But then... I decided that if someone is smart enough to research me before an interview and finds my blog, they *deserve* to be better prepared, right?

In the current economy, with so many people unemployed, it is more important than ever to show yourself as the best possible candidate in an interview. The User Experience profession is thriving, but the employee pool is fairly deep right now and most companies are being conservative with hiring, so if you don't stand out, you might remain unemployed. So, here are some tips and things that I personally look for when interviewing potential employees. Some of these may seem obvious, but these suggestions are coming from things I've encountered in actual interviews, so maybe they're not as "common sense" as one would think.

1. Be prepared
All of the subsequent tips in this article really fall into this category. As an interviewer, I spend time preparing for every interview by reading through the resume, reviewing any portfolio pieces that have been supplied ahead of time and even Googling or using LinkedIn to research the interviewee's background. I try to prepare specific questions based on what I find in my preparation. I expect the same or an even greater level of preparation from the candidate. There is absolutely no excuse for being unprepared.

2. Be alert
If you're not a morning person (and you have a choice), try to schedule your interview during the time of day when you're usually at your sharpest and most productive. If you sound or look like you are half asleep, I'm going to assume that you're not terribly interested. I have performed at least one phone interview during which I was wondering if I the interviewee had just been napping before the call. Not good.

3. Dress appropriately
You don't have to wear a suit and tie. In fact, I appreciate seeing a bit of individuality in interview attire - I relate it to creativity. However, you should be dressed as you would dress for visiting a client. In the consulting world, we spend a lot of time in front of our customers and it is important that we look the part.

4. School your nerves
Several years ago, I had a very memorable interview with a young man who was sweating profusely and shaking so uncontrollably that I couldn't understand much of what he said. I felt so sorry for him and was wondering to myself the entire time, "Am I really that scary?" Granted, this is an extreme example, but I still think that it's a good idea to try to calm yourself before an interview. Remember that it is as much about you interviewing the company as it is about them interviewing you. This might make you feel more confident so that you can be relaxed and assertive.

5. Be conversational
Maybe this is a personal preference, but I really don't appreciate the "sales pitch" or any approach that feels forced or fake. I prefer honest, candid, well-thought-out answers given in a conversational tone. I'm usually most impressed with interviews that feel more like a peer discussion with questions coming from both sides. Even though this may seem like a more casual conversation, however, make sure to watch your language. I will expect you to talk to me as you would talk to a client. So, if you're dropping F-bombs in the interview, I expect you will do the same with a client... which is not good.

6. Prepare answers to common questions
You might not know what the interviewer will ask specifically, but you should be prepared to answer some common questions. A couple of examples:

Please tell me about yourself.
I often start an interview by asking the prospective employee to tell me about him or herself. I'm really looking for a brief outline of your past employment history and your current interests and career direction. The specific questions I ask later can be leading, so I want to see what you say without those "clues". I would recommend spending a bit of time thinking out what you might say to this question. How can you highlight your background, skills and career goals within 2-3 sentences?

Show me some of your work.
You might have a huge portfolio, but pick out 2-3 pieces that you would consider your best work and be prepared to describe them in detail. Include information such as how you worked with a team to create the end product. This is often more important than the work itself. If you're more of an Information Architect, you don't need to supply visual designs. Bring copies of some wireframes you've done. If you're more technically skilled, you might bring code snippets or example functionality that you've coded. In the latter case, bring your own laptop and have the examples loaded locally just in case you can't get an Internet connection. Be creative in coming up with ways to portray your work through examples.

7. Do some research
Research the company, the interviewers (if you have names), and anything you can pick out of the job description. For a UX professional, you should have some depth of knowledge about visual design, information architecture, usability, at least a couple of web technologies (HTML/CSS, RIA, JavaScript, Flash, etc.), standard documentation, and standard software development processes and methodologies. It's ok to be weak in one or more of these areas, but it's not ok to be completely unaware of them. Here are some examples of questions that I often ask in a UX interview:

What are you an expert in?
Visual design, usability, information architecture, HTML/CSS, Flex, Flash, illustration, content management, requirements gathering, software development process, art direction, leading a UX team - all good answers, but be prepared to elaborate.

How have you earned these skills?
Formal education, self-education (mention specific books, courses, certifications, etc.), or experience (again - use examples).

What do you think is the #1 principle or attribute of a usable interface?
My own answer to this question would be "consistency". I believe that even a poorly designed interface can be usable if it's at least consistent so that it can be learned. Whatever your answer is, it should be something that impacts the entire user experience.

Do you think that visual design impacts usability? How?
This seems to be one of the more difficult questions for most candidates, but it really tells me a lot about how much thought they put into usability and design in general. Mostly, the answers that I get involve aesthetics, which, alone, have little to do with usability. However, visual design can make content legible or divide up information or functionality. More importantly, it's great for hinting at behaviors to set user expectations (something is clickable, draggable, resizable, etc.) and providing navigational clues (selected, deselected, or disabled states). And this is only scratching the surface.

What software development processes/methodologies have you worked under?
Waterfall, Agile, other - I basically want to see if you know anything at all about process. We always follow some level of process; be it our own or our client's. We are also often required to recommend processes that will result in a high quality end product.

What design process do you typically follow? What are your deliverables?
I expect to hear some combination of these words in answer to this question: design comps, wireframes, sitemaps, design guidelines/patterns, usability studies, prototypes, user interface specifications, use cases.

What document or deliverable do you think is most valuable? Why?
This is a follow-on to the previous question in which I usually get more detail about what the candidate is communicating in his/her deliverables and what he/she thinks is important.

What deliverables do you expect from other team members as input to your design process?
This is another question designed at finding out how familiar the candidate is with standard software development processes. I expect to hear words such as: high-level or functional requirements, user personas, use cases, and technical specifications. Note: some of these may be generated by the UX designer and that's a great answer too.

What kinds of teams have you worked with? What was your role? Your team members' roles?
Yet another question to gauge software development process experience. I'm hoping for candidates who are familiar with working with Project Managers, Business Analysts, Technical Leads, Testing/QA Leads, etc. I also want to know if the designer acted as a "pixel pusher" on those projects or had more of a lead role in designing the software.

What gets you most fired up when working on a UX project?
I ask this question mostly to learn what the candidate most likes to do. What someone most likes to do is often also what they are best at.

Are there any new areas (technologies, processes, team situations, etc.) that you haven't had a chance to work in but would like to?
The answer to this question tells me where the interviewee most wants to go with their career and how much they think about it. Interestingly, a lot of the candidates seem to base this answer on the questions they think they failed to answer appropriately from earlier in the interview.

How do you handle criticism?
Please refer to my last article: Criticism is your friend

8. Be honest
If you don't know the answer to a question or don't have experience with something in particular, say so. If you're being interviewed by a peer, as you would be with my company, they are going to know if you try to BS your way through an answer. Not that I'm suggesting offering up all of your weaknesses at the get go, but don't be afraid to admit weaknesses in certain areas while playing up (but not exaggerating) your strengths.

9. Ask some questions
You should be interviewing the company as much as they're interviewing you. What is important to you about an employer? What type of work do you want to do? I recommend giving this some thought and preparing some questions ahead of time to help you to determine if the opportunity is a good fit for you and your career goals. Also - I'm always a little underwhelmed by the candidate who asks no questions when I offer them the opportunity. Are they too inexperienced to know what to ask? Do they just not care very much what they do or where they work? Are they just planning on pulling a paycheck as they would if they took a job at Starbucks? Are they so desperate that they will take anything?

You should come up with your own questions based on what is most important to you, but here are a few examples that might help to get you started:

How many employees does this company have?

What are the work hours? Are they flexible?

Are employees expected to travel or work at the client site? How often?

Are there any education or training benefits?

Are there opportunities for career growth?

What is the working environment like? Could I have a brief tour?

10. Follow up
If you had either a very positive or very negative response to the interview, you might consider mentioning it right at the interview conclusion. "I think my skills and career goals align well with this position" or "I'm sorry, but I don't think that I am a good fit for this opportunity." If you do think you are a good match, you can ask the interviewer when they plan to fill the position and who you should contact for follow up. In either case, a thank you note to the interviewer would be appreciated and end the relationship in a positive way (if it is, in fact, the end). Never burn bridges.

I know the old way was to send a formal letter on fine stationary for a thank you note, but for me, an informal email is just fine. If you're in doubt, I don't think it hurts to do both. Just make sure they don't sound exactly the same - you can go into more detail in the letter format.

Criticism is your friend

2009-02-17T14:08:00.000-08:00

I have, in the past, taken professional criticism poorly. I was very quick to become defensive when someone provided feedback about my design work. I think that this is common for designers with a little less experience and a lot to prove. Over time, I have learned that this is a detriment to both my business relationships and my personal and career growth. It's ok to defend your design, but it's not ok to be defensive about it.

I still sometimes have the urge (and occasionally even act on it) to immediately jump to the defense of a design without thinking. This might happen particularly when, for some reason, I do not give due respect to the source of the critique. It might be that I think that the person providing the feedback has bad taste, a poor since of usability, is out of their realm of expertise, or just plain doesn't like me. It's even more likely that I'm just too in love with my design to consider its flaws. Does this mean that I should just instantly disregard what they have to say? That might be my first inclination, but if I really dig deeper, I might actually learn something and improve my skills in the long run. And let me tell you from experience... it's much more difficult to go back and say, "You know... when you gave that criticism three days ago and I bit your head off for it? You actually had a point..." than it is to force yourself to step back and consider it immediately before responding so inappropriately.

I think that a designer's ability to take criticism and effectively use it to improve their work is a clear sign of their maturity in the field. When interviewing design candidates, I often ask questions targeted at this subject specifically. I want to know that they can take criticism without getting defensive, but also that they know enough to analyse it beyond the words.

For any good designer, there is often a reason behind just about everything - from the color palette usage to the button placements. These might be consciously considered during the design phase or they might be intuitive. I personally tend to be a more intuitive designer. So, my subconscious had a reason for doing what it did, but I might never have consciously thought about it. In this case, if I jump to defend my design against criticism without giving it some thought first, I might completely miss the point and thereby render my arguments useless.

Every single piece of criticism received, no matter the source, should be considered as objectively as possible. Does this mean 'design by committee' is a good thing? Absolutely not! I agree with everyone out there - this is a bad practice. However, if you consider the *reason* for the criticism as opposed to taking it at face value, you might be able to improve what you've done.

Here are a few rules that I try to enforce on myself when handling criticism:

1. Don't take it personally.
It is definitely hard sometimes, but this is the first step to avoiding a defensive response. Even if the comment is made in a derogatory manner, try to consider it objectively. It's not about you.

2. Try to separate the comment completely from the person who provided it.
Not that a person's perspective and motives shouldn't be considered, but that will come later. It might be best to try to analyze the comment without the baggage. This will help to make sure that you're not dismissing a comment out of hand because you believe that it is unworthy of your consideration. There is no comment that is unworthy of consideration - even if it's provided by someone without experience in the subject.

3. Look beyond the words.
Did someone say that they thought the border should be purple instead of orange? Don't just say, "Ok" and change the border to purple, but try to consider why they said it. Is the orange border distracting their eye away from the more important content? Is there an imbalance in the color palette such that there is simply too much orange in the design? Maybe it's really as simple as the person thinks purple would make a better border color, but I find that to rarely be the case. And taking the time to think about other possible interpretations of the comment may help you to find other areas for improvement.

4. Consider a different perspective.
Everyone is looking at their work through the veil of their own preferences, experiences, and expectations. You might see it differently if you can look at it through someone else's veil. Try to consider where they're coming from and place yourself inside that mental model to view the design differently.

5. Defend your design where it bears defending.
Was there a good reason for doing what you did? Great! Explain it. Say someone wants you to move the button from the lower left part of the screen to the upper right. Maybe having it on the lower left is consistent with all of the other screens on the website. Maybe it's a usability concern. Try to articulate what you may have done by pure intuition. And if you didn't have a good enough reason or their idea is simply better than yours, accept it and move on.

6. All criticism is good criticism, but it's not all valid.
If, after going through the due diligence of considering the comment from every different direction possible (and asking follow-up questions to try to understand it better), you judge that it's invalid, let it go (if you can). Did that person want a purple border just because it's their favorite color, but it would upset the branding and throw off the balance of the design if it was implemented? This is where we can avoid the 'design by committee' issue. The designer *should* have the final say (or maybe an Art Director, depending on the project structure). But what if the person who wanted the purple border is the one writing your paycheck? Well, you might first try explaining why the purple border is a bad idea, but you might have to implement it anyway.

7. Be confident.
Just because you don't always achieve the 'perfect' design out of the gate doesn't make you a bad designer. I think that what really makes a good designer is someone who can communicate, listen, and analyse all aspects of both the design challenge and the criticism to create the best final result. I will personally continue to strive to be a good designer in this context.

RTFM? I don't think so.

2009-01-24T10:47:00.000-08:00

My husband is always telling me to "RTFM" (read the freakin' manual) whenever I'm fiddling with a new gadget or software. My response is usually some variation of, "But I shouldn't have to!" This is also my philosophy when designing user interfaces. The ultimate goal is to design an interface in such a way that the user intuitively knows what to do rather than to force them to either fail, go through training, read help documents, or some combination thereof.

The traditional web application method of form validation was to wait until the user filled out the entire form and clicked a submit button and then let them know what they did wrong. The validation errors were generally provided with a popup menu - either a single error per submission or a list of errors throughout the form. This method posed several problems, but two major ones. First, the user was forced to fail first and then follow an "exception flow" to correct the issues. Second, the user could not see the error messages while correcting them since the dialogue had to be closed before the user could return to the form.

In more modern web applications, the second of these issues has been corrected by providing "inline" validation error messages. So, the user still has to click submit first, but the error messages are now displayed on the screen near the field, at the top of the form, or both. This is not a bad way to handle form validation, but still doesn't solve the first problem in which the user is being forced to fail before provided with the information necessary to complete the form successfully.

A second more modern method of validation error handling is to provide the error message as soon as the field loses focus. This is also a good way to handle the feedback and at least provides the user with an immediate response, but I don't think that it is the whole answer. The focus should be to PREVENT failure in the first place so that it truly becomes the exception instead of the rule.

To be honest, I do not think that many of my projects have come close to achieving the level of intuitiveness that I think they should. Not to say that the interfaces that I design aren't generally intuitive, but I almost always have to stop short of what I would consider a truly ideal solution. So, what is "ideal"? Since this could be a huge topic, let's narrow it down to form-based data entry. Here are a few goals I would work towards when designing a form:

Provide input such that the user knows intuitively what to put in each field to help prevent them from making mistakes.
Provide minimal help/instructions only when absolutely necessary and make them as visual as possible.
Let the user know immediately if they have made a mistake.

Providing Instructions
We often want to provide the user with instructions in attempt to achieve goal #1, but this may sometimes be complicated by goal #2. Providing TOO MUCH instruction can be just as bad as providing too little. If you provide instructions for fields that the user already knows how to fill out, he/she may not read the more important instructions for fields where the help is truly needed. Generally, the more text provided to the user to read on a form, the less of it the user is likely to read (particularly if most of it is unnecessary). It is better to provide instructions that are as short and as visual as possible - and only when necessary. Here are a few examples:

Near the field
This is probably the way that I have most often displayed instructions or hints. It is fairly common and likely carried over from old paper forms. The positive is that it's visual - the user doesn't have to read it to gain understanding. The negative is that it's very passive and may be easily missed.

In the field
This method is a bit harder to miss since the instruction is right in the field, but it is typically hidden when the field has focus, so the user does not get the instruction when it's most needed.

On hover or focus (tooltips)
This is similar to the "near the field" display, but is shown only when the user's cursor hovers over or enters the field. This might pull the users attention better than the always-visible instructions.

As an input mask
Whenever field formatting is an issue, I think the best possible solution is input masking. This has, until recently, been rarely seen on the web, but I remember using it in Access database design many years ago. With the many RIA tools now available, this method of instruction is much more accessible.

Here are a couple of links to open-source input mask components:
Flex
Javascript

Other Visual Cues
There are other visual cues can help to let the user know what to enter into a form field:

Field sizes
The size of a field can give the user a visual hint of what is expected. For example, if you want the user to enter a 2-digit state abbreviation rather than a full state name, it is helpful to have a smaller field. If all of the fields in the form are sized appropriately to the amount of data expected, the user may only need to glance at the labels. In addition, having the fields in the expected order (when there is an expected order) will help the user to flow through the entry quickly.

Multiple fields
I have mixed feelings about this one. Multiple fields are often used for inputs with specific patterns such as phone numbers, credit card numbers, and serial numbers. I do think that this helps to set the user's expectations of what should be entered, but because all of these behave a little differently, there can be usability issues. For example, does the form automatically jump to the next field when you've entered the correct number of characters in the first one or not? I personally think that input masks are a better solution and provide basically the same visual cue.

Character Restrictions
Another interesting challenge in helping the user complete forms is character restrictions - maximum characters and data types. For maximum characters, we typically just set the cap on the field and when the user reaches it, he/she is unable to enter more. I think that this is acceptable and expected for short fields, but for longer text entry, the running tally of characters seems helpful. This is typically done by displaying the maximum number of characters next to the field and then showing a "### of ###" total as the user types.

As for data types, Flex has a "restrict" property that can be set on a text input that disallows the wrong type of character. I think that this solution falls into the category of protecting the user from failure, but it doesn't (by default) provide any feedback to the user so that they understand why they can't enter anything else into the field. In this case, I think it might be good to provide an instruction triggered when the user tries to enter something other than what the field has been restricted to accept.

Success or Failure
I have talked to designers that are of the opinion that a success notification should be provided for each field, but I personally don't think that's necessary. I would recommend providing success messages only for particularly difficult fields, such as serial numbers, and only providing negative feedback when necessary for more common fields. This should meet user's expectations and keep the form nice and clean - no need to distract the user from the data entry without a good reason.

How do you know if you've succeeded?
I am a huge advocate of performing several formal usability studies throughout the design and development process. I am *always* caught by surprise at some of the issues that a usability study will turn up. It isn't always easy to sell this to clients - it is a somewhat new idea and will of course cost more money up front - but I explain that it is the QA of the design and a necessary part of the application development process. If usability issues can be caught during the design phase instead of after development is complete, it will save the client money in the end by reducing necessary rework and increasing user acceptance. As they say, you only get one chance to make a first impression.

Adobe MAX 2008: Lazy Innovation

2008-12-03T19:49:00.000-08:00

I'm finally making good on my promise to expand upon some of my experiences and thoughts about the sessions that I participated in at Adobe MAX this year. The first, which really got me thinking, was Lazy Innovation: Strategies for the Design of Innovative User Experiences. Here is the description of the session provided by Adobe:

When engaging with applications, users essentially want to complete their tasks with a minimum of difficulty and friction. In this entertaining presentation, the Adobe Consulting User experience team will explore this "doctrine of laziness" as a means of identifying opportunities for innovative user experiences.
Speakers: George Neill, Jerome Doran
The primary premise of the session was that we, as user experience designers, should observe and anticipate the shortcuts that our users may find and provide those as the primary paths in order to provide the most efficient and usable interfaces possible. In addition to this, there were several tips for how to "think outside of the box" when designing these solutions. These are a few of the key points that I wrote down in my notes and would like to explore:

1. Interview users in their own space.
2. Assumptions are restricting.
3. Keep it simple.
4. Don't stop at the first solution.

Interview users in their own space
Most of the usability studies or user interviews that I have performed have been in environments completely unfamiliar to the users. In these situations, you have to count on the users to verbally explain what they do in enough detail to allow you to read between the lines. You also have to assume that they aren't leaving any part of their routine out, which is probably too much to ask. If some workflow is so "routine" that they do it without even thinking about it, how likely are they to mention it? Yet, any task that they perform without thinking is *the* most important aspect of that workflow.

To illustrate this point, the speakers displayed a photograph of an end user at her desk. Arrayed around her were the tools she used to do her job day to day including her hand-written mechanisms for keeping track of data that the software she was using either did not provide or did not provide in a way that was usable to her. This alone told the user experience designers much of what they needed to know to correct the issues in the current application and create a workflow that would alleviate the need for these hand-written systems.

Assumptions are restricting
You could say "duh" here, but I was trying to look at it on a deeper level. For example, is it always a good idea to follow the "proven" design patterns? I think that *starting* from design patterns is always a good idea, but what if there are easier ways for this particular user group to navigate the system or complete a task? If we always assume that the design patterns should be followed, we may never get to those better solutions. And to get more general, assuming that something is not technically possible can pose severe limitations on innovation. I very much enjoy working with a development team that is willing to explore some of the more out-of-the-box user interface solutions in the interest of a better user experience.

Keep it simple
This also seems obvious, but I have to say that it may be one of the problems I encounter most on projects. The business wants to cram every single last feature request into the software no matter where it falls on the end user's priority list. In a recent project, I have designed features that emulate some of the most complicated office software products available (Outlook, Word, Excel). In interviews with users, these were requested, but of lower priority to some of the more simple features. On the development side, they were extremely complex to design, develop and make usable. At the end of the day, these features created unnecessary complexity in the user experience, not to mention the amount of time involved in designing and developing them to be even remotely usable. When prioritizing features these should be the first to go. Simple software is easier to use.

Don't stop at the first solution
Ok, this one might turn into a little of a rant. From the creative perspective, I *know* that one should never stop at the first solution to any problem. Pushing past it is what gets you to the innovative solutions - the real goal in any kind of design. However, it seems that no client ever wants to *pay* for the time it takes to do so. They all want innovation, they just want it in the time it takes to use an existing template (all but impossible). It happens sometimes, so maybe that attitude has been falsely reinforced - a designer might reach a stroke of genius on the first try. Given that remote possibility, how do we sell the time to our clients in a way that they will understand? I hate to post a complaint without some suggestions for resolution, but this is one that I am really stuck on.

What do you think?
I'm really curious. How do you approach innovation in user interface design while retaining usability? The most usable interface is one that the users are USED to, but there's not much innovation in that. How do you introduce new concepts? How do you convince your clients that it is important to allow time for innovative solutions? Are those solution even "all that" or should we just stick with the familiar?

Adobe MAX 2008 - The Big Picture

2008-11-22T10:13:00.000-08:00

I'm back from Adobe MAX 2008 - the U.S. version, which was held in San Francisco at the Moscone Center and the Marriot hotel. This was my first trip to MAX and I have to say that it was the best conference I have ever attended. Not that there isn't room for improvement related to some of the session offerings and organization in general, but I would definitely recommend it to anyone in the industry. It's worth the cost without a doubt.

I have a ton of thoughts to share, but I thought I would start with a general overview in part to keep my memory of everything fresh. I had planned to write something about the sessions day-by-day, but they kept me far busier than I expected and I was just too darned exhausted in between to do so. So, here is my schedule and a short take on each of the sessions I attended. I have denoted which of the workshops were "sessions" and which were "labs". The sessions were basically lectures and demonstrations on certain software or topics and the labs were constructed like hands-on training. For anyone planning to attend next year, I highly recommend signing up for the labs as quickly as possible. They fill up fast. I created my schedule a couple of months in advance but was still only able to get two of the labs that I wanted.

Day 1 - Monday, November 17, 2008

9:30 am - 11:00 am MAX Opening General Session
This was 5,000+ people in a very large auditorium with a theatrical presentation of some of Adobe's newest softwares and how they are being used out there. The biggest surprise for me was when the first lady of California, Maria Shriver, came out to speak about a project she is sponsoring called California Legacy Trails that was developed using Adobe Flash. This was just a first taste of the extravagance that we could expect. To help you visualize:

11:30 am - 12:30 pm (session) Lazy Innovation: Strategies for the Design of Innovative User Experiences
The content of this session was a great discussion of the "ideal world" where we take a deeper look at user behaviors in order to provide streamlined and innovative user interfaces that are as efficient as possible and more aligned with the user's natural workflow. There was a bit too much time spent on the set-up and not enough time on the point, but I chalked that up to lack of practice, being that this was the first session of the event. Still, it was good enough to generate a lot of thoughts and inspirations for me which I hope to expand upon very soon.

2:00 pm - 3:00 pm (session) Prototyping Adobe AIR Applications with Fireworks
This session went through the process of prototyping Flex/AIR application interfaces in Fireworks. It was a good session in general and very informative, but I was a bit disappointed. I would guess that the shortcomings Fireworks has in this respect are due to the eminent release of Thermo. The gist is that Fireworks can only create rapid prototypes that do NOT provide reusable code. This would serve some purposes and I can imagine it would be great for pure designers who do not have the skills to create reusable code. My personal approach, however, is to create high-fidelity prototypes with a goal of at least 80% reusable code. In my opinion, this can increase both the consistency of the experience, efficiency of development, and overall end-product quality.

3:30 pm - 4:30 pm (session) Introduction to Thermo
Thermo (now named Adobe Flash Catalyst) appears to be a designer's dream. It (theoretically) allows us to visually create Flex code through a WYSIWYG editor that is reusable for the development team as in import to Flex Builder. I say "theoretically" only because I am a bit skeptical about the tool's ability to create code that is clean enough for the level of re-use that I think is necessary for a quality end product. I spoke directly to some members of the Adobe team about this and they have insured me that it is intended to do so, but I'll reserve my true judgment until I have a chance to see it in action. They also shared that Adobe Flash Catalyst (Fc) is scheduled to release in about a year, with a public beta scheduled in Q1 of 2009. We were given a "preview" CD containing a pre-alpha version of the software (along with Flex Builder 4 "Gumbo"), but it is unfortunately a Mac install and since "I'm a PC", I will have to wait for the beta.

5:00 pm - 6:00 pm (session) Filthy Rich Flex: Graphics and Animation
This session demonstrated several ways to create animations or transitions trigged by user interaction in Flex. In general, I was a bit disappointed that the speaker didn't talk more about why these transitions were important to usability. While the demonstrations and code review were probably useful for Flex beginners, I didn't find much enlightenment in this presentation. I was really hoping to learn new ways to stretch the visual and interactive boundaries of the standard Flex components.

6:30 pm - 8:30 pm Welcome Reception
The Welcome Reception at the end of day one was basically a free meal, drinks (beer and wine) and an opportunity to network with other MAX attendees. I found the large tables of strangers a bit intimidating. I did run into some colleagues from a previous project there that morning and spent the evening sitting with them and also talked to one other person who happened to be sitting at the same table. Otherwise, whenever put in this situation (every meal offered), there was little conversation beyond small talk at my tables. I think it might be more successful if the Adobe employees were given the task of taking on a table or a few tables each to engage us in conversation and get us talking about the conference topics and helping to break the ice.

8:30 pm - 10:30 pm Meet the Team
The Welcome Reception could be a great precursor to these sessions where we were given open rooms in which to have conversations with the various Adobe product teams. I spent the first hour in a room with the Flex and Catalyst teams and the second hour with the Adobe Product Evangelists. In the first hour, I engaged some of the Flash Catalyst team members in asking about the code that would be generated by Catalyst and how much control we, as designers, would continue to have over the layout using this tool. They insured me (as I mentioned above) that it is the intent of the team to have the tool continue to provide the greatest degree of layout control possible and that the code should be entirely reusable by development teams. They also welcomed me to provide feedback after using the preview.

My second hour with the Evangelist team felt a bit strange. I recognized several faces in the group of around 10 evangelists - most notably Ben Forta. There were also a lot of Adobe User Group facilitators and Adobe Community Experts from around the country. It felt like everyone in the room knew each other with exception of myself and a couple of others. I asked about the goals of the team and how they work to spread knowledge and "buzz" about the products across the country. The answers were a little vague, but in general, they work to spread acceptance of the software through the developers via user groups and smaller developer conferences. I like the approach, but I'm skeptical about its effectiveness. Of course we, as the developers, can recommend the Adobe technologies to our clients, but often the business in these areas is driven by them hearing the "buzz". They don't often even understand what they're asking for beyond knowing that it's the next best thing in the technology world.

Day 2 - Tuesday, November 18, 2008

9:00 am - 10:00 am (session) Best Practices for Developing with Flex in a Team
This was one of the sessions I appreciated most at the event. It was really more about general project management principles than specifically about Flex, but I found so many useful nuggets in the presentation that I sought out the speaker at the customer appreciation event to discuss some of it with him. My most recent client project has been so chaotic with requirements growing so uncontrollably that by the end, they had increased by around 70%, stretching the timeline by the same. By the end of this session I was wishing that my clients, project managers and all of the team leads I work with could attend. I will try to expand upon some of the advice this speaker had in a later post.

10:30 am - 11:00 pm General Session
This general session was very cool. It was even more theatrical than the first - following a "secret agent" theme. The keynote address was lead by Tim Buntel, Adobe's ColdFusion Marketing Manager, as "Agent B" and Ben Forta, Adobe Product Evangelist, as "Agent F". They proceeded to show the best aspects of software provided for Design, Development and Deployment tracks. I was so amazed with all of the new features and the overall integration of the products that I wanted to run right out and buy CS4 right away.

1:30 pm - 2:30 pm (session) Designing and Building Web Experiences in Flash CS4 Professional
WOW!!! Ok, so I originally didn't sign up for this one, but changed to it rather last minute and I'm really glad that I did. Flash CS4 is amazing - particularly the new 3D animation engine. I was left at the end of this demonstration just dying for a really creative project so that I could engage some of these new tools. In particular, it's going to be great for browser-based games. Also, they have completely changed the way motion tweens work which will make them infinitely easier to create and modify. You can even save the animations applied to objects as a template for use on other symbols.

3:00 pm - 4:00 pm (session) Flex Project Workflows
This session was something of a case study provided by one project team. Most of the discussion was around designer/developer workflow and communication. It was interesting to hear about another team's experiences, but I didn't personally gain much in the way of new knowledge out of it. One aspect of interest was that this team's approach was to first develop a completely working prototype without any visual design applied and then send it to the design team to apply styling. As I would have expected, this caused a lot of rework due to the design team's need to request changes to implement the visual design. I feel fairly strongly that the design team should create the interface prototype first, then provide that to the development team to create the back-end code necessary to support it. I will definitely be expanding upon these views as it's something that I'm very passionate about. :)

4:30 pm - 5:30 pm (session) Next-Generation Flex Skinning
This session provided demonstrations on programmatic skinning of Flex components. I'm afraid that I found it a little disappointing. The demonstrations didn't go very deep into the new tools or how they could be used in more innovative ways or even how this was "better" than applying skins via external image libraries and style sheets.

6:00 pm - 7:30 pm Sneak Peeks
This general session was something of a preview of the new features and products that Adobe's research and development teams are working on. Many of these were absolutely incredible. The most popular of the new tools was one that reads the textual content out of video. This is huge because it will allow us to perform keyword searches against video content. It will also give us a way to provide content in both text and video format without rewriting the entire piece. I'm sure there are many other useful applications for it as well.

7:30 pm - 10:30 pm Customer Appreciation Event
The Customer Appreciation Event really took the cake for extravagance. I had been warned by other attendees that had been to MAX before that it shouldn't be missed. They bussed all of us about 20 minutes away from the Moscone Center to the the California Academy of Sciences and the De Young Museum. Once there, we had free run of both museums plus food and drink offerings including selections of sushi, burgers, spare ribs and various appetizer offerings. On site, there were bands, quartets, cultural musicians (the African drum musicians were amazing), a dance club, contortionists and several other entertainment options in addition to the museum displays. My first stop with the planetarium show. I have never seen one before and I have to say that I was seriously missing out!

I am just amazed at the expense that Adobe and the sponsors must have put towards this event - the number of buses, renting out two museums, the food, drink and entertainment - it's just mind boggling. Here are a few (poor quality) photos of the event:

Day 3 - Wednesday, November 19, 2008

9:00 am - 12:30 pm (lab) Getting Started with Real-Time Flex and AIR via LiveCycle Data Services
This was a "mega-lab" facilitated by Ben Forta. We went through some fairly complex code examples using Adobe's LiveCycle Data Services along with Flex. I'm not sure where the AIR part came in as we really didn't dive too much into that aspect, but the hands-on demo using LCDS was definitely useful. During the lab, however, I did some quick searching and am not finding a lot of shared hosting providers that provide these services. I asked Ben Forta about it at the end of the lab and he said that there were some licensing issues with using the LCDS directly on shared hosting, but that there was no reason these hosts couldn't provide BlazeDS. Connecting to data via LCDS was so extremely easy that I will definitely have to do further research.

12:30 pm - 4:00 pm Lunch and Napping
Ok, so I have to admit that I was so exhausted after lunch that I opted to skip the session I was to have during this time and went back to the hotel for a nap. I was glad that I did though so that my brain was fresh and awake for my next lab. I was supposed to have a session called "Experiences that Scale Across Devices" which I didn't feel too bad about missing because they had done several demonstrations during the general session and other sessions on this topic.

4:00 pm - 5:30 pm (lab) ColdFusion Powered Flex
While this lab was a bit on the "beginner" side for me, the instructor was the best one that I encountered at all of my sessions and labs. He didn't just lead us through the code examples - he also explained the "why" of everything that we were doing. I managed to learn quite a lot from this lab in spite of it being targeted towards beginners. There were several things I've done in ColdFusion and Flex in the past without knowing why I was doing them or how exactly they worked. It was great to gain a better understanding of these tools. Using ColdFusion along with Flex through the wizards provided in Flex Builder was beyond easy. I just hope that I can find a project on which to apply this combination.

Communicating with the User in RIAs

2008-10-01T19:21:00.001-07:00

RIA interface design has provided a *somewhat* new challenge in communication with the user. In typical HTML-based applications, you could count on the "page refresh" to shoulder at least some of the user communication effort. The page refresh could communicate:

"I'm navigating you somewhere."
"Your changes have been saved."
And just generally... "You can expect to see something new when this is over."

hus, when the page refresh is done, the user knows to search the screen for the "something new", whether it is an entirely new page, a failure/success message, or new data.

With RIA, the transitions can be so seamless and fast that the user may not recognize that something has happened, so it's on the user interface designer to make sure that the communication is clear. This article will focus on a few instances in which the application needs to communicate with the user and a few different concepts and examples on ways that it might be done.

Visual Display
If you were to display an error message in the same visual style as your page content, success messages, or any other text, your user would be less likely take notice. It is helpful to devise a way to visually differentiate all of the different messages. Validation errors or other messages which you really want the user to pay attention to should be called out while less important messages should be there, but unobtrusive. Some examples:

Pop-up Alerts
Pop-up alerts or dialogue boxes are the most blatant way to demand the user's attention. They can also be the easiest way to annoy your user into disregarding them. Used *very* sparingly and with visual styling to further increase the importance of the message, you can make it more likely that your user will not just immediately get rid of it. If you use too many alerts or use them under conditions that really aren't all that important, your user will be more likely to just close the alert without bothering to read the message. Another tactic to get the user to pay attention is to provide them with a succinctly worded Yes/No question and Yes/No buttons for answer. Don't give the user an easy, noncommittal out by using "OK" or "Cancel" buttons.

Color Codes
You can use colors to differentiate messages. I personally like red for errors, yellow for warnings, green for success, and blue or gray for help/instructions. Most of your users can just glance at the color and get the message. However, you should also consider color blind users or users in countries where the red/yellow/green code has a different meaning depending on your audience. It might be helpful to add an icon along with the color codes (such as an exclamation point or question mark). This allows the users to get the message without having to actually *read* the message.

Location
The location of your message on the screen can also signify its type and importance. I think that it's generally a good idea to display validation error messages near the related field, but what if that field is "below the fold" or otherwise can't be seen from the user's current location? It might be a good idea to display an additional message in a location that the user can't miss if it's important. Conversely, if the message is necessary, but no action is required by the user, it can be displayed in a less obtrusive location.

Flex has a built in component for form validation that displays error messages near the required form fields, but it comes with some built-in usability issues. First, the user must position the mouse over the field in order for the message to appear. I have performed usability tests on software using this validation and it fails miserably. The red border on the form field is too subtle and the users do not understand how to get the error message to display. Also, in scrolling situations, there is no top-level error message display built in to this component. The component might be useful if it could be extended so that the error message was displayed constantly rather than just on mouse-over. Someone has already done this (of course). See Aral Balkan's post: "Better form validation in flex".

Transitions
Page refresh in the standard HTML website is a type of transition and as mentioned above, can communicate change to the user. I actually found out how important this was after performing a usability study on a particular feature that I was adding to a web application.

This was a very data-intense application, so it was necessary to hide the feature until it was needed in order to free up the screen real estate for data display. So, I used a hidden <div> which was displayed when a link/button was pressed by the user. While completing this task during the study, very few users recognized what had happened after the link was clicked. Most assumed that they had navigated to a new page, when in fact, the data they had been viewing had just been pushed down so that the new feature could be displayed.

So, using the Yahoo UI library, I added resize and fade-in transitions on the <div> so that it appeared to be opening downward and pushing the data down below it (first resizing the to the appropriate dimensions and then fading in its contents). All of the users in the subsequent study easily recognized what was happening.

Let me know what you think
So I've obviously barely scratched the surface of all of the user communications that are required in a complex application nor all of the ways to address those I did touch on. Please feel free to comment back about challenges you have faced or other ways you have discovered work well to resolve these. And thanks for reading!

Getting Started in Adobe Flex (for Designers)

2008-09-10T06:51:00.000-07:00

This article is intended to be the beginning of a series of articles on Adobe Flex from a User Interface Designer's prospective. I hope that it will give any designers out there that are new to the Flex framework a jumping off point to help them figure out exactly where to begin when designing for and/or developing new applications. I plan to add follow on articles to dive into more details about the aspects of Flex that would interest UI designers in the future.

Overview
Flex is a framework for rapid design and development of Flash-based RIAs (Rich Internet Applications). Underneath the covers, it uses a mix of an XML-based language (mxml) and Actionscript that gets compiled into a Flash swf, which is then published to the web. The standard user interface components available in Flex apply some of the best aspects of both desktop user interface behaviors and web interface element behaviors. The standard components are extremely customizable both in appearance and behavior and custom components are relatively easy to develop for design elements that do not fit the standard set of components.

Although the resulting application is a Flash swf, building an application in Flex feels more like working with HTML/Javascript than it does Flash. There is no obvious concept of a stage or timeline. Each screen or set of screens is self-contained similar to a typical HTML-based website until the application is compiled. However, because of the limitless user interaction possible with Flex, designing interfaces for it is much more challenging than designing traditional web application interfaces where there are certain limits to what can be done in a reasonable amount of time. There is much less of a linear navigation scheme of page-to-page or screen-to-screen. It is easy to create conditional transitions that react to user input on a single screen. And similarly to Ajax, Flex applications can pull back data for display real-time, without a "refresh" or sending the user to another screen.

For a more in-depth look at the Flex framework and code, I would recommend Adobe's Getting Started with Flex guide. If you are primarily a designer, you will most benefit from the Getting Started, Building a Simple Interface, and Building an Advanced Interface sections.

Design Considerations
The easiest way to get started learning and using or designing for Flex is by exploring Adobe's component and style libraries. This will give you a basic idea of what is available "out of the box". It also gives you code snippets that you can copy and paste into Flex Builder.

The more your design can conform to use and styling provided with the standard components, the faster and easier it will be to design and develop your interface. However, the true power of Flex lies in the fact that you don't *have* to stick to the standard components and that nearly anything is possible. Rather than making it easier to design an interface, this makes it much more complex. Here are some aspects that should be considered:

Component Behaviors
Most of the standard components have built-in behaviors that you may or may not wish to make use of in your interface. When considering the overall user experience of your application, you may find that some of the behaviors fit and some don't. For example, a "panel" object can be dragged around by its title bar. This is a behavior you may wish to turn on for certain elements and off for others.

Transitions and Effects
Transitions and effects are not traditionally part of web-based application user interface design. For one thing, they're not necessarily "easy" to create and can even hurt the user experience due to slow page loads. And let's not even mention browser compatibility. In Flex, there are some standard effects and transitions that are very easy to employ. .Also, because there is no sense of a "page refresh" as you would have in HTML to alert the user that something has happened, transitions are sometimes necessary in order to provide that feedback to the user and maintain the usability of your application. For example, what happens when the user clicks the Save button on a form? In a traditional web application, you might see the page refresh and your new data added. The page refresh alerts you that something has changed. In Flex, your data could also be refreshed, but that alone may not be obvious enough for the user to feel confident that the change has been made. You may wish to replace the "page refresh" with some other type of transition or effect that accomplishes that purpose. I hope to explore the many options for this in a later article.

Images
It may be worthwhile to give greater consideration up front as to what tools you will use to create your design comps. One great advantage of a Flash interface is that it can include vector images and thus create a very small download for a finished file. If you design using a vector graphics tool (Illustrator, Fireworks, Flash, etc.), you can use those graphics to create your image library for your Flex application. I have found a Flash-based image library to be very efficient for use in Flex applications (also more on that in a future article).

Skins
As with the image library, I highly recommend working with vector-based graphics when skinning for a more crisp appearance and smaller downloads. The gist of skinning is that you can make any component in Flex look exactly how you want it to. But keep in mind, some components will be easier to apply significant modifications to than others. For example, you cannot, through skinning, make the tab bar display vertically rather than horizontally. You will need to develop a custom component for that (which I found out the hard way on my first Flex project). There's only so much that skinning can do. But, if you just want to make your Flex application look a bit different and not like everyone else's Flex application, modifying the skin is an easy way to do so.

Adobe offers skinning templates in Flash, Photoshop, Fireworks, and Illustrator and instructions how to use them on their website HERE.

CSS
Cascading Style Sheets in Flex work much the same as they do in HTML. The syntax is slightly different in that the property names are camelback instead of hyphenated (ex. font-family = fontFamily). However, Flex seems to recognize styles written in HTML property syntax as well. Some limitations that I've found:
width, height, x, and y properties cannot be set through the style sheet
style inheritance seems a little odd sometimes due to the component inheritance (ex. the ComboBox component seems to inherit styles from button, so styles applied directly to the Button selector through the CSS apply to ComboBox as well)
Adobe has a complete list of CSS properties for Flex 3 available on their website HERE.

Communicating the Design
You may also find it a challenge in this media to communicate your design to the business and development teams. For your design concept presentation, I recommend using storyboards to portray the transitions and user interaction as necessary. This method will also be useful when communicating the design to the development team for implementation. However, I think that there is no better way to communicate the design than to create a high-fidelity UI prototype directly in Flex. This will require more technical capability than a pure graphic designer would typically have, but it is really the only way to ensure overall consistency in design. Even so, if you are working with a large application and team, documentation may also be necessary. I highly recommend using detailed User Interface Specifications coupled with a Navigational Blueprint and Wireframes and/or Storyboards as necessary. I will expand upon these recommendations in another article about Design Process as related to RIA.

More to Come
So I obviously haven't touched on everything here, but have hopefully given you some basics and provided links that will help you get started. If there are any specific user experience or user interface design topics related to Flex or RIA in general that you would like to see, please let me know.

I welcome respectful, constructive feedback or corrections.

BFlex '08

2008-09-09T11:38:00.000-07:00

On Sunday, September 7th, I attended the all-day *totally free* BFlex training conference at Indiana University in Bloomington. Having attended free conferences in the past, I was really expecting it to be more of a sales pitch and was very pleasantly surprised. All in all, while I had to give up most of my weekend to attend, I found the experience very worthwhile and will plan on attending again next year if at all possible.

The organizers scheduled all-day, hands-on training sessions in three tracks: beginner, intermediate and advanced. The instructors included Adobe Customer Training and Adobe Community Experts, which we were told paid their own way and donated their own time to facilitate the event.

It was a bit tricky for me choosing which track to take since I have mostly concentrated on the design and layout end of Flex (working with mxml, css and skinning). I knew that Beginner would be too easy since I had already taken the Flex 2.0 Developing Rich Client Applications course, but I thought Advanced might be a little over my head, so I opted for the Intermediate track. It was a bit on the easy side for me due to my experience in the tool over the past year and a half, but I felt that the topics were right on. Here were the training topics for the intermediate track:

Managing Data on the Client
We learned how to filter and sort recordsets client-side. This was an easy topic, but also very useful.

Exchanging Data Between Components Using Custom Events
I find the event handling in Flex to be rather tricky (especially for my more design-focused mind), so this topic was an excellent primer for me. Unfortunately we didn't get to it until the end of the day and it was rather rushed. However, the instructor (Matt Boles of Adobe Customer Training) was kind enough to offer to do a web conference with me to dig further into it. We learned how to create, instantiate, and handle a custom event.

Extending Flex Components
I have created a few custom components, but haven't really worked with extending the existing Flex components, so this was a great topic for me. We learned how to modify or add functionality or design attributes to the existing components. The example involved adding a button into the title bar of a panel - something that I have needed to do in my real life projects so extremely useful.

There were a couple of other topics included in the materials that we ran out of time for (bummer!): Providing XML to Controls with E4x and Implementing Drag and Drop Functionality.

One hole that I saw at this conference, and have noticed in the community in general, was the lack of design and layout focused training. The presentation layer in Flex can be very complex and is integral to the user experience. I have learned a lot in this area in the two Flex projects I have worked on in the past year and a half with Johnson & Johnson, but have mostly had to self-train. Maybe the organizers will consider adding some topics on this next year. Specifically, I would like to see topics focusing on design considerations for RIA, mxml layout, and skinning.

One other thing of note that was announced at BFlex was the RIAdventure cruise happening next February. It is a networking cruise to the Bahamas for ColdFusion, Flex and AIR geeks. How cool is that?! It is being sold as a "non-conference", but I am hopeful that they will add some training sessions and speakers so that I can justify the time and expense with my employer.