Saturday, July 16, 2016

How a
technical-minded team expand its skills into UX?

The most common comment I get from
technical/IT people who are interested in UX design is “I’d like to get into
UX, but I can’t draw”.Drawing is very useful, however rough
sketching is really all the UX practitioner needs, and even then it is
generally only used for their own or their team’s reference. UX design is not
just about drawing skills; it is as much about the ability to create a design
solution to a task-orientated or system problem, communicate the design
proposal to the team and then help them build it for their client. The drawings
that my clients see are ones I do in my overlapping capacity as a UI designer.
But I’ve also worked in the past as a UXer paired with front-end developers who
wore the UI design hat.

It can be hard to pinpoint the exact role a UX
designer has. Are they a UI designer or Visual designer? It is generally broader
than that, but they could have those roles as well! As can be seen in the
job descriptions I’ve described below of different UX practitioner roles, the
broad range of skill-sets bought to today’s UX practices means that entry into
the UX space can come from a number of directions. Good skills gained working
in one of these entry vectors can be complimented by other skills that allow
you to come at the problem from a different idea space. UX design by its very
nature has to be collaborative and a productive UX team is rarely a team of
one. I’m not saying one person can’t do all of the work; I’m saying that a team
of one misses out on the benefits of team engagement, peer review, and broader
design collaboration opportunities.

In my experience the ideal application
development UX team has four key members: the planner, the creative, the
validator and the technician. Each has strengths that when shared make a
coherent and formidable team.

So which type of UX practitioner could you
become?

UX designer – the planner

UX designers are really concerned with how a
product or application feels, how it flows, and the best way to achieve a
frictionless task-flow in the application. They are interested in how people
undertake the task at hand, finding what their “pain points” are and designing
systems to alleviate or rid them of that pain. They can sometimes also
undertake initial user research but they tend to be the main UX manager in a
project.

Deliverables:

Heuristic review of the problems to be solved

User workflow assessment and identification of
service delivery touch points

Wireframes and/or storyboards of screens

Information Architecture

To become a UX designer a practitioner will
need:

An online portfolio/links-page that showcases
their skills in online information and application design.

Good working knowledge of some – or all – of
the following: Photoshop, Illustrator, Fireworks, Axure, Balsamic.

Ability to interview users and identify key
pain points to be solved for the user.

UI designer – the creative

While a UX designer worries about the overall
look and feel, User Interface designers – often known as the pixel-pushers –
are the ones that need graphic design skills and be able to draw! They work on
the way a page is laid out, how it uses positive and negative space, how it
presents a visual and semantic hierarchy for the user to successfully
interpret, and fulfilling the design guidance from the UX designer on how the
application should work. As well as the look of the page, a UI designer may
also have some front-end development experience and understand the technical
limitations of the UX designer’s proposals.

Finally, the UI designer will create a
technical reference list and visual style guide for the application or web site
that the development team can refer to when building the front-end components.
This guide will also include guidance on how to present feedback and error
messages to the user, as well as describe common design patterns that are to be
used uniformly throughout the application.

Deliverables:

Visual language, style guide and colour
palette for the site/application

User Researcher – the validator

The User researcher lays out the user’s needs.
They have three questions to answer at the start of a project. “Who are our
users?”, “What do they need?” and finally “How important is that need?” User
researchers are less worried about how a business process actually works and
more worried about how it is presented to the user.

User researchers are great gathers of data to
validate their decisions. It is important for the work of the user researchers
to be continually re-assessed as a project proceeds. Each assumption and design
decision made by the UX team should be tested throughout the life of the
project.

Deliverables:

Heuristic review/User research of the existing
work methods and steps

Personas and user profiling

Task relevance and importance grading

Mid-project health check and final testing of
a project

Support documentation writing

To become a User researcher in a UX team a
practitioner will need:

Cognitive science, human factors or psychology
training

Software or customer service testing and
validation experience

A lot of patience and good listening and
report-writing skills

Front-end developer – the technician

Front-end developers are responsible for
creating a functional implementation of a product's interface. Typically a UI
designer hands-off a static mock-up – or even a prototype – to the front-end
designer, who then translates it into a working, interactive experience that
can be demoed, used for usability and user-acceptance testing and finally go
into production. Front-end developers are also responsible for coding the
visual interactions that the UI designer comes up with.

