Adverts pay for many of the resources we take for granted on the web. No one begrudges a few ads — you wouldn’t be reading this if you did — but some sites take adverts beyond a reasonable level. Google’s latest search algorithm change attempts to improve user experience by downgrading sites with too many adverts.

According to Google’s Inside Search blog:

We understand that placing ads above-the-fold is quite common for many websites; these ads often perform well and help publishers monetize online content. This algorithmic change does not affect sites who place ads above-the-fold to a normal degree, but affects sites that go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page. This new algorithmic improvement tends to impact sites where there is only a small amount of visible content above-the-fold or relevant content is persistently pushed down by large blocks of ads.

The algorithm analyzes adverts in fixed positions; the Pagerank for sites using pop-ups, pop-unders or overlays will not be affected.

Google estimates the change will impact 1% of searches, i.e. you could encounter result reordering for one in every 100 searches. If your site’s affected, they recommend testing it with the Browser Size tool.

Perplexing Prerequisites

As with most search algorithm changes, Google is holding all the cards and gives us little to go on…

1. What do Google consider to be an advert? They’re not always banners or third-party scripts?
2. What do Google consider “above-the-fold”? It’s a dubious design term which changes from device to device and has no authoritative specification.
3. How do Google know whether an advert is above the fold? It’s easy to reposition advert blocks with CSS or JavaScript which wouldn’t necessarily be noticed by the algorithm.
4. How do they rank pages which use responsive design and reposition or remove adverts according to the screen size?
5. Google AdWords recommends advert positions above the fold. You may have received messages stating that you’re losing revenue because you’re under-utilizing the maximum number of slots. Could you be penalized for using Google’s own advice?

It’s great Google want to improve the web and search is their core business — they can do what they like and we’re free to use them or not. That said, should a company as powerful as Google be able to dictate something as subjective as design or user experience?

The Apple and Microsoft websites are essentially huge multi-page adverts. Could those sites be downgraded because Google (a major competitor) considers them to offer a bad user experience?

And where could it end? Could Google consider downgrading predominantly red designs because it’s considered a danger color in some cultures? Are they impeding your creative freedom? Is it censorship?

Don’t Panic

The vast majority of site owners need not be alarmed. Google’s announcement sounds more like marketing spin than an advanced new technology which will change the way designers approach pages.

I suspect the algorithm loads each page in a browser engine which emulates a 1024px width screen. CSS and JavaScript effects parsed during the initial page load may be applied but event or timer-driven code wouldn’t run. It then works out the vertical position of the first major content block and if it’s more than, say, 600px down, the Pagerank would be reduced accordingly. The overall impact is likely to be tiny, though. Factors such as keyword relevancy and even page weight will have a bigger effect.

There’s an easy way for site owners to avoid downgrades: simply place all your adverts at the bottom of the page then rearrange the content using CSS3 animations or JavaScript events. I’m no fan of intrusive advertising but that’s a horrible user experience — far worse than a little scrolling. Unfortunately, Google won’t know unless they manually check the site.

Will Google’s new algorithm affect your site? Is the policy at odds with Google’s advertising business? Is Google using it’s power to dictate website design and code quality?

Let’s start by defining the word “function.” A function is a self-contained piece of code which carries out a particular task (or function!). A key benefit of using functions is that they are reusable; if you have a task that needs to be performed a number of times, a function is an ideal solution. They can be either defined by you or by PHP (PHP has a rich collection of built-in functions). This article will focus on programmer-defined functions but will touch briefly on PHP’s functions to complete the picture

Read the original post:
PHPMaster: Defining and Using Functions in PHP

There reaches a point in every web developer’s life when they need a country selector — perhaps for a sign-up form or delivery address. So we find a list of all 249 countries, insert a select box into our HTML code and consider that a job well done.

It’s not.

Country select boxes are dreadful. The problems include:

1. Too many choices
Locating your country within 249 items is a usability nightmare.

2. An awkward interface
Select box controls differ between devices, OSs and browsers but one thing is certain — the user will need to scroll around to find their country. That often means switching from keyboard to mouse or lots of swiping on your mobile.

