User Personas vs User Requirements: Understanding End-Use

Great software is never about you. Unfortunately, many digital products fail because they fail to capture audience interest, largely due to a lack of value to their target customers. For example, according to CB Insights’ 2021 report into Startup failure rates, 35% of startups fail due to a lack of market need.

That statistic seems incredible when considering classic business models, where a company is established due to a need or opportunity. With the technical innovations available in our modern age, startups often ignore that need and launch products based solely on what they ‘think’ is needed - which, as we can see, leads to disaster. Whether you’re a Startup or an established business, understanding your users should always be at the top of your priority list.

Assumption makes an…

Ever heard that American expression we’ve just referenced? It’s a good one, honestly, because, in our experience, assumption really does make a project much worse. It’s assumptions that can lead to a failed launch, but also assumptions that fuel many feature requests and project bloat that can cost our clients time and money.

When assumptions can be so costly and detrimental to success, why do so many businesses assume they understand their customers without adequate user personas?

User personas are a fictionalised version of your customer. They map out each ‘type’ of the customer by assigning certain qualities such as age demographic, interest, technical competency etc. They are used across most realms of business - including marketing and sales.

In UX design and software development, user personas are also relevant. Unfortunately, the level of persona creation most businesses are familiar with fall far short of what software projects require.

In our workshop sessions, we work with clients to understand user personas more emphatically, looking to empathise with their needs, wants, and frustrations. But, we’ll also create a map of user requirements. This is the technical stage that many businesses overlook and is what differentiates traditional marketing user personas from those built for digital products and UX.

User personas vs user requirements

User personas, as we have mentioned, are fictionalised versions of a customer type. Therefore, they vary heavily between minimal personas that simply map out client age groups, income, and budget to far more extensive maps of a customer type’s lifestyle, motivations, habits, etc.

In the past, user personas were largely based on the scary word we used earlier, ‘assumption’. Marketing agencies and advertising executives would categorise personas and use them to justify spending on print and TV ads in magazines that promised they were read by ‘ABC1’ audiences etc.

The digital age has transformed how you can create user personas. Not only can you get real-world analytics to see who your customers really are versus who you think they are, but you can also use data to find out everything from their exact age to browsing habits, average basket spends, etc.

Your user personas aren’t enough

However, all of that said, most businesses don’t put enough effort into their user persona creation. They typically build them from a broad summary of their own customer experiences - failing to put in genuine research.

The alternative is less common but can also miss the mark: a business that already has well-researched user personas based on analytics but has failed to get genuine user feedback or testing.

So whether you just think you know your users or use data to show you how they behave on your site or elsewhere online, you are often failing to discover the most important aspect of your product’s success: user needs/requirements.

At KOMODO, we support User Research as a way to build genuine personas - but also to extract something that exists just below the ‘top-level’ of persona work: that of user requirements. User Research, which is a topic for another article, allows us to interact with real customers directly, gather genuine feedback and assess real-world needs.

What are user requirements?

Essentially, user requirements are a list of things that your product or service must accomplish in order to meet user needs. Some agencies may just term them ‘requirements’ and treat them as the requirements of YOUR software - but we’re here to say that’s the wrong approach.

You must define USER requirements, not requirements. Listing what your software project needs to do is not the same as understanding what users need and then designing solutions as a result.

In our workshop process, the main drive behind user personas and user stories is to derive user requirements. Our user research process takes this even further by investigating user requirements by directly interacting with your target user base and gathering genuine, real-world needs.

User requirements vs other requirements

While user requirements help shape aspects of a product, such as its features and functionality, the other project requirements are still important and worth discussing.

Requirements as a top-level idea will come from many sources: as an agency, we’ll ask what your project’s goals are, which will help us shape the requirements of the project (for example, if you want to employ app development in addition to your web application, we can define one requirement as cross-platform development.)

Business requirements

Your project must align with your business goals. For example, if you want to grow your sales conversions by 30%, how can a software solution help you to achieve that? This is a business requirement and one that must be factored into a software development project. In our work with clients, we perform stakeholder interviews and workshops to outline your business requirements and how our development project will affect them.

User requirements

As we’ve discussed, these should be genuine needs discovered through user interviews and other User Research techniques. These requirements define what a user’s goal is and what their inputs and outputs may look like.

Technical requirements

Your user and business requirements feed into technical requirements, which you can divide into functional and non-functional requirements.

• Functional requirements define how you will develop the product and what the system has to accomplish. This includes everything from reporting requirements through to the platform, coding language, transaction capabilities, audit tracking etc.

• Non-functional requirements are elements that a product must have to support the business and user requirements but aren’t defined by tangible technical functions or features. These include things like data integrity, usability, scalability, security etc.

Stakeholders often define non-functional requirements in an attempt to extract what value they want from the product. Unfortunately, this internal bias often ignores user needs and can lead to costly mistakes and feature bloat.

User requirements are king

Ultimately, user requirements are what we believe are the most important thing to gather and understand. By knowing what your customers want from your product, you can shape the functional and non-functional requirements around the people who are actually using the product and generate the conversions you need.

However, gathering these requirements means performing the right kind of user research. For example, if you ask them what they want from a piece of software, a user’s answer can vary wildly and be based on emotion, opinion, expectation etc. If you instead ask them what challenges they face when interacting with online checkout, you’ll clearly understand the problem and, subsequently, the need for something better.

User requirements are vital to a project’s success and are a natural continuation of user persona work. So why go to the effort of mapping out your customers without ever actually gathering their genuine requirements and then building your product to solve user problems instead of satisfying stakeholder expectations?