uxstudio

I recently posted the following question to a group of Ux professionals: What is the single most important activity that a user experience group can do to increase its effectiveness and influence? I asked everyone to draw from their real-world experience, NOT theory or ideals.

There were a number of thoughtful, practical responses…

Jeremy Ashley said:

1. Take time to truly understand what your company, organization, executives, and program managers need from the user experience. Accept that they know their business, and your role is to help enable that.

2. Hire in skills beyond the traditional designer/usability engineer roles. Hire PM’s to help effectively communicate with the outside PM and dev teams, as well as support project management. Hire developers to help understand real world implementation issues and opportunities. Hire marketing specialists to help evangalize, promote, and train both within and outside the company

4. Determine your plan and follow it. Modify it only after significant discussion with senior staff to ensure you examine all angles and possible outcomes. Do not get distracted by ego, politics, or emotion as you will waste your time reacting rather than driving.

5. And finally….The only way to impress your boss is to DELIVER

Steve Fadden said:

If this is a group with NO UCD experience whatsoever, I think nothing beats a good usability test. Not so much for what it tells you about the product’s usability (though that’s always helpful), but because it gives you a lot of “bang for the buck” in terms of access to information:

• You gain access to a real or potential user who comes in for the test, so you can talk to that person about her/his demographics, skills, expectations, work environment, key tasks, performance measures, and so forth.
• You gain the ability to observe a user trying to use your product. This can be especially value if you can
• get other members of the team to observe, as it opens their eyes and increases buy-in for more UCD
• activities in the future. You gain the knowledge about key problems with your product right now. So you have the opportunity to highlight these problems and address them in your work (it also provides a way to prioritize the problems from a user’s perspective)
• Last but not least, you can get ideas for solutions from the end-user’s perspective. It’s not the only solution path, but a valuable one to ensure that is represented in the iterative product development process.

If it’s a group that’s already doing some usability evaluation (with real target end-users) as part of its process, then I think the next beneficial activity is some form of observational activity of the end-users in their context of work. This might be in the form of simple site visits or complex contextual design activities, but the important part is to ensure that people on the team are able to observe a number of end-users in their ‘natural environment,’ interacting with the the people, systems, and resources that are common for the work or activities being performed.

Paolo Malabuyo said:

Make sure that the culture of design and user experience is explicitly supported from the top. Unless executive management cares about user experience, it’s going to be an uphill battle throughout. Grassroots organizational support can only get you so far.

For me, choosing where to go next had a lot to do with this. After 12 years working for 3 large companies (IBM, Oracle, and IBM) I’ve had a lot of exposure where the culture is not one of design but of engineering. Trying to change a company’s DNA is very difficult, and without that change happening from the top I don’t know if it’s going to happen in a deep and sustainable way.

Any cultural change is going to be seen by an organization/organism as either an infection or a mutation. In engineering cultures, you want design culture to be a mutation; unfortunately, the organization will react as if its an infection, and the white blood cells will do everything in its power to kill it. It will not be a mutation unless there is support from the top.

In my current company I’m able to have that support and explicit activity from the top. In my previous job at Microsoft, the results of some of these activities can be seen in the Xbox 360 (not to be confused with the current hardware failure problems!) user interface and capabilities. Time will tell whether what we were able to do will take hold as a successful mutation or will eventually be eradicated as an infection. My fear is that it will be as long as top management doesn’t explicitly support and prioritize design and user experience.

Michael Arent said:

Make sure the group has effective leadership that can influence up and down the foodchain. Effective leadership means a person or persons who have cred in the industry — leader(s) in his/her field.

Adrian Howard said:

Stay with a project from the start to the end. If at all possible be in the same room as the people doing the work on the project at any point – even if this means finding a room and forcing those folk to work there

In my experiences the places where the UX process often falls down is communication. People can very quickly move off track and miss the “whys” behind the design decisions that were made. Without somebody on the spot these can quickly push a project off the rails.

Having somebody on the spot all of the time means you’re available to resolve questions and problems immediately. The inevitable changes due to plan-meeting-reality can be dealt with quickly. You can spend time educating the rest of the team in the UX issues.

(In fact, that last point – educating the team – is the real “most important activity”. The best way to build better products is to stop having a UX Group and start having a UX Company. The best way I know of starting that process is to spend all of your time mentoring people outside the UX Group).