3. Sorting problems
If your site is primarily visited by US users, an alphabetic list displays “United Arab Emirates” and “United Kingdom” first. Some developers address this by putting the most likely countries at the top but this can confuse users expecting an alphabetically-ordered list.

4. No consideration for alternative country names
Country lists rarely consider alternative names. I live in the UK but any of United Kingdom, UK, Great Britain, GB, Britain or England could be defined by the developer.

5. Poor internalization
What if a Spanish user tries to locate “España” in your English list? At best, they’ll find Estonia. In addition, lists rarely consider international country codes such as ES or US.

6. No consideration for abbreviations or mis-keying
If a user enters a term such as “nited”, “States” or “America” it’s unlikely they’ll locate the USA.

Fortunately, Christian Holst from the Baymard Institute has developed a solution which solves the issues for us: see Redesigning the Country Selector.

It’s a jQuery plugin which replaces a standard HTML select box with an auto-complete control. The jQuery UI Autocomplete plugin is supplied but you can use your own implementation if necessary.

Several properties can be defined in the HTML:

<select name="Country" id="country-selector" autofocus="autofocus">
<option value="Austria" data-alternative-spellings="AT Österreich Osterreich Oesterreich ">Austria</option>
<option value="Spain" data-alternative-spellings="ES España">Spain</option>
<option value="United Arab Emirates" data-alternative-spellings="AE UAE Emirates">United Arab Emirates</option>
<option value="United Kingdom" data-priority="2" data-alternative-spellings="GB Great Britain England UK Wales Scotland">United Kingdom</option>
<option value="United States" data-priority="1" data-alternative-spellings="US USA United States of America">United States</option>
</select>

This snippet is identical to most country select code except:

• If a data-priority code is defined, it’s assumed to have a higher priority than countries without a code. The lower the priority number, the higher it will appear in the auto-complete list.
• A space-separated list of alternative codes and spellings can be defined in the data-alternative-spellings attribute.

To convert the select to an auto-complete box you simply need to call the jQuery plugin method:

$("#country-selector").selectToAutocomplete();

There are many more options so I suggest you try the demonstration and view the documentation at baymard.com/labs/country-selector. The open-source code is released under the MIT License and is available at GitHub.

The plugin is far superior to other implementations I’ve seen — including, ahem, my own. Note that it doesn’t work in IE6 or 7 but those browsers will still display the standard select box. It’s not limited to countries either and you can use any type of data. Recommended.

In part one of this mini series, we tackled the question of implementing a slider when you want to create a range of values, not just one. If you haven’t read part one, you’ll be feeling a little bit lost so I advise you go and check out iOS Range Slider: Part One . Still with us?

More:
BuildMobile: Wicked iOS Range Slider: Part Two

One of the commonly used iOS controls is the slider control. It’s a great, all purpose slider, that allows you to quickly swipe your finger along the screen to set a value. Things get a little complicated when you want to create a range of values however. The options are somewhat limited.

Read More:
BuildMobile: Wicked iOS Range Slider: Part One

With today’s snazzy and competitive “Web 2.0” and social media world, universal design is many times forgotten. It’s bewildering as to why since there are many social, technical, financial, and legal reasons which support universal design practices. Let’s discuss some of the more prevalent issues in websites today, and how they relate to the main universal design principles. The Principles First, let’s review the seven universal design principles including some web-related examples.

Link:
DesignFestival: Popular Mistakes in Universal Web Design

The role of search in your site can be a hot topic. Sometimes there is pressure to make it a giant bandage to cover poor navigational structure, and other times it’s included just because “every site needs search.” Let’s look at three pervasive myths about search and two questions that will help us create a strategy unique to every site. Misconceptions About Search Myth #1: Site Visitors Prefer to Find Information With Search Researchers have worked to combat this myth and have found that site visitors’ behavior does not naturally trend toward search first, even when searchers know exactly what they’re looking for.

See the original article here:
DesignFestival: Creating Meaningful Site Search by Challenging Assumptions

Next time you’re on a project where a designer is involved, it will help to keep these five tips in mind when it’s time to present wireframes:

1. Be visually minded

