Designing Organizations

Check out my latest article Designing Organizations on the MQ Blog!

Goal-oriented Prototyping

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!

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

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

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

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

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.