I thought I’d share a couple of articles I enjoyed reading recently: 

The Case Against On-staff IAs
http://uxmag.com/strategy/the-case-against-on-staff-ias?

A strong case is put forward by Hana Schank that being an outsider can give you a better perspective. While I do agree that its hard to maintain complete objectivity working inside an organisation, the familiarity also brings some benefits. I have seen many cases of consultants making poorly thought through recommendations because they didn’t have a firm grasp of all the issues. 

So, how do we get the best of both worlds? A lot of it boils down to the value an organisation places on customercentricity. If its regarded as being important, employing all the necessary tools and tricks to see the world from the users perspective will be routine and welcomed. If the interest in UX is just lip service (which is often the case), then all the subtle deterrents will be drip fed into the project, until all usercentricity is slowly asphyxiated. The only weapons against this are passion and education. You need to win over each stakeholder one at a time. And that is something only an ‘innie’ can do.  

5 Design Decision Styles. What's Yours? http://www.uie.com/articles/five_design_decision_styles/

Jared Spool outlines 5 approaches to UX. A horrifyingly accurate summary in my experience.  

I was at UX Lisbon on Friday. I decided just to do the last day as it seemed to be a great line up and I couldn’t really justify taking more time off work right now. 

While I got a lot out of it, I also felt that some of the talks were pretty routine to many of the speakers. Of course I don’t expect them to come up with something totally new every time, many of them have a bit of a road-show and do the same routine all over the world. So the outcome is a little generic and in some cases patronising. And I thought a couple were poorly targeted for the audience, in my opinion. Of course its easier to criticise than to do, but I do feel that, in our industry, not getting who your audience is is a major fail, as that’s what we are about, isn’t it?

Don Norman was great. I wondered if the fact that he kept it so high level was one of the keys to his success. That allowed each person there to interpret what he said to suit them selves. I am still getting used to his new suggestion that we start considering ‘signifiers’ instead, which he introduced not so long ago as an alternative to the now horribly abused term of ‘affordance’. You can get it straight from the Don here: http://www.jnd.org/dn.mss/signifiers_not_affordances.html. I think he has a point, particularly about the social context of the clues we offer, considering the lack of location specificity of most digital experiences. 

Coming from a design background, I feel strongly that the actual design and experience of the documents contributes to both their usability and the level to which they are valued by internal and external clients. I am sure I am not alone in having this view. So, having seen many examples of horrible, unclear documentation, I am keen to get on my soap box about this. 

A UX’er could be called on to create a number of documents, from a sitemap and wireframes to flow diagrams and concept diagrams. And, of course, not every UX designer has the skills to make every output a work of art. 

I have seen some awful documents, but, to be honest, the awfulness doesn't come from the lack of design finesse as much as from the author trying do something they are not familiar with. I’ve seen outputs from IA’s trying to make hardcore tech specs by using language they’ve seen in other peoples documents and not understanding it. And an awful hash made by someone who was wrestling with a content audit ad clearly loosing the battle. 

So, what is good documentation?

• Its clear: it speaks clearly to the audience it is meant for.
  
• Any one in the team can pick up your outputs and understand your thinking on the subject, without having to ask you what you mean.
  
• Its pleasant to use. Anything that gives people a headache is definitely going in the wrong direction. 
  

Why is it so important to document well? 

• Good documentation helps you communicate your ideas clearly.
  
• Documents have a habit of drifting out of your control, so they need to be able to stand on their own two feet in what ever company they find themselves in.
  
• If you ever want to change jobs, you are likely to have another UX’er reviewing your work - and sloppy work will count against you. 
  
• Someone else may have to work on them. They won’t think well of you if they inherit a pile of s**t!

My advice is this:

1. Know your audience. A solution that suits board level directors may not be right for the development team. A one size fits all solution will end up suiting no one well. You may have to adapt documents to suit the people who will be using it.  
   
2. Ask around. If you need to do something you are unfamiliar with, ask someone who is. 
   
3. Use the internet. If there aren’t a hundred examples of what you need to to, I’d be really surprised. 
   
4. Do follow the crowd. As usability resides with the user, it make sense to utilise what’s familiar to them and build on that - rather than having to educate them each and every time you present to them.  
   
5. Consult a book. Dan Brown’s book on “Communicating Design’ covers the basics of UX deliverables quite well. He has a collection of examples on his website, too. 
   

Having worked in a number of organisations over the years, I am always amazed by the variety of structures people have devised to house the creative outputs. Depending on the background of the founders, the structure often echos existing models, like advertising with creative directors and account directors running the show or publishing, where the creative leadership will come from the editorial team and product management. 

Alternatively, it may be based around the skills and experience of the founders, and I have certainly seen places where IAs or planning or sales or technology is the strongest muscle in the studio. And I’ve seen all of these models work brilliantly - and a couple where it wasn’t so good... 

Is there a “best” way? Probably not. But there are certainly a plethora of “worst” ways. The key to getting it right isn’t about who is in charge - someone has to be and its always great if its you or at least someone in your gang and criminally terrible if it isn’t - but really, its more about finding a way for each disciple to contribute in a meaningful way. 

The process can get broken because ownership is often seen as being exclusive, so that one person or team is ruling the roost, telling everyone else how its going to be done - often to quite extraordinary (and unnecessary) detail. This is very demotivating for the other disciplines which often leads to creative withering in those areas, where the inspired staff leave and are replaced by more docile characters.

A better approach is where each team member is encouraged to feel as if they co-own the project and to be actively encouraged push for the most excellent outcome possible. The trick is to live it rather than talk about it: lots of places espouse this view but it rarely actually happens because too few people really believe in it. The trick is to get everyone involved right at the start, brainstorming, talking, reviewing, and keep that going every step of the way. Of course there needs to be a leader, the one keeps the project on course, but the fact that they believe that a great idea can come from anywhere (and anyone) is what will allow brilliance to rise to the top and deliver great outcomes. 

When I started my digital career, I’d never heard the term ‘experience designer’. In fact, it was just before the term ‘information architecture’ was introduced to the industry, which we referred to quite quaintly as ‘new media’. 

A decade and a half later, everyone and his dog is involved in “experience design”, using one of a wide range of tiles including UX strategist, information architect, interaction designer, UX designer, experience designer and experience architect. 

So what do those of us in the many-titled tribe do? Do all those labels refer to the same role or are there subtle differences between an information architect and an interaction designer? How do any of us decide which title is right and what to actually call ourselves?

My perspective on this is the names matter less than the skills required within the industry. User experience design covers many activities, including:

• Strategy - what’s the plan for now and the long term?
  
• User research - what do they want and need?
  
• Content planning - from data structuring to metadata and taxonomies
  
• Information design - to help all stakeholders achieve their goals
  
• Usability testing - unavoidable and ideally, iterative
  

My view on this is not wildly different from Peter Morville's idea of the “Big Architect, Little Architect”. I see a range of skills, not all of which are used on every project, with the data oriented in the pack focus on content planning, the more creative picking up the tasks associated to interaction design and the visionaries grabbing the strategy basket and pushing the boundaries as hard as they can. 

Some people will be able to do it all, from the detail to the big picture. And the more experience they have, the more comfortably they will be able to operate anywhere on the continuum. But, honestly, people who excel at both ends of the spectrum are few and far between.  And rightly so, in many ways. Its the collaboration and the different perspectives that help tease out the nuances in the problem and, later, in the solution.