Your meeting will fall flat if the designer isn’t able to start creating mental visual concepts about how the design could start coming together. One way to help create the right atmosphere is to make attractive wireframes. If you are like me and aren’t a designer, then spend the extra effort to learn about basic design principles. This applies whether they are low or high fidelity, digital or hand-drawn.

Another way to serve these conceptual thinkers is to focus on the overall concepts of the site and how you see it coming to life. There couldn’t be a better place to employ digital or paper prototypes, if you are familiar with them, to help both of you visualize and discuss.

2. Channel creativity

Any quality designer will tell you that the best designs are produced within constraints. Creativity that is not channeled can be debilitating. One way to do this is to always talk openly about site goals, technical limitations, audience, budget, and timeline.

Designers are visionaries who are thinking in terms of design innovation and will likely keep creating new ideas during the whole design process. These are often great ideas that improve upon your work, but they can also frustrate the scope of the project. Clearly stating the limitations the design is working within can be a relief for everyone.

3. Focus on enjoyment

If designers’ jobs are merely to skin wireframes, their motivation will be lackluster, and who could blame them? Talk about where you see people being delighted, surprised, or specifically cared for by the site. Especially if you know the types of people that will be using your site, you can discuss how each personality would benefit individually from the interface experience. This will help them focus their energy, build excitement, and lead to innovative ideas for improvement.

4. Break it up

When you can, avoid dumping all of your documents and requirements on the designer at once. This will be overwhelming for both of you and can throw the creative process out of balance. You’ll probably end up needing one or two bigger meetings, but it will help if you can have some shorter meetings beforehand where you present sketches, talk about ideas, or talk through specific pages or challenges. When the bigger meetings roll around, you’ll have less groundwork to lay at the forefront and it will be easier to get momentum built. This process will make the transition to the design phase seamless.

5. Make it personal

It makes a world of difference to get to know the designers you’ll be working with personally. How do they best consume information? What role does emotion play in their decisions? What time of day is their mind most focused to absorb details versus think about the big picture? Do they need to marinate on something awhile to offer feedback or is it more instantaneous? Do they need coffee before your meetings? The more you can find out, the better you can personalize your projects with them to everyone’s benefit.

A Note for the One-person Shops

If you happen to be a one-person shop, where you are developing the strategy, planning/wireframing, designing, and coding all yourself, these still apply! As a multi-talented individual with a heavy task load, make sure to think about the different modes in which you are asking your brain to work. By helping yourself think conceptually, visualizing, using constraints, thinking about enjoyment, and breaking the work up into smaller segments, you will be all set for the design phase.

Ideas, even earth-shatteringly magnificent ones, that aren’t communicated effectively can suck the life right out of a project. For the next couple of weeks I am going to be discussing considerations for presenting your IA work to various audiences.

Here are four guidelines to keep in mind while you’re preparing to meet with or present IA directions to the developers involved in your next project:

Be respectful.

In every situation, always respect the developers. I’ve unfortunately been witness to and even participated in hasty critique of developers’ work. The truth is that we don’t know the constraints they were under when they created a system, what obstacles they had to overcome, and the problems that have already been solved. Make assumptions with benevolence, draw out current weak points as springboards for discussion, and use the project goals to guide constructive conversations.

Be brief.

Developers usually have several complicated problems rolling around in their heads that they’re in the middle of solving (occasionally this creates the illusion that they’re not listening, but don’t be fooled – they are). Acknowledge their cognitive load and don’t take up more time than is reasonable. They will respect you for your brevity and be glad to get back to working on those solutions.

Get to the good stuff.

These pragmatic problem solvers benefit from getting right to the meat of the matter, so make sure you cut verbal fluff where you can. Be careful here: that doesn’t mean they aren’t interested in the project goals, site audience, or other “soft” topics. In fact, it’s these details that give their work context and purpose. It’s the delivery which matters, which should be sans pretense and filler words.

Engage with the details.

From the very beginning of a project, the developers should and will be thinking through implementation details. Stay a step ahead by preparing thoughts and questions related to the implications for both front and back end development. Every piece of a wireframe or prototype impacts their scope. Sometimes this can get frustrating if you’re excitedly sharing a big idea and they’re giving you five reasons the execution of this idea is not going to fly. Expect this back and forth and be thankful that the development team is putting all that thought into the project.

