So, what role am I this week?

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.

UX design needs to be part of IT culture

It is obvious that there are a growing number of projects that will benefit from user experience (UX) work but in the past the judgement was that the benefits were not obvious, or not thought necessary. For a lot of people UX practitioners are some exotic animal that consultants and developers have heard about, but they never actually come across them in the wild!

I’ve worked in the application design space variously as a web designer, information architect, user interface designer, front-end developer, user-centred design analyst and usability business analyst. They are not the same thing – there have been subtle differences in the actual work, from being in effect a hands-on front-end developer to doing initial assessments of the service design touch-points between customers and a client’s systems.

I came across this interesting snippet about Mark Kawano on CoDesign, Fast Company’s design magazine on the web:

…Kawano was a senior designer at Apple for seven years, where he worked on Aperture and iPhoto. Later, Kawano became Apple's User Experience Evangelist, guiding third-party app iOS developers to create software that felt right on Apple's platforms. Kawano was with the company during a critical moment, as Apple released the iPhone and created the wide world of apps.

“I think the biggest misconception is this belief that the reason Apple products turn out to be designed better, and have a better user experience, or are sexier, or whatever . . . is that they have the best design team in the world, or the best process in the world,” Kawano says. But in his role as user experience evangelist, meeting with design teams from Fortune 500 companies on a daily basis, he absorbed a deeper truth.

“It's actually the engineering culture, and the way the organization is structured to appreciate and support design. Everybody there is thinking about UX and design, not just the designers. And that’s what makes everything about the product so much better . . . much more than any individual designer or design team. (Read the full article here.)

The key takeaway here is that a design engineering culture is very important to Apple. At Apple, everybody does design – it is not just one small part of the company. They have lead the push and now others in manufacturing and service industries can see now the results that are possible under a concerted effort to cultivate a design-based culture and some will want to find a way of emulating that culture for their own business.

Building culture internally

The ITC culture I see today is far more of a technical engineering culture than a design engineering based culture. This technical engineering culture is based on a need for quantifiable results. Emotion-free data. Fixed known deliverables. Minimum viable product specifications. These are metrics that techs understand well, and the pure design culture’s lack of uniformity in this respect is hard for technical engineering cultures to understand and embraced.

I see this technical engineering culture every day on chatting to the tech staff I work with, and taken with my experience working in large organisations, this insight allows me to engage on that level, even though I originally came from a pure design background. There is a willingness of people to engage in tech-focussed online forums and expand on their experience on projects and with technical problems and solutions. This is fantastic and a good way of promoting a change in culture. Yes, there are hints of tribalism, but there is comradery, healthy punditry and a community willing to engage and to contribute.

So the first thing to do is create these channels internally. Allow freedom of speech and ideas inside your enterprise and make sure the senior staff also become part of the conversation. Create an internal Meetup, use Yammer or build a wall of ideas in Trello. I've used them all and they all work as long as you have a UX champion to prime the pump.

Conversations with tech-heads

I recently read a comment from Nathan Barry in one of his monthly newsletters. Nathan is a designer/developer/entrepreneur and author of The App Designer’s Handbook, and these comments really say it all:

At the last software company I worked for, plenty of the developers completely ignored design. They even overlooked the most basic design mistakes. Sometimes I’d push back when they tried to put subpar design work into production; inevitably, one of the developers always replied: “Does it function? Good. Design’s not my job.”

They could get away with it because we had 4-5 software designers on staff who would come through and make the work look good.

I always pushed back because my goal was to get everyone at the company to care about the product. I thought everybody should make decisions and do work based on what made the product better, and not draw arbitrary lines between design and development.

As a developer your job is to release the best product possible. Which means design actually is your job.

All aspects of user experience and interface design are now part of the full stack of application development skills you’ll need in the future to move ahead.

Being a very tightly focussed specialist will make your career path smaller and smaller. You really don’t want to be the guy that excels at making CSS render round corners and transitions work on IE8.

Design Culture = Bigger work pipe

Any development team provider who wants to promote their ability to deliver flexibility and competency in the full gamut of design and development skills would benefit greatly by supplying core design and development team members whose work expands their sphere of influence at a client site. Having a client thank you for helping their team be more cohesive, provide a more holistic service and add value and knowledge to the project is an aim that will bring rewards.

And definitely extend your contract.

PS: Just remember you need to build skills; you don’t need to change horses.
If you are stuck in the same type of developer role again and again and think you want to branch out into UX, send this article to your boss. 

This post was also published on LinkedIn Pulse, June 30, 2015

UX skills across a team

Now that I'm back in the land of the independent consultant and not under the yoke of a consulting company, I have the freedom to make public a few thoughts on the way UX practice should work in large IT-focussed organisations.

This posting is prompted by an article that Jared Spool wrote on his UIE site:

Hiring UX Experts Versus Giving Your Team Their Own UX Skills

