The idea of a UX unicorn has always been something of a puzzle to me. User Experience is already such a broad field, encompassing digital design, graphic design, interaction design, user research, usability testing, prototyping, and other specialties. Saying that there is something unique or special about a person who is competent in some part of User Experience and also another discipline such as coding feels like a failure to acknowledge the unique breadth of User Experience. But, for the sake of this column, let’s roll with this definition:
A UX unicorn is someone who can deliver broadly on the UX skillset, plus something else that most would consider rare—though perhaps not mythical, as the term unicorn might imply!
Champion Advertisement
Continue Reading…
Considering the idea of a UX unicorn objectively, being skilled in many different facets of User Experience is inherently a positive thing. It makes a UX professional much more employable. Doing work in specialties at which you’re not yet an expert helps you to work more effectively with those who are specialists. Your understanding of what they do and empathy with them is much greater. However, doing this is not without pitfalls. As the old saying goes, “A little knowledge can be a dangerous thing.” If a specialist is working with someone who has a little knowledge, but doesn’t understand the limits of their knowledge, this can quickly lead to a breakdown in their working relationship. If you’re a designer who is expanding your knowledge into another specialty, the best advice is to be humble. Spend more time asking questions and digesting the answers than giving opinions.
The broad scope of User Experience provides a wealth of opportunity and a range of development areas for a UX designer. However, thinking about skills that would make a UX designer or researcher really stand out, I’m going to look at a role that, in my view, doesn’t receive nearly enough love on project teams—that of the humble business analyst.
In my experience, having a great business analyst on a team means that I can have a lot more confidence that the project will be a success. The business analyst is the person who asks the awkward questions, maps out the what-ifs, pins down the requirements, takes the time to understand what the business wants, and considers how that maps onto the project deliverables. In some respects, the skillset of the business analyst overlaps with that of the UX designer, but there are also some key, closely related differences:
A business analyst typically focuses at least as much on understanding the requirements of stakeholders inside the organization as of those outside.
The scope of the business analyst’s work is typically broader than that of the UX designer.
Business analysts care about the needs of the business and identifying solutions to those issues more than about the interplay between the user and the project output.
Let’s look at some business-analysis processes and outputs and explore what they would mean to UX designers if their role were expanded to include them.
Requirements Definition
Defining and documenting requirements is about much more than creating a document that comprises a prioritized list of the things a product team needs to do. (Although that alone is extremely useful to a UX designer.) There are two key aspects of a business analyst’s role that are important in requirements definition: stakeholder analysis and change management.
Stakeholder Analysis
In practical terms, creating a great design isn’t just about understanding what the user wants. It’s also about understanding and delivering on what the business needs. If the business doesn’t see some benefit to creating a new product or feature, nothing will get done. Understanding who the key stakeholders are within the business and their interests in the project means you know
who you need to listen to and keep informed for the project to be successful—Your time and energy are limited, so use them effectively.
what the stakeholders’ concerns and interests are—This lets you pitch your message internally in the right way.
I cannot stress enough how important this is. Delivering what users need requires that you first gain the support of the business to do what you need to do. In most cases, this means designing in a way that meets the needs of both the business and the user. That may mean fulfilling the brand promise or the core values of the enterprise or simply building on the knowledge and expertise of others in the organization. Understanding exactly what these are and ensuring your design relates to them makes it easier to pitch the design to the business and get buy-in.
Change Management
Every decision that an organization makes has been taken for a reason. The reason may have been good or bad, and the decision may have had either the desired outcome or unexpected consequences. The decision may have been right at the time, but absolutely not fit for the organization’s current goals. But, whatever the reasoning behind the decision, understanding the current state of the business environment in which you are working can mean the difference between coming across to colleagues as that guy who thinks he knows it all and that guy who has some interesting ideas.
Understanding why an organization made certain decisions is key to helping the organization create change. People can be very defensive about the decisions they have made if they feel challenged. The most successful change agents in organizations are those who have sufficient empathy with others to be able to understand their perspective and work collaboratively with them to achieve a better solution. To bring this back to the user, understanding why an existing system operates as it does can, in turn, help you to design the system in a way that helps users transition to a new way of working.
Use-Case Modeling
In my view, use-case models are among the most useful outputs of the business-analysis process. While UX designers model users’ interactions with a system through a combination of personas and scenarios, use-case models typically have a more formal representational style. Yes, user stories have largely replaced use cases within organizations that employ some sort of the agile approach. However, the discipline of use-case modeling forces systems thinking. Plus, the process of reviewing a use case with stakeholders almost always prompts active discussions about the requirements.
For me, the biggest benefit of use-case models becomes apparent in meetings with developers and stakeholders. Use-case models that are informed and supported by user research give you an effective way of responding to the question: “Yes, but what if the user….” Being explicit about what you expect the user to do—or not do—means you’ll spend more time on genuinely productive discussions.
Conclusion
While it’s true that you can simply rely on your friendly business analyst to do these things for you, I encourage you to get more involved in business analysis yourself. First, developing these valuable skills may come in handy if, now or in the future, you find yourself working in an organization that has no business analysts or none is available to work on your project. Of course, if there are business analysts available, work with them. Try to understand the business analyst’s perspective and way of thinking about problems.
Second, it will be good for the soul. You’ll be doing work that has a lot of parallels with UX design activities, but with a different focus. This will give you the opportunity to expand your skillset into a different, but related domain. If someone shows their design to you, you will learn about their design. If you design something yourself, you will deeply understand the design. The distinction comes from your being involved in the design process. Similarly, if your task is to create a set of requirements, you will be the one who has to deal with the competing demands of stakeholders and understand and codify the requirements in a form that the project owner is happy to approve. Finally, taking on both of these roles provides an opportunity to bring User Experience and Business Analysis together and ensures each is better informed by the other as a consequence.
I transitioned from a BA to a UXer about 5 years ago, and all my learnings from being a business analyst have helped me a lot. I used to have a chip on my shoulder that I didn’t come from a psychology or design background, but it no longer matters as the discipline is starting to grow up.
I couldn’t agree more. Both disciplines—business analysis and interaction design—are two sides of the same coin. To create a more complete picture and have a holistic approach, you will have to do both and combine the results. Business analysis, interaction design, and agile development are three examples of approaches that risk having the same disease: a myopic view of the reality in which the system has to operate.
Peter has been actively involved in Web design and development since 1993, working in the defense and telecommunications industries; designing a number of interactive, Web-based systems; and advising on usability. He has also worked in education, in both industry and academia, designing and delivering both classroom-based and online training. Peter is a Director at Edgerton Riley, which provides UX consultancy and research to technology firms. Peter has a PhD in software component reuse and a Bachelors degree in human factors, both from Loughborough University, in Leicestershire, UK. He has presented at international conferences and written about reuse, eLearning, and organizational design. Read More