Of course, I am painting with broad strokes here and every developer is unique (I work with ten and am married to one, so I have some firsthand experience). These guides are just a good place to start as you get to learn about and relate to these individuals on your project team.

In my last post, I mentioned that one way custom controls on a mobile device work well is if they mimic a real-world control. Let’s look at a turntable metaphor as an example: an app that looks like an old turntable might have a moveable needle, knobs to turn, and the ability to scratch (I found out that apps similar to this actually exist, but I’ve not checked them out).

This might be Apple’s favorite rule to break. To see what I mean, check out the calendar app on an iPad. It looks a lot like a traditional datebook with all of those flippable pages, but it’s the tiny arrows at the bottom that you have to tap to flip the page. There’s no option to use a swipe for page turning.

The iCal app doesn’t allow page turns by swipe

In an effort to do what they say and not what they have done above, let’s look at some ways that you can deliver a consistent experience that makes sense to the people who will be using your app:

• Get off the computer. In as many ways as possible, the abstraction should work as the subject itself. If you are building the turntable app that I mentioned earlier, then by all means get your hands on a turntable! Put a record on, adjust the knobs, listen to the crackle of the needle against vinyl, pay attention to the details that make it an enjoyable experience. Take notes.
• Improve on “real life.” The advantage of having a turntable or a datebook on a multi-touch digital device in the first place is that you can do all manner of things you can’t do on a real turntable or datebook. Increase enjoyment by improving upon the real world object where possible, both in appearance and technical ability.
  For example, being able to swipe to flip the page of an eBook is a fun interaction but becomes a chore if you are forced to do it. A digital turntable might have secondary controls that don’t require the users who are in a hurry to set the needle or pick a new album. Plan for advanced or frequent users of your app by creating alternate task flows that focus on efficiency.
• Try it before you build it. The more you can experience the app you’re making before it’s built, the more you gauge how well the metaphor is coming across and where the holes are. A cheap and effective way to do this is through paper (or even felt) prototypes, where you can “act out” the interactions with printouts or drawn mockups.
  So, in our turntable example, you could demonstrate that you want the needle arm to snap to the edge of the record when it’s tapped once, but dragging allows it to be placed anywhere. This activity is instantly collaborative since it’s not on someone’s personal computer and leads to lots of clarifications. Make sure to invite the developers; they will think in terms of execution and can bring technical opportunities and limitations to the discussion.
• Think through details. I like to think of developers as the directors that pull the working parts together into a cohesive unit, telling the “actors” where to go and when to make the story believable. It makes the process much smoother and takes the pressure off if these interactions have been discussed beforehand. That’s why it’s best to avoid the temptation to sweep even small areas of vagueness under the rug during the planning and design phases.
  It’s all too tempting to say, “the developer can flesh those details out, we don’t have time to worry about all those interactions right now.” Remember that your metaphor will be fail without detail-oriented production; it’s the direct manipulation and carefully planned responsiveness that makes the app feel “right.”

Chances are that you are building an app where more standard controls are optimal and there’s no need to make it look like something else. If you’re not sure, take into account who’ll be using your app, what purpose the metaphor would have, and the unique value the metaphor would bring to the people using your app. Don’t forget that enjoyment counts as value!

We are very excited to announce the arrival of our newest family member: Design Festival!

Design Festival is an exciting new website created from the ground up by the passionate team here at SitePoint. We want to explore web design topics in more detail, and decided a whole new website would provide the focus we’ve been searching for.

Design Festival will be the new home for web design professionals from around the world. We are exploring different web design techniques, with an emphasis on logo design, UX, and typography.

If you love web design, this site will provide an outlet for your passion. Please join us!

• Access best-practise UX design, logo design, typography, and coding advice.
• Indulge your passion for design – and learn a thing or two as you go.
• Contribute your own expertise to help others sharpen their skills.

Please visit the new site, join our Facebook page, and follow us on Twitter to stay updated on all the exciting Design Festival news. We’d love to hear all your feedback, so please let us know what you think.