(You can read the full article here. http://www.uie.com/articles/hiring_ux_experts/)

He starts with the question "Is there a conflict between providing expert services and training for those skills?"

I've always loved how Jared can craft a message that gets to the nub of the matter and he nailed it in one page.

My attempt at putting the same argument forward 6 months ago to upper management could probably have been better prosecuted by Jared, but then I work in a business that needs everything documented and old habits die hard and I like to back up my arguments with research and hard statistics.

The take-out from Jared's post is that 80% of UX work is routine and when learned and understood by everyone on the team, it creates consistently good design outcomes.  I've found this to be the case when I build comprehensive UI design guides for large enterprise projects that create a design template that developers can read, understand and then run with, without coming back to me for every design decision. If I can solve these problems for them before they even come up when a front-end dev is building a page then they are happy.

Shifting technicians from system thinking to user-centred design thinking allows them to widen the scope of the design problem, but in turn gives them a better view of the world that the application solution sits in.

That is the first step. The next step is allowing devs to start solving those 80% of problems and leaving the tricky stuff to the UX professional.

The big plus for that is you actually have a higher-skilled team of consultants available who can then be seen above the crowd of coders out in the marketplace. Some people just don't see that though.

Pity.

Communication and education as a team sport

It occurred to me today that a conversation I had with my boss of the time nearly 10 years ago encapsulates the problems I have today trying to promote the UX profession.

I was asked to work in a way that suited the Project Manager’s defined methodologies and my answer “I don’t work that way” was construed as “I won’t work that way”. The boss hit the roof and reminded me who was boss.

Of course I realised straight away that he had misconstrued my statement, meaning and level of deference to the management hierarchy - I should have promptly explained the WAY I work best, then proposed a path that would suit us both.

We both needed to find a path, to understand each other's problems, capabilities and worked as a team to solve the issue; in effect we needed to educate each other.

Levels of priority as a concept - seriously!

So, what does "High Priority" really mean?

A requirement has come through that a job must be able to be marked as "High Priority". Simple enough? Well, as in all things UX, the answer is yes... and no.

The reason I started asking what it really meant was that I'd seen users game the current system's definitions and implementation of a "High Priority" setting. Their "High Priority" had a business rule that meant that a warning flag was sent to a senior manager if a task was not completed within X days of it being started. The task included a number of information gathering and data entry tasks that very often could take more than X days since there were sometimes a lot of dependencies (including other tasks that had the same time limit!).

Their solution was to do the entire job manually outside of the system that was built to manage the collection of the data. The data set was collected in a word processor document and only then did they start the data entry task inside the system by copy and pasting the results from their information gathering, and finally save the results in the previously time-limited application.

All on the same day.

OK, so the job got done, you say. But the reporting and time management data that could have been gathered at the same time was totally useless. There was no way of knowing how long each different task took, so efficiency reports were useless. And the data was captured outside the system, so managers have no idea at any specific date or time the state of each task with their individual workers, or within the team as a whole.

In the end, the "High Priority" setting was no solution, and added risks to the system that should not be acceptable.

So, how do you fix this to help all users?

You must go back to the original idea that prompted the concept of a "High Priority" setting as the solution.

Again I ask, what does "High Priority" really mean?

High priory really in this case means "I want this done quickly". But high priority as implemented in the example above meant “get this done within the time-limit or you’ll be reported to senior management”.

The aim is 'fast work throughput', but the solution is ‘cover your arse’.

The point is there should never be a need for that non-perform flag to be sent to the senior manager. The workflow and operating procedures should have the potential for manageable escalation built in.

The problem can be broken down into a number of points:

1. The business rule is linear and too rigid.
2. The rule is often unachievable as the same rule can apply to individual sub-sets of the measured task.
3. A consequence of the rigid rule creates inaccurate metrics...
4. …so analysis is based on inaccurate data.
5. There is no gradual escalation of the issue; just a big stick, 
6. Users that run out of time do not normally just work faster, they cut corners or find a way of conforming to a rule that is outside the original intent of that rule (as in the case above).
7. The flag is being used by the manager, not the team.

So from a usability point of view, how do we solve all of those issues?

Let's look at that list and reverse it.

The last point, point 7, is in my list is actually the starting point for a better way to design the system. The team should always be the driver, not the manager. The users must be given visibility of that flag and provided with up to date information on how to beat the flag rule without going outside that rule’s intent.

In point 6 we see that although the rule's intent was to push high priority tasks through the system first, the result of gaming the rule meant that the high priority flag had an unintended - and potentially dangerous - outcome. Tasks escaped the 'system' and was not visible while outside that system.

Point 5 shows that there is an heavy imbalance between the managers of the system and the people actually doing the work. Rigid rules and big sticks only tell your workers that you don't trust them to complete a task successfully; a task they have been hired to do after going through an interview process to allow a manager to pick the best person for the job. If you, as manager hired them, why don't you trust your own judgement in them? End even if you didn't do the direct hire yourself, isn't part of a manager's job to make sure their team has been trained to do their job?  

Now, points 3 and 4 are linked: inaccurate metrics creates inaccurate data. Inaccurate data means that decisions are ill-informed.

Point 2 really means look at the whole system. Creating arbitrary rules made without looking at the holistic consequences of that rule is just plain bad management. And leaving that rule in place over several years brings us to the initial point.

For in point 1 rules need to be degradable. In programming every decision has options - the 'if' statement is there for a reason - it allows a programmer to look at what happens next if an event occurs. It defines options. It must include, within reason, get-out or postponement clauses that allow staff to do their work in a flexible - but still legal - manner. By all means you still need a red flag event, but that is the LAST step, not the ONLY step.

In the case above only one rule was made. Make this task high priority. The intent was to speed up work for high priority cases. The result was to put a major flaw in the system. That is NOT why we make a task high priority.