A web front-end developer on a UX team often
needs to break out from their development-centric mental model to help the team
come up with solutions to complex user-interactions that will push the
boundaries of what a browser was originally built for.

Deliverables

Design solutions as implementable code

Production code CSS, HTML, JavaScript

Technical specifications and documentation for
the development team

To become a front-end developer in a UX team a
practitioner will need:

Front-end and back-end development experience

Experience coding UI prototypes

Fast turn-around when developing mock-ups for
the user testing phase

Ability to put up with work with creative
people

The 1-2-4 formula

If a project doesn’t have the budget for four
people at the start of a project then the team can still be built up over time.
Projects can easily be started off as a team of one IF you have the right
person – the afore-mentioned unicorn* – but generally speaking the Front End
Developer role is the rarest in a UX practitioner.

The team can grow over the project to become
two people who split the theoretical and practical skills, then four where each
of the suggested practitioners mentioned above have defined roles.

Expanding up to eight roles

There are four additional distinct specialist
roles that would be useful to a team if the project budget, time constraintes
or required outcomes warrant it. The tasks undertaken by people in these roles
are covered by the four core roles mentioned above but in some circumstances
these specialist roles could be added to the core team of 4 to build a team up
to eight distinct roles. These may not need to be full-time equivalent roles.

Below are some of the most common additional
roles in the team.

UX Manager

When a project is big enough it is worth
looking at bringing in a manager with UX experience to help corral the team and
provide guidance and focus for the objectives of their work. UX managers will
generally initiate engagement and then provide ongoing management of client
expectations. UX managers can also be the interface between clients, project
managers and the team. This allows the creative to be creative, the researchers
be focussed on their research and the designers and developers to get on with
building the application or web site.

Information Architect (IA)

When a project has a complex information
architecture requirements or a complex data migration requirement a full time
IA is a must. An IA is responsible for ensuring that the organisational
structure and presentation of information on a website or application makes
sense from a user's perspective.

An IA can make vast improvements in
find-ability on complex web sites and web applications, greatly improving 'time
at task' metrics.

Accessibility Analyst

This role is a must for government projects
where sites and web-based applications must meet WCAG 2.0 web accessibility
standards to level AA compliance before they can be signed off. The
Accessibility Analyst works with the design, development and testing teams to
ensure compliance that allows access to government services for individuals who
have a recognised disability that impinges on their ability to use a computer
to access government services.

Content writer

You’ll rarely have both types described below
on your team as they tend to be specialist roles for different types of
projects.

Test content writer

A test content writer is useful if the aim of
the project is to generate written content from internal or external sources.
One problem that often occurs in this type of project is that the development
team do not have experience or knowledge of the user requirements for their
target-market type of high-volume user. Having a test content writer on the
team allows a wide range of test content to be created as the project develops
so that the project can see just how real content is delivered to their users,
and it allows the user interface for the writer to be optimised to suit common
writer’s task flow patterns to be supported by the application.

Support content writer

A support content writer is useful if the aim
of the project is to present complex tasks to the user in a web application
rather than a purely information delivery site.

A support content writer is often bought in in
the development stage to write the help text, provide guidance on clear and
concise field and navigational labelling, and write the user guide for the web
application. Sadly the role is often the last person on board in a project and
so the project can suffer if too many decisions have been made without a
support writer’s expert guidance so every effort should be made to bring this
role into a project as early as possible.

A final note of caution on team culture

There can be a cultural issue in moving from a
technical systems-trained background to a UX design space. For instance, I know
of BAs and developers who have moved successfully into the UX space, but to do
so they have had to fight their propensity to give more weight to the business
or technology requirements rather than the user requirements.

Where BAs could
be seen as the documenter of business and systems processes, the UX designer is
first and foremost the champion of the user.

Some developers really don’t care what a page
looks like – they just want it to work and they see that as the end of their
involvement - “I’ll make it work and you make it pretty” is a common refrain
and developers can be naturally biased towards technologies they know and are comfortable
with. Yet I’ve met developers who work as hard on the front-end look and feel
as they do working on back-end.

BAs and developers working in the UX space
must learn that all needs are to be viewed and weighed together. Either way
experience has shown that they both appreciate a competent UX practitioner’s
guidance during development.

Friday, July 03, 2015