Phillip Shoemaker said:

Prove your effectiveness. Much easier said than done, but let’s make this extremely clear: in many companies, they take user experience for granted and don’t value you as much as they should.

I’ve lived on both sides of the coin: at Palm doing UI after Jeff and company left, and it was taken for granted; people just thought it would happen, even if you didn’t invest in good resources, or user testing, etc. And then again at Real, where we invested significant resources on testing device UIs.

The key is to prove your effectiveness, or show management what will happen to the product/company if they don’t invest in that group/area.

Another key thing to do is to find the real influencers in the company, and get them on your side. Remember that the key influencers in most companies are not the managers. Rather they are particular engineers, product marketeers, QA technicians or the support personnel. Get them on your side, and you’ll start leading by influence, and proving your effectiveness.

Luke Kowalski said:

Automation of the UCD process is the single most important success factor. This becomes more effective the larger the number of applications the designer has to support.
Automation defined:

• Making requirements gathering, prototype review, and quantitative testing a required “bus stop” of the development process (F.e.: Every team must write a user profile before proceeding to the Business Requirement Document)
• Baking in code based templates (UI layout reference library) inside the development tools
• Delivering predefined designs and base widgets as part of a flexible, and modular development environment. Forms and flows can be mashed up and swapped out declaratively, without having to change the code. This design also allows for changes later in the development cycle.

All of the above free up the designer to do front end work like talking to customer and gathering UI requirements, designing the information architecture. It leaves the layout police clean-up work to the tools, and to the development process, the automated part….

Glenn Cochran said:

My answer is simply this…partner, at all cost, with the engineers writing UI code.

The most effective teams I’ve managed always work closely, if not literally side-by-side, with UI engineers. Back at Blue Martini we partnered with engineering and created a shared component library used in mutliple shipping applications. The component library rendered a standard, highly-branded look-and-feel as well as provided desktop-like interactions in a web broswer. This isn’t to say that what we achieved was having all applications so equal they were bland and generic. Each product also had custom code for specific interactions and concepts unique to the product itself.

The impetus for this successful partnering and building of this UI framework was largely driven by the sales team. The suite of existing products with unique visual designs and interaction models was complicating the closure of deals in the pipeline. In addition, the applications could be highly customized during deployment but were not standardized in any way.

The sales team worked closely with my team to refine which applications should be doing what and exactly how they were ultimately demoed, utilized, and deployed. The idea was to simplify the cross product differences while still focusing on the specific roles of users in each product. My team delivered new designs, focusing largely on reusable components, their interactions with the user, and the overall UI architecture (menus, toolbar, navigation, etc.). Ultimately a reusable framework was built by engineering and was used to rebuild four products. The engineers loved the challenge of building the UI framework while the sales team loved the simplified product offering with a standard look-and-feel and extensibility model.

As for the organizational change, the main hurdle was on the product management side. We had to get total buy in from the product managers of each product we planned to convert to this new design. Ultimately we started with two product managers that worked well with my team and proved the concept could work on their two products first. After that, it was only a matter of time before other applications started to look dated and out of sync with the new design and product managers began asking to have their application updated as well.

From concept to implementation, it took about 1.5 years to get four separate products converted and looking/working like one another. The lenght of time was largely related to current release schedules all ready in play. We had to balance new features with the overhaul of the UI design across two releases, typically, for each product to complete the effort.

The end result was a set of applications which worked well, that looked as if they’d come from the same vendor, that were highly branded, that were simpler to use, which provided an improved experience for users that was more desktop-like in nature. The sales team was able to simplfy their demo suite and ultimately sell more product.

For my team, this effort was great deal of work and was often frustrating, but in the end we were highly effective. One thing I learned on this journey was that previous approaches constantly speaking about ROI, ranting about needing to do more user testing, stating how UCD is the most important function in the company, basically were herd but not taken seriously. Once we put on a different hat which focused entirely on the bottom line (closing deals), we were able to get a ton of work done in a reasonable amount of time, that customers and internal folks really loved. They truly appreciated us tackling this challenge and for us we ended up with a reusable framework that helps enforce the design goals we’d set forth.

Andrea Hill said:

Sell the value to the organization as a whole. Provide concrete examples of ROI. Make it known that it is an indispensable part of the process.