If you’d like to become a contributor to this website by either writing a post or tutorial, please get in touch: editor@designfestival.com.

Thanks, as always, for your ongoing support of SitePoint and our sister sites. We appreciate it, and hope you love Design Festival as much as we do.

If you’ve been lucky enough to work on an iOS app for the iPhone, you’ve probably had two experiences:

1. Sweet freedom! There is no cross-browser compatibility to concern yourself with and a nearly limitless array of possible experiences you can build into your app.
2. Paralyzing freedom! Just like picking the right box in the cereal aisle, too many choices can leave you frustrated and resorting to whatever you’re most familiar with.

It is not difficult to create elegant, yet complex interactions on a website. Take web forms, for example; many fields and directions on one page can be smoothly navigated with design cues, easily scanned layout, and responsive controls. This is not the case in iOS, where a series of interactions on separate screens must work together to create one seamless experience.

As I’ve worked in the iOS platform, I’ve noticed how my web biases inform my iOS wireframes and task flows. Here are some ways I’ve learned to be aware of these biases and avoid them:

• Reset expectations about typing. Typing is so commonplace these days, we barely think about it. But no matter how speedy someone is on a mobile keyboard, it is always easier to select text on a touch device than it is to type it. Before you add a text field ask yourself: is this absolutely necessary? 

If it makes sense for your application, dynamically populate a list of possible answers below an input field once the user starts typing a letter or two (Google and Path are two of the many apps with this type of auto-complete functionality). Shave seconds off of interactions wherever you can because those seconds add up!
• Condense labels for forms and tables. Brevity is always advisable on the web, but it’s non-negotiable in iOS. Any time label text for table elements is wrapped or truncated, it interrupts the visual flow. Keep labels as short as possible without sacrificing meaning.
• Rethink forms. Instead of a consecutive list of questions and input fields on one long screen, think about forms on iOS as several quick interactions strung together. It’s helpful to maintain consistency with iOS standard controls by keeping cancel/back and submit/next buttons in the navigation bar at the top. The best forms are not drudgery to the user but just steps that must be taken to get something useful done.
• Take advantage of gestures, but… Gestures are tricky because they’re easy to both under and overuse.  There are three ways that I find gestures most appropriate:
  1. Offer them in the same way you might offer a keyboard shortcut in a desktop application — it’s there for improved experience and efficiency, but it’s not necessary to make the app function.
  2. Use them if you have created realistic controls that mimic real-world interactions.
  3. Present them in your app when you need to require deliberate intention (like answering your phone or deleting an account).
• Think in taps, not clicks. A finger tip is infinitely bigger than the tip of a mouse pointer, and that significantly affects your interface. Once you have a wireframe or mockup put together for a screen of your app, step back and look at it. Does it look like Honey I Shrunk the Web Page with lots of touchable areas crunched together? Is someone with thick fingertips going to be tempted to throw their phone across the room out of frustration? This seems obvious, but it is can be a daunting challenge to stop thinking in clicks.
• Don’t go overboard. It’s easy to swing too far in the other direction and use an array of different native elements because they’re there. The switch is an example of an element that has been widely overused because of its novelty. Well-placed interface elements put the people using your app in control, but superfluous interactions can make them feel like your marionette. A critical eye and some honest colleagues will help prevent interface bloat.

Instead of strictly following these guidelines, which will change as the platform changes, it’s best to focus on thinking critically about the medium and the people your product reaches. The advent of hundreds of millions of mobile touch devices is revolutionizing the way we think about the web and even desktop applications. Stay ahead of the curve by challenging your paradigms now!

Whether you’re testing an existing product, involved in a site redesign, or working on a completely new site, your biggest challenge is often yourself. Here are a few ways you might unintentionally cause problems:

• Your personal experience with a company, product, or application skews your interpretation. Think about an application you use daily. You know exactly where it frustrates you the most and maybe even how you’d fix it. Now imagine you were hired to make improvements to that app. You’d want to go straight to the source of your frustration. But if you limited your testing to just that area, you could miss a more global and crippling problem because of your tunnel vision.
• Years of experience using and working on the Web helps you to become an expert, but it also can create blind spots. Assumptions about how the Web should function based on what has worked and failed in the past can be indispensable, but also dangerous. When doing realistic illustrations, artists say, “draw what you see, not what you know,” and this is the same principle.
• Lots of pressure from higher-ups in a company to affirm their theories can implicitly affect the way you run tests and ask questions, especially if you’re new. There’s a reason people can be skeptical of tests funded by pharmaceutical companies. You may never skew results on purpose, but it’s easy to do unintentionally when the stakes are high enough!

