Check out 5 tips to help BAs improve outcomes through user experience techniques.
Software is changing. From self-driving vehicles to smart watches, the devices with which we interact, and by extension how we interact with them, are a far cry from the technology of 20, or even 10, years ago. Now we expect technology to be personal, to be intuitive, to speak directly to us (literally and figuratively), to track our heartbeats and our sleeping patterns, and find us music and holidays and life-partners. In other words, the user is central to new technology.
Which means that those involved in creating that technology have to change too. As software prototyping and development increasingly incorporates user as well as business needs into its lifecycle, Business Analysts find themselves working more and more with their counterparts in UX, or user experience.
So what exactly is UX, how does it relate to Business Analysis and, most importantly, what are key values/techniques can BAs learn from UXers to ensure better software development projects?
What is UX – in brief
UX, or user experience, is an interdisciplinary practice that aims to reframe design conundrums by looking at user (and business) objectives, rather than technology. UX professionals can have a background in anything from design to psychology, and use a wide variety of practices in their daily work – user testing and research, contextual enquiry, storyboarding, strategy and product design. In essence, a UX professional aims to understand human behavior in a given context and apply it to a product strategy and requirements.
Why it’s important to understand UX as a BA
Although they ostensibly focus on the business end, all Business Analysts know that product success depends on users effectively engaging with the software you produce. Failure to engage users results in low revenues in the long-term; in the case of Enterprise software, bad usability can result in low productivity and employee disengagement. So for many firms, UX is becoming increasingly important. This provides opportunities for the UX-savvy BA to add value to their role within a project or enterprise. Implementing some ‘UX skills’ while defining and managing requirements will help BAs produce successful software solutions, avoid expensive reworks and deliver positive outcomes for both businesses and users.
The cornerstone is that BAs need to consider users, and UXers business needs. As Ian Crew of IS&T Data Services points out, “to be successful at either BA or UX, you have to know a lot about the other.”
So there’s plenty of overlap between UXers and BAs already; adding UX skills to your BA toolkit will ensure that you’re better equipped to understand end-users, communicate with stakeholders and pull off successful software projects. Here are 5 useful UX techniques, from user personas to interactive prototyping that will come in handy for any BA.
Contact us to learn more about Justinmind Enterprise
Understand the users
Obviously, you might be thinking. But you’ve probably experienced a software project in which there was a gulf between what stakeholders thought people needed and what users actually needed. At the requirements gathering stage, a BA who researches and observes users in context can present stakeholders with evidence-based information; most BAs will already be familiar with doing this through Observation. But try integrating UX-style user research techniques into your BA Observation stage by using ‘contextual enquiry’ methods: observe your target users driving an app or software, and examine their immediate environment for clues as to things they’re lacking. For example, observing an employee writing tasks on post-it notes before updating them in their project management software will give you clues as to areas of need that you probably couldn’t have got from talking to sales, support or marketing. For UX professionals, contextual enquiry is key.
Once you’ve observed users ‘in the wild’, formulate rough user personas and outline how your product will benefit each persona. Give these ‘user requirements’ space alongside in your business and system requirements.
In general, don’t be afraid to actually interact with users. Ask them how they operate, get interested in their working practices and they’ll reward you with vital information in terms of requirements definition. Check out the ideas in tip 3 below.
Understand the competitors’ products
Sometimes BAs complain that UXers don’t understand the business context in which they’re working, or the project’s strategic business direction. But it’s equally true that sometimes BAs neglect the importance of understanding the competitive landscape on a functional level. In place of examining the competitive market on a business level, take a tip from user experience professionals and carry out competitive analyses of the competitions’ interface design, navigation and information architecture. This will enable you to figure out where the competition stands in terms of usability, and identity any opportunity gaps for improvement which can then be built into your requirements. Find out more on carrying out a UX focused competitive analysis here.
Borrow UX techniques
We’ve already touched on the UX technique of contextual enquiry, which provides you with invaluable information about how your product will eventually be used day to day by users. But there are plenty of other UX techniques that will boost your BA abilities.
User personas can be a powerful tool during requirements gathering and definition stages. Whereas profiles are on the general side and help you understand group behavior, personas get down to the nitty gritty of particular user types, giving you a much more realistic idea of the situation on the ground.
Rooted in user research, personas attempt to present a type’s personality, behavior, personal information (age, income, civil status etc.) and, importantly, tendencies – oft-used brands, use of technology and similar information. The aim of drawing up these user personas is twofold: to evoke real understanding an empathy for real users, rather than a distant conception of ‘the average user’; and to assist in organizing requirements by ranking features according to importance in each persona. This feature prioritization matrix means that your prioritization process is objective and evidence-based.
Read more about user-centred research and prototyping here.
Another useful UX technique for BAs is card-sorting, an exercise that is meant to reveal how users think. It’s simple to carry out and quick – with a small group of potential users, create a separate card for each feature of your product, then ask people to group them and name each group. The aim here is to understand users’ expectations and thought processes behind the information architecture of your product. These can then be written into requirements. The outcome (hopefully!) will be an intuitive and user-friendly IA that won’t need to be reworked. Smashing Magazine has some great tips on card-sorting.
Prototype like a UX professional
Interactive prototypes are useful for both UXers and BAs alike. Some BAs will be familiar with using a prototyping tool (read more about the basics here) to elicit requirements, but it’s also a good way to propose blueprint solutions to your stakeholders. Introduce prototyping as early as you can into the process and you will be able to test your ideas from the start – identify key functionality of your software and ask users to carry them out on your interactive prototype. The ability to modify functional requirements at the early stages of the Software Development Life Cycle is central to verifying that even your early-stage solutions are on track to hit requirements, thus keeping costs down. Quality Assurance Testers will thank you for it too!
As a side note, be aware that not all prototyping tools are fitted to BA needs. Using a tool that integrates requirements and has sharing capabilities makes more sense than one solely orientated towards visual interface design.
Work together on requirements
While it’s great to introduce interactive prototypes into your BA process, if you’re working side by side with an actual UXer then this can cause friction as you may look like you’re treading on toes. Conflict can be healthy, but only if it’s managed and learned from. Letting the UXer into the requirements gathering and definition stage through co-organized meetings, and clearly defining roles (and responsibilities) from the start will smooth the process. If you decide to manage those mutually defined requirements in a prototyping tool, they will be completely collaborative and contextually linked to functions; this means that all involved have equal buy-in, and no one is left producing, or reading, text-heavy requirements docs. UXers, who generally have more experience with designing user interfaces, can be a valuable ally for BAs who are struggling to implement functional requirements at the design stage.
The overlap between BAs and UXers is large, and in the future it’s likely that the two disciplines will work closely together in the majority of projects. Getting a handle on the benefits and methodologies of UX is a valuable asset to business analysts right now, and that looks set to continue into the future too.