Embedding a new user experience team

Almost 3 years ago I left Yahoo! and London to embark on my new role at Symantec in Gloucester. I have honestly loved every minute of it…despite the regular sleepless nights!

At the time of joining my host organisation ‘MessageLabs’ had been acquired by Symantec and there were many big changes taking place…I was one of them.

Symantec already had a sizeable user-centred design team (which is excellent!) in the shared engineering service group, but I was the first to be embedded into the Symantec.cloud division. There were no other designers, design patterns or visual assets…hell, there wasn’t even any other Macs and nothing on the intranet seemed to work! It was a complete nightmare compared with working at Yahoo! which had a large Mac user base.

I was thrown this challenge (and I am paraphrasing…a little):

Make our complex IT products more accessible to the less IT literate small/medium sized businesses (SMB).

I thought it would be valuable to talk about my experiences of embedding a user experience team into an engineering organisation. I don’t confess to have perfected the process of embedding a user experience team into an engineering organisation, but I do feel that I have made significant ground on the challenges I saw at the time.

Misconceptions

We just make stuff look prettier

Its easy to get upset when people think that all you do is, take something an engineer did and make it look pretty. Try to resist the temptation to get into a vigorous discussion with someone about user experience design.

I quickly came to realisation that many folk, just won’t get it. You could rattle on about user research, pattern libraries and user flows for as long as you want but all you will do is wind yourself up and probably annoy the person you are talking to. That’s not a good place to be.

The best response I have found is, ‘Yes, making stuff pretty is part of what we do’. I then leave it until I actually work with them on a project to expose the full spectrum of user experience deliverables.

I am not Jesus and I certainly don’t have the talent or social charisma to convert everyone into interaction design ‘believers’, but what I can do is work hard to show promote its value on specific projects. People get that, consistently and without doubt.

We don’t do any work, we are just layabouts

I guess one of the problems with digital world is that you could be sat next to someone and they will never see any of your work because the people you work with are the other side of the earth and on an entirely different time zone.

If we were building a sculpture out of clay in the office people would take probably note. They might not understand it, but they can see effort. Digital work is different, unless you are clicking your mouse and keyboard at rapid pace throughout the day, its almost understandable that folk might start thinking that you don’t do any work.

Now engineers are tapping all day. If its not emails, its code. They sound busy and its an accepted or standard mode of business, so they may go around the office and engage in conversation with other engineers about how busy they are. Because we are a smaller team, we can’t do that…and there in lies the potential for misinterpretation.

Designers are generally passionately motivated about the work they do for the business and customers. They don’t see their work as a chore – they love what they do and why they do it: its customer driven (or socially driven), not technology driven. We are dealing with a the subtleties of of web development making the choices that help our business to be more successful than it’s competitors.

I digress a little.

Going back to the title of the section, this is a short sighted comment and those who suggest we are lazy are probably either covering their own tracks or jealous that we love our jobs so much. Ignore 100% or if it bugs you that much, take them into a meeting room and let them know it bothers you. If they persist go to their manager or HR. Its toxic and disruptive.

Everyone seems to name any document we create a ‘wireframe’

…and actually, it doesn’t matter too much. They can call it whatever they want, as long as the find it useful document to discuss and challenge – that’s all that matters.

Visual stuff doesn’t take more than an hour to produce

If you show someone a few page designs, they might be tempted to say that it only takes a couple of days to knock up; and of course, they have no idea that to establish the final designs you have to create user goals, user scenarios, user flows, wireframes and conduct user research to validate the approach.

It can be a bit of a chicken and egg scenario: You won’t be given the time you need unless they see value, but you can’t produce the value unless you are given the time.

The only way I could make this happen was by working closely with product managers and project managers to explain and explore our processes in detail. Make sure you tailor your communications to talking about time benefits with the project managers and quality benefits to the product manager. That is what they care about.

 

Do more of…

Talking to engineers

It is really important to get an understanding of every engineers skills and the challenges they face. They are usually up against some crazy time schedules and you could significantly cut their work load by making small changes to your designs.

Show and tell

When you have a great story to tell about your contribution to a project, tell everyone. In fact tell everyone and their dog! Promote what you did, as it will pave the way for other designers when they work with the same folk. Put the work on the walls, and be prepared to explain what you did when people stop to take a look.

Wiki/Sharepoint use

Making your work available to everyone in the organisation (and at all times) makes a huge difference to collaboration and exposure of our work. You can fire links around the company with very little effort at all. Granted, its a bit of a pain at first to set up project wiki pages and document every change or meeting…but its an impressive resource for all to see.

Clickable prototypes

People love stuff they can interact with and it doesn’t matter if its a very linear/strict prototype. Going the extra mile to product a prototype will ensure you get the buy-in you need – guaranteed.

 

Do less of…

Using UX or IA terminology

Pretty much everyone you speak to won’t understand words like: Information architecture, cognitive overload and mental models. Don’t waste time educating them, make it clear and concise in normal every day language.

Trying to convince people of the value of user experience/interaction design

Some folk are just so die hard against designers, its not even worth wasting your breath, but that doesn’t mean you should stop working with them. Always make yourself available and always remain positive. Hold out for the right scenario/situation to expose the value of your work.

 

 

 

 

 

About graham

Gadget-obsessed user experience designer/manager. Compulsive cleaner and reluctant runner.
This entry was posted in Business, Leadership, User experience. Bookmark the permalink.

Facebook comments: