• Where do non-UX-team members learn about UX?

    As a User Experience practitioner, you learn about UX in school (even if it wasn’t called UX), you improve your skills in practice by being part of project teams, and you update your knowledge at a UX conference or training. But what about the people around you? Where do Project Managers, Product Managers, Developers, Sales, QA, Strategists, and Managers learn about User Experience?

    If only because of our position in the business process and our need for input by other roles, we need to learn the basic elements of other fields, such as business modeling, project management, coding, QA, and selling our projects. This is why, at several recent conferences, I’ve been talking about these so-called “More Elements of UX”.


    Likewise, I think the people around us in our organizations should learn the basics of our field. They need to know for example why we insist on performing user research when we don’t know what motivates potential users, why we create conceptual models of a system before diving into the details of its interactions, why sketches work for the initial phases of design, when visual designers needs to be brought into play, and how to best evaluate a design at different stages of design and implementation.

    Why do they need to know? Well, how else can they help us plan the research, scope iterations, put together the right team, and track our progress? People in roles surrounding UX need to know about UX because their work influences how well User Experience practitioners can do their work.

    Here are some examples of the influences that the people around us have on our work, and how we can contribute to the decisions that they need to make:

    • A Project Manager’s estimate codifies which aspects of your work get measured (“did you produce each of the estimated 15 wireframes?”). UX team members must indicate how they want their progress to be measured and also which aspects of a design influence its complexity.
    • A Product Manager’s vision statement determines what kinds of experiences you are asked to design (“Product X will feature branded experiences” versus “Product X uses well-known patterns”). UX team members can supply user research results and trend information to help shape the vision.
    • A Developer can make or break a crucial interaction by influencing the responsiveness (““), but also determine the degree of openness of the entire system (“beautiful seams”). UX designers must indicate the priority of design principles, and have a feeling for the technical “umfeld” of the application.
    • Sales has the power to create expectations about the solution (“We’ll make you a state-of-the-art, Web 2.0 Banking Portal”), and about where you will spend your budget (“using stunning, award-winning photography”). UX practitioners should help in determining the most suitable offering and forumulate the associated end-user value, and should assist in writing the story that goes into the Sales presentation.
    • Managers might determine how much progress you or your team need to make (“5% increase in quarter-on-quarter conversion”), which tools you have available (“we have licences for iRise and Visio”), and what process you should follow (“RUP” versus “Scrum”). The UX team must do regular self-inspections to determine its capabilities and needs, and negotiate the right resources.

    Hopefully, you and your UX team will have some influence on most or even all of these “More Elements of UX” that also determine the User Experience.

    But, to come back to the question in the title of this post, given that I want to share these thoughts with your Project Manager, your Product Manager, your Sales colleague, your Developer and QA teams, as well as your team’s Manager, where should I go to meet them? What conferences do they attend? Which magazines do they read? What type of training do they sign up for? Have you been able to bring these colleagues to UX events? How did you convince them to come along? Have they invited you to their events?

    Some examples of organizations and their events that I could go to, are:

    But I could use some more pointers. I would love to hear how you think that, together, we can educate the people around the UX team about the influence we have on each other’s work. Suggestions in the comments section are appreciated!

    There are 4 thoughts on this idea

    1. Alaina

      We actually do in company training on UX & design concepts. Even before UX came into existence here 18 months ago it was an accepted practice to put on ‘lunch & learns’ that are open to any interested parties in the company. Initially we did presentations there including a ‘What is User Experience?’ talk before deciding to do a regular monthly design workshop. For a couple of hours in the afternoon on the 4th Friday of the month our team puts on a workshop about a design topic or concept and invites the entire company (60ish employees). Actual attendance varies in the 17-30% range but includes managers and VPs. This past week we focused on scope creep though previous workshops have also included topics like mental models and locus of attention. It not only serves as an educational tool for the rest of the company, but also gives us a common language and an opportunity for our team to cement our knowledge by sharing it with others.

    2. Peter Boersma

      @Alaina Of course in-house education is an option too! It is probably the best way to approach the mutual learning that is required, simple because you’r learning it from each other instead of via an external training. Thanks for the reminder!

      @Adrian Your second point (“The influences run both ways”) is exactly why I want to look for experts in other domains and explain them our dependencies.
      The first point follows from the second; when people know more about the overlap, by definition they know more about the other fields.
      Ad finally, knowing more about the overlap and mutual influence, means the chances of sharing the responsibility for the work (as opposed to wanting to own it) increase. But that may be me already applying servant leadership 😉

    3. Adrian Howard

      I could ramble on for hours on various tips and tricks about getting the whole team to understand UX—but I think they boil down to two points that are more about attitude than any particular practice:

      1) You need to be a missionary, not a dictator. You need to convert people to want to do UX work. The whole team needs to be thinking and doing UX work. Not just because you tell them to – but because they _want_ to. Spending more time facilitating UX work by the whole team reduces ongoing problems, and frees up the experts to focus on the harder UX issues.

      2) The influences run both ways. UX affects Dev. Dev affects UX. PM affects UX. UX affects PM. And so on. We need to learn more about other folks domains just as much as they need to learn about UX. It should be easier for UX folk too—we’re supposed to be really good at putting ourselves in other people’s shoes. The bonus is that the more you understand the easier it is to find connections between UX and other domains, and the easier it is to convert folk to think more about UX.

      The biggest problem with adopting these is ownership. When folk encounter UX work in another domain the first thought of a practitioner is often “I should be doing that”. Unfortunately the project manager, dev, or whoever is thinking exactly the same thing. Both sides are equally “right”, and getting past that can be hard. I find looking at management approaches like servant leadership and trying to turn the organisation away from “who does what” style of work towards a “what needs to be done” approach.

    4. Mariya philip

      User Experience studies has its own importance, sometimes not fully understood by some project managers. They are some times reluctant to study new techniques. Any way we have included UX in company skill enhancement training for project managers

    Comments are closed.

  • Close
    Team Profile