Whether you’re conducting formal usability testing or just meeting with your team to discuss wireframes, your deeply held convictions can influence you anywhere! Here are some ways to actively work against your biases:

Avoid asking leading questions

Such questions hint at the answer you’re expecting to receive. For example, analyze how the statement below may be leading:

I would like you to use this form to complete your order. Your card won’t be charged when you click the submit button, so please finish the whole process.

The leading is subtle, but the statement assumes that the person using the site knows that you’re supposed to click a button at the end of a form, and that it’s called a submit button. Even more subtle is that just by saying the words “submit button,” you’ve now likely caused your participant to give more attention than normal to that element.

Be empathetic to participants

Your testing will be most successful if you recognize the strong desire many people have to do a task properly. Constant apologizing will likely make the test run too long, and can make for a stressed-out participant (making you feel awfully mean).

By paying careful attention to your tone, and writing an assuring and informative script to lead into sessions—as well as gently reminding participants during the session that you’re testing the web site or app, and not the individual—you’re more likely to create an environment that produces impartial results. If the participant simply struggles to figure out an interface you made and thought was quite clear, you’re at an especially high risk of becoming defensive, or asking leading questions to achieve an expected outcome.

Beware of your assumptions and bad memory

As soon as a test session is over, your brain starts to fit the new information into your existing assumptions about how things work, forgetting or altering those new pesky details.  The steps your brain takes to remain efficient do not always lead to the most accurate synthesis of information—especially if lots of time has passed between project stages. It’s impossible to remember everything that happened during the test accurately, even if you are a good note-taker (although, notes help!). Consider recording the screen and audio during sessions at least, so that you can refer back during analysis.

There’s no need to stress too much over these things, but do learn to be wary of your inclinations over time. Your best tests and internal discussions will happen as you learn to remove your biases from them.

In the lead up to the UX Australia conference in Melbourne, of which SitePoint is a media partner, James Mansfield asked three of the conference speakers about their views on the emerging field of UX design: what it is to be a UX designer, how they got into the field, and where they see it going.

The three UX designers interviewed were Shane Morris (Automatic Studio), Daniel Szuc (Apogee HK and co-author of SitePoint’s Usability Kit) and Iain Barker (Meld Studios). Their responses provide insight to aspiring UX designers, and paint an interesting perspective for experienced practitioners.

Hi gents, and thanks for taking the time to answer some questions.

First of all, User Experience Designer is a relatively new job title and a little tricky to define. How would you describe the role of a UX designer, as opposed to, say, a usability consultant or interaction designer? What title do you give yourself and why?

[Daniel Szuc]: I think we get carried away at times with our own buzzwords. We all want to differentiate what we do, but every new term brings with it the responsibility of educating the marketplace. This is not to devalue the direction they give us, but I prefer to use a term that the marketplace understands. At present, it seems to be UX. Every marketplace is a little different in terms of receptiveness to terms; for example, usability, UX, CX, design, XD, and so on.

Currently, I lead with “usability consultant” but often wear a number of hats including facilitator, designer, strategist—depending on the job. For me, the core of what we do is this: how can we take teams on a journey to help them make or create better stuff that has some positive impact?

How can we take teams on a journey to help them make or create better stuff that has some positive impact?

[Iain Barker]: I’ve used all three terms at different stages. When I called myself a usability consultant I was in a highly specialized role conducting usability tests, and then lobbing my grenades of usability goodness at client teams. I’d identify usability issues and make design recommendations, but lacked the responsibility of making or implementing the decisions.

When I refer to myself as an interaction/UX designer, I have a broader responsibility for the research and design of an interactive product or service, and actually making design decisions. I agree with Daniel that for the majority of clients, UXD is better understood than interaction design. On my LinkedIn profile I describe myself as a “user-centered design specialist,” but that might not be helping matters!