In the beginning...In the last 200 years the built world has seen architecture grow from engineering, industrial design grow from architecture, and software design grow from computer hardware design.Ideas from the creative world have grown with the advances in the built world; so it is in the software world. New companies have been created using totally new business models like desktop publishing, digital graphics, computer aided design and now whole movies are made with computer graphics imagery. These applications have grown to be quite complex and the barrier to entry for any later comers was daunting.Enter the internet with a web interface providing first a hypertext linked access to military, technical and scientific information. It continually grows and morphs until complexity forces the creation of a range of specialist’s skills to help the web grow through its birthing pain-points.This is the well-spring from which the UXD community has emerged.Although it could be argued that industrial design, architecture and computer science all provided precursor skills to the UXD world, UXD is mainly the result of the marriage of Information Architecture (IA), and Human Factors Engineering (HFE), where the librarian component was dropped from AI and the mechanical engineering was dropped from HFE, since UX focussed on more than just indexing and information and didn't need to worry as much about the mechanical engineering and ergonomics of HFE since the interface was virtualised and planar.UX has also sprouted more than a few siblings, like CX (Customer eXperience) and Service Design, both of which look at the larger user experience world outside just electronic interactions and the design of computer interfaces.

Service design looks beyond the human/computer interface and designs in real-world interactions as well

These user-focussed areas look at whole systems in the
real world as well as the virtual and UXD practitioners can use lessons learnt
in CX and Service Design to match on-line services with real-world
touch-points.

There is also the allied practice of digital design which
is the cross-over point between graphic design and interface design where
traditional advertising meets online marketing.

The UXD space is growing with the advent of a wide number of specialisations, however it originally started with three main disciplines:

·User Interface Designer

·Information Architect

·Human Computer Interaction Analyst

This is getting a bit complicated, and when I saw the Venn diagram (below) showing experience design and computer science, human factors, industrial design, architecture and computer design all having partial cross-over into the UXD space, I thought we finally have a model that can explain it all.

Each of these professions had before them a number of influences based on the pre-online world, however early computer interaction work in the 1980s/90s was mainly done by individuals who learnt on the job. They kept going until the jobs got too big for one person and so specialist roles emerged.

Made by the former German UX consultancy envis precisely, based on Dan Saffer's original work "The Disciplines of User Experience"

The diagram above attempted to bring a kind of infographic overview into just where things are in relationship to the way we manage design processes today.It is complicated and still lacks references to customer experience design and service design, has Writing in a tiny little circle just nudging UXD (WTF!) and Marketing not even touching Communication design? Anyway, it is a start and I'm not the one to go down that rabbit hole to fix it since I have a strange feeling it can only be achieved in 3D!Back to UX-centric roles

Since 2000 the following roles have been added on the
creative side…

·User Centred Design Researcher/Planner

·Visual Designer/Digital Designer

·Interaction Designer

·UX Architect

·Motion Designer

·User Experience Designer

·Data Visualiser

·Test Content Writer

…and the following roles on the development side:

·Front-end Developer

·Design Technician

·Prototyper

·Videographer

·Data Wrangler

…along with the following production roles:

·Digital Producer

·Content Editor/Wrangler

·Content Writer

…plus the following client-side roles now have a link:

·Product Manager

·Customer Satisfaction Analyst

·Change Manager

·Marketing Manager

·Marketing Analyst

…and so the UX Unicorn* is now dead.

Traditionally the practitioners in UXD came from the
design community, however science has been added to a broader UX industry today
of the following roles:

·Cognitive Psychologist

·Ethnographer

·Anthropologist

·Neuro-anthropologist

·Ergonomist

Although these roles are beyond the “design” part of UX
they do show that there is now a healthy and growing ecosystem building around
the UX industry.

It is only getting bigger. I can say I've actually had to do most of the work described above in my working life, and much of it with a fair bit of cram learning via Google or its precursors, Alta Vista and O'Reilly technical books.

Now my problem is when talking to clients who are totally confused over where I sit in their scheme of things, How do I explain where I am located in this great mass of allied user experience roles today?

I think I'll have to get back to you on that one once I read up on proto-ethological anthropology and immersive 3D data modelling! ;-)

* “UX Unicorn” is a
name for somebody who can do all of the above rolls. It is a bit of a joke in
the industry because UX Unicorns are now a myth and no longer exist, however
clients keep wanting to hire one all-rounder rather than a team. There really
aren’t any all-rounders left who can grasp and action successfully all of the
tasks that go into online software development and production these days. And
if there are, they command top dollar.