User Experience (UX) Roles vs Information Architect Roles (IA)
This is just a quick post showing the basic level differences between User Experience (UX) Roles and Information Architect (IA) Roles. I'm working on a full model post as well, but that is still being written.
User Experience (UX) Roles.
User Experience (UX) Roles Diagram
User Experience Architect (UX Architect)
Gathers requirements, defines the system features (functional specification) , user journeys, personas, interactions, sitemaps, wireframes, data models, conducts research, writes testing protocols and conducts testing.
Interaction Designer (IxD/UX Designer)
Defines interactions, sitemaps, wireframes, based on requirements from the more senior UX Architect.
User Experience Researcher (UX Researcher)
Conducts research for the User Experience Architect (UX Architect), Interaction Designer (IxD/UX Designer) or for a User Interface Developer (to apply common patterns).
Usability Tester
Works with User Experience Architect (UX Architect) or Interaction Designer (IxD/UX Designer) to define the testing formats that are conducted during research, design and development project phases.
Accessibility Tester
Works with User Experience Architect or Interaction Designer (IxD/UX Designer) to define the testing formats that are conducted during research, design and development project phases.
User Experience Tester
Conducts user acceptance testing for the experience in line with the personas and user journeys.
User Interface Developer (UI Developer)
Interprets the functional specification, sitemaps, wireframes with the aid of the User Experience Architect (UX) Architect and Interaction Designer (IxD/UX Designer) to avoid losing key featured defined for the specific audience. This is a negotiated process where the UI Developer is able to express their deep knowledge of the front end code capabilities and can be an area of conflict if the UX practitioner does not respect their capability and fully explain the reasons for the design elements.
Information Architect (IA) Roles
Information Architecture (IA) Roles Diagram
Information Architect
Gathers requirements, defines the system information features (information specification) , conducts content audits, information research, data architecture, writes tone of voice, defines taxonomy, content strategy, word based marketing strategy and content object model.
Content Auditor / Researcher
Conducts information audit of existing system (if one is there) and research into area specific language.
Taxonomist
Defines the taxonomy for the system based upon the Content Audit and Research.
Content Strategist
Writes the content strategy based upon the Content Audit and Research.
SEO, SEM, PPC Strategist
Defines the keyword structures based upon the Content Audit + Research, keyword logging and meta standards.
Content Object Modeller
Writes the content object model based upon the Content Audit + Research, Content Strategist and SEO, SEM, PPC Strategist.
Content Author / Developer
Delivers content that fills the content object model and is in line with tone of voice.
Related
- Information Architecture (IA) the classification of information
- Information Architecture (IA) the classification of information Part 2 - Educational publishing and courses examples
Getting UX done, the engagement process
UX is a highly complex set of research tools and outputs, the use of which is dependant upon time, cost and the clients willingness to accept them.
Question 1, why are you there?
If the client were to think in best practice terms which for them would deliver exactly what they require then everyone would have a great experience of the process. Unfortunately it is pretty much a given that clients want to prove themselves knowledgable about well everything, in control and this is one of the main problems. I often hear clients say "I understand our users" or "I built this company so I know what users want" maybe they did or used to, but the fact they have called in an agency or consultancy means they don't anymore. What clients mostly mean is I have my agenda and I want you to listen to it and agree with me. That way is the road to mediocrity.
What does the client really want?
It's worth at this point asking the client what they want out of the process. If they only want a pat on the head and to be told they are great, best to give them that, do the job get paid and don't put it on your CV.
If the client (really) wants their products or services to have higher impact, increased transactions, market share and gain advantage, then explain what your doing, how they gain and that great ux will fundamentally change how they work.
Question 2, what does your client understand about what your doing there?
UX is not UI, the experience is not only the interface, it's what you can do with the interface, what tasks can be completed, what data can be inputted, transformed or called into the UI.
The real pitch for real UX.
The pitch to a new client is not we can make your product or service like your competitors it's "we can make your offering stand out from the crowd". Great ux is about shouting over the noise and changing the rules, "don't catch up - great ux creates the opportunity to jump ahead".
Question 3, how will your client know they have succeeded?
This is not a KPI hunt, clients are not really interested in you proving success, they already have their own success metrics, strategic plans and objectives they need to report up the chain. They may not be able to directly tell you as these things are highly confidential the important thing from an engagement perspective is can you work them out? Then can you articulate these back to the client in ux terms.
The real job of ux, find out about the users.
The real job of ux is to align the business with the users, from the user perspective. Users ask "what's in it for me", "what do I personally gain". This means that user research is required by the clients customers, in order to work out what they want for from the business in order to take up their services or buy their products, how they will want to interact and what they will give the business for a relationship.
Banking Change Management through User Centred Design (UCD)
There has been massive change management taking place across all sectors of British banking over the last three years. Much of this is driven by buy outs and mergers, some by efficiencies and a little more recently through questioning the nature and controls around risk management.
However simply changing the owner has caused major problems in these banks as their competitive advantage and therefore their value has been an amalgam of very different skilled people, internal processes and market penetration from the bank or group buying them. These internal processes have often evolved in a highly organic method through acquisition and proven delivery often driven by individual people. However once this people based relationship is broken and these processes are exposed to a wider audience they pose serious questions in relation to risk management, value and the continuance of revenue flow.
The standard process applied has been to pass these processes over at division level to change program managers, at department level to business analysts to define the scope of the current structure. After definition many of these process based activities are passed over to information technology to resolve. I remember being taught at University (Napier, Edinburgh) that technology should never be used as a substitute to sound business process; however this technology determinant does not seem to have been passed on to banking business people. While not the best starting point, people who work in technology do tend to ask the right questions, to define epic requirements, even when it’s unpopular with the business.
Information technology analysts take these epic requirements and define an A to Z system 'what it does'. However to get the B to Y user requirements (or stories), a user centred design analyst, ux research and designer spends time with the users to define 'how it works'. This may seem obvious to digital practitioners outside banking, but it’s a revelation to those inside banking and banking technology, that users who normally find ways around poor software are able to define the requirements that turn a useful application into a killer application.
This is not really the end, more a beginning, if other sectors can learn from banking, that users (not stakeholders, usually no longer active users) can determine the overall success of software. And that user centred design (UCD) can assure and amplify competitive advantage if underwritten by skilled practitioners, then the possibility of success is significantly raised in all software and change programs.
User experience as a process
Process thinking in user experience
The first step in user experience needs to be the recognition that every problem is different and will require a separate solution. Because if they are not, then every business is the same which they are clearly not.
In effect there is no quick fix or standard method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method without flexibility should be ask to leave as they about to cost you a fortune.
Offering user experience services is a bit like dungeons and dragons in that you role your 12 sided dice and hope the business does not throw some trolls at you.
I have worked with very well known agencies who are unable to get their clients to understand the importance of user experience - research, testing and design as they focus on the design component without proper understanding that it is only one part of a three stage process. The reason that clients give for not paying for research and testing is the assumption that user experience people a such great experts that they can do their job in total isolation from the business and the end users. Maybe 'Super User Experience Person' does exist but I doubt it, more importantly users change.
Some process steps for user experience
This process list is based on personal experience and is open to reduction or extension based upon just how savvy the client is and how must they really want to be successful rather than just being seen to be doing something.
1. Understand the problem
2. Do research
3. Analyse research
4. Get validation
5. Compose concepts
6. Create buy-in
7. Define the audience (actors)
8. Create personas
8.1 Research
9. Define critical tasks
9.1 Research
10. Define key pathways
10.1 Main pathway
10.2 Alternative pathways
10.3 Failure pathways
11. Set the tone of voice
11.1 Type of language
11.2 Level of formality
11.3 Use of jargon, brand identity or subject specific words
11.4 Content style
11.4.1 Meta standards
11.4.2 Content object model
11.5 SEO if web based
12: Wireframes
12.1 Selection of type & method
12.1 Wireframe Concepts
12.1.1 User testing
12.2 Wireframe sketches
- Client sign off
12.3 Wireframe prototypes
12.3.1 User testing
- Client review
12.4 Wireframe & Visual design integration
13. Functional specification & analytics specification
- Pass to development
14. Usability Test plan
15. Accessibility Test plan
16. Functional & Content Test plan
17. Testing handover with participant screening document
18. Review testing results
19. Modify labels, interactions & structure in line with findings
20. Done, until .....
21. Check interactions based upon analytics and more user testing.
22. Offer enhancements to clients.
Translate
Switch site
Twitter Updates
- After seeing the http://t.co/3e6fV6UA boom and bust, I know business model is important revenue is critical. http://t.co/df6Kprl2 3 days ago
- I still keep seeing graphic designed UI without any UX thinking so 'Less UX fluff and more Proof of the pudding' http://t.co/NUBfyZfx 6 days ago
- When I did my exec training in the 1990's this sort of thing was described as a key indicator of a disconnect between vision and capability… 1 week ago
- The sad thing with British Airways, I was in T5 trying and failing to book a ticket. I want to buy, they want to sell http://t.co/sg4V6mdR 1 week ago
- British Airways security update stops ticket sales « Karl Smith User Experience Architect (UEA) http://t.co/htJxLsuA via @Digg 1 week ago
- Does the 'have a go' attitude of many companies detract from real digital strategy?: http://t.co/e3KbdQjF 1 week ago
- http://t.co/HYOeiOy3 You don't allow changes during a sprint, you suspend or review tasks and put them back into the backlog, but you... 1 week ago
- Writing strategies for digitalization corporations since 2002 that have business process change, market movement, governance and technology. 1 week ago
- http://t.co/Nfmsw2lO I have been writing stratagies for digitalization for major corporations since 2002. Digital changes every day but... 1 week ago
- http://t.co/5bP9W37b UX research and design can evolve in Agile however the framework should be established 1 or 2 iteration before... 2 weeks ago