[Shane Morris]: I think the three terms reflect a maturing of the market, and what we as user-centered design specialists can offer our clients and employers.

Initially, we were all about usability; then it was about interaction. Nowadays we’re concerned with a broader relationship between a user or customer and the organizations they deal with, so we talk about user experience. So there’s a shift of emphasis.

I’ve always been wary of highfalutin titles, but I’m comfortable with calling myself a User Experience Architect because it best describes what I now do with my clients.

Thanks guys, very interesting perspectives. What do you think it takes to be a good user experience designer?

[DS]: I think it requires a number of people skills, like the ability to listen to all perspectives, watch for elements than can improve the design, and keep on learning generally. Then there are the more professionally recognized skills like communicating clearly, showing leadership, and being able to sell and market yourself and your ideas. And I’d add storytelling—the talent to tell compelling stories across everything we do.

[IB]: This is a big question. Some of the facets include having empathy for the end user, being able to collaborate and communicate with various stakeholders, and recognizing when to compromise on and when to fight for an idea. Importantly, you should see failure as part of the learning process that leads to a better solution; be prepared to share unfinished ideas or ask “stupid questions.”

[SM]: I concur with Daniel and Iain, but what’s interesting is that none of us focused on “hard” skills: running a usability test, facilitating collaborative design, or building a prototype. The most important skills are “soft,” with empathy the most important; perhaps it’s because hard skills are usually learned on the job, which certainly was my experience.

I conducted my first usability tests, and a lightbulb went on

It’s certainly interesting that you’ve all focused on what you’ve termed the softer skills. I imagine they’re the hardest to teach young students and, as Shane pointed out, are often learned on the job. So for aspiring UX designers out there, what advice do you have about entering the field?

[IB]: My advice for anyone starting out as a user experience designer are:

• Choose an organization that actually involves users in their design process
• Work in a nurturing environment that offers experience and mentoring
• Don’t be hamstrung by the fear of failure
• Read widely about the different perspectives on the UX process and techniques.

I studied a vocational information design course at university, and from there I spent a few years working as a technical author before given the job of designing the interfaces. For the first few years I got by on opinion-based design, which I found frustrating at times. Then, when I conducted my first usability tests, a lightbulb went on.

[SM]: Usability testing is a great way to start with user experience. It’s one of the more procedural techniques we use, and scales well from informal to formal; best of all, it’s a great environment to learn about human behavior.

For me, working in UX was a lucky accident. I’d studied computer science and cognitive science at university, but then discovered this area, and that I was qualified (by the standards of the time). I’m very lucky that the field has continued to evolve, and remain fresh and challenging to me.

Usability testing is a great way for a person to get started with user experience

[DS]: I started in development, and then learned about “human factors” while working at a telecommunications company in the early 90′s, leading to my interest in usability. From there I moved onto customer support systems, where I received good grounding in developing UI standards and training projects on embedding usability in products.

Thanks guys, that’s really interesting. You’ve been involved in the industry for quite some time, and seen it mature. Where do you see it going from here?

[DS]: Some advancements I’d like to see include a common language, standard and flexible tools, a better understanding of the leadership role UX plays in product strategy, and design being used to help business articulate strategy and plans. Basically, all the stuff we are good at, and more.

[IB]: I see a broader understanding and acceptance of the value we offer, with greater and more diverse opportunities, more demand than supply, and the recognition that we should influence business strategy.

[SM]: I think of it this way: once we were in the business of telling people their baby is ugly. Then we progressed to advising people how to make their babies more attractive. Nowadays I help companies work out what sort of baby they want, or whether they’d actually prefer an Xbox.

[DS]: The good news, as at 2010, is that there’s healthy interest from business about UX; now it’s our time to determine what role we want to play in the UX business discussion.

[IB]: It’s good to see organizations building strong internal UX competencies, and those teams given increased profile and recognition. Long may it continue.

By day James Mansfield designs the user experience for 99designs, and by night he plays dad and rants on about UX design at his blog. He loves cycling, food, beer, AFL and his eggs poached.