November 13th, 2024, posted in for_founders
by Adelina
This article is part of the Understanding series of our UFOs UI/UX Framework. The framework is a tool we created based on our 10+ years of experience in building complex software and thousands of hours of design meetings and feedback. Developers, designers and entrepreneurs can use this framework to gain a better grasp of the UI/UX process and build awesome apps as a result. To learn more about the UOFs UI/UX Framework and each framework component, please go here.
This article is part of the “U” from UFOs, the framework component that strives to help you understand the business needs of your clients and an app`s main stakeholders.
Imagine your team just landed a software development project for an app you know nothing about. At the moment you are reading this, there are no written specifications, no user flow diagrams and no project board with pending tasks. Soon you`ll need to start working on the first draft screens. Where do you actually start?
UI/UX design is all about problem solving. To succeed, an app needs to serve a business goal for a stakeholder, solve a problem for a user and bring something to the industry. Understanding these three aspects is the first step in understanding the app you are designing and ultimately building.
Before we can even talk about specifications, technical requirements, user journeys or personas, there is important groundwork to be done. And this consists of preliminary interviews with people directly involved in building the app and people who will be using the app. Interviews shouldn`t just happen as part of prototype testing or after-launch monitoring. They should be a primary tool in product discovery and the initial stages of UI/UX design.
With this in mind, preliminary interviews are aimed at answering two questions: “Who?” and “What?”. These two questions form the basis of all future iterations and can be revisited throughout the design and development lifecycle. They are also a fast and easy way of getting to know the industry, in addition to any additional research you might conduct (e.g. reading white papers and reports on the industry, watching demos of similar apps).
WHO?
The people you interview in these initial stages will help you get an idea of the full spectrum of your stakeholders. This can also serve as a basis for future user persona profiling.
WHO are the makers? - in addition to the actual team developing the app (UI/UX designers, developers, testers), you can also have client-side makers. These are primary stakeholders, like co-founders or investors, who are directly involved in the design and development process and have the most decision-power. They are the ones who often invested money in building the app or who are the most interested in the business success of the app.
Mandatory makers to interview:
product owners - for start-ups they might be the co-founders themselves, while for bigger companies you might have a dedicated person acting as a product owner. They're in charge of the vision and direction of the app and understand the requirements in detail.
Client-side product owners (as opposed to internal product owners) have the advantage of understanding the product AND having an already established relationship with the wider stakeholders. This allows you to also interview the CEO, CTO, board members or marketing team members who can give you a multifaceted perspective on what they want to build.
WHO are the users? - unlike makers, users have less decision-power regarding app design or features, but they're the ones most impacted by these. This sometimes leads to a contradiction, where people who won't actually be using the app build it for people who will. Needless to say, the makers` vision for the app doesn't always go with what the users actually need or want.
That's why it's important to not restrict requirements to a list of features handed down by the product owner. Preliminary interviews with users are also a big part of this understanding phase. This works best for internal apps, where the user base more or less coincides with the company's employees (you can be put in contact with them through the product owner or other stakeholders). However, even when the end user is exclusively “out there”, you can still work with the stakeholders to identify potential candidates.
At a minimum, users can be divided into admins and regular users. Further segmentations may include:
Company employees:
- managers: from team leads to division managers, they can offer you the bigger picture in terms of workflows and processes.
- power users: these are people with a lot of work and industry experience. They can help you identify edge cases and features they would very much like to use in their daily job, but failed to find in similar apps.
- regular users: they are the people whose job the app needs to make easier. At a minimum, the app should allow regular users to perform their daily tasks.
Company clients:
- end users: these are the users whose activity is supported through the app and who are served by the employees using the app.
- other businesses: final recipients of B2B software
- partners - this includes suppliers or any third-party vendors.
WHAT?
What people want from the app very much depends on who they are. If the app was a pie, makers and users would all want a piece of it, but of various flavours. Below are some examples:
- product owners - their goal is to create products that stand out. They`re the ones most interested in the app`s look & feel.
- managers - their goal is mostly instrumental: optimize processes, reduce cost etc. They're less interested in what makes the app stand out. They use dashboards a lot and need ways to analyze data and assess performance.
- power users - they want to be able to do things previous software they used didn`t allow them to. This might imply highly customized design and features.
- regular users - their goal is to do less manual work. This might mean automating tasks or integrating in the app data previously tracked offline manually.
- clients - need to have easy access to important information (business accounts, stats & reports) and ways to communicate easily with a support team.
To complicate things even further, one person can have multiple roles and therefore conflicting wants or needs depending on the role they put forward. In sociology this is known as “role conflict”, an example being when a parent coaches a team that includes that parent's son. The role of the parent can conflict with the role of the coach which requires a higher degree of objectivity.
Similarly, exploratory roles (like that of a product owner) might conflict with more instrumental roles (like that of a board member). A person might want to build the most advanced fleet management software on the market. All the while admitting that, as a board member, if they were responsible for the financial decision of buying such software, they would choose the cheapest or the medium-priced option.
Preparing for the interview
Whether in person or remote, preparing ahead for these preliminary interviews can save you a lot of time down the road. Below are some tips & tricks for a smoother experience on both ends.
Make sure you have a way to record the meeting - taking notes might sometimes distract you from the actual interview. Try recording the meeting instead, so you can review it later if needed.
Identify patterns early on - if you do decide to take notes, write them down as statements directly in an Excel spreadsheet (you can also include supporting quotes). You can then identify patterns by coloring in the participants who adhere to that statement. Works great especially for redesign projects, where you can easily identify recurring pain points users have with the existing app.
Source: https://www.userinterviews.com/blog/tools-for-remote-user-interviews
Ask open-ended questions - might sound trivial, but it encourages users to tell a story rather than confirm or rule out your own assumptions.
Keep the “what ifs” for the makers, not the users - ask users only factual questions. Interviews should stick to concrete examination of what users do and how they feel. They should not try to get the user to create their ideal product.
Start building a list of contacts - this is particularly useful when working on an app for a bigger company. During interviews people tend to reference other colleagues who they feel might have a better grasp on certain aspects. Write those contacts down and start building a list of team members, departments and responsibilities.
Group questions into topic categories and subcategories - you probably won't be able to think of all the questions straight away, but having some broad categories to map them to really helps. Below is a concrete example of organizing your questions.
35 example questions to kick start a productive discussion about complex software
You have been contacted by a relatively large company to design and build an app which covers the seed-to-sale life cycle of bonsai trees. This includes tending to and growing the trees, but it should also provide supporting features for the sales team, the inventory management team and the company's clients (flower shops distributing the bonsai trees, other growers) and partners (e.g. fertilizer and pesticide suppliers).
Questions for the makers:
App structure and architecture
1.) Will this be a single app or a suite of apps, given the number of features?
2.) If this is a suite of apps, how will the onboarding and sign in happen? (e.g. single sign-on through a portal allowing users to sign in with the same email address across apps)
3.) Will this app/suite be used only internally or will it be sold as a seed-to-sale software solution for other growers?
4.) If this is a SaaS, how many users do you expect to have?
5.) What is the overall entity hierarchy and what are the restrictions that come with this? For example, the company is the highest-level entity. Each company needs a bonsai grower license in order to sign up for the app. Can a company have more than one license and if so, how do they switch between licenses? How many levels down does the hierarchy go? For each company you might have several brands (luxury bonsai trees, pocket-sized bonsai trees etc.). Each brand may have their own teams with various roles within the team.
Industry and competitors
6.) Who are your biggest competitors and what is your main differentiator? A huge value proposition might be the fact that you offer an integrated suite. Alternatively, there might be multiple CRM solutions out there, but none tailored for the bonsai industry specifically.
7.) What are some industry trends which you have identified and could directly impact the design and development of the app? For example, more and more clients move towards a vendor managed inventory model. Instead of simply selling bonsai trees to flower shops, you could monitor their inventory thresholds to make sure they never run out of bonsai trees. Or you could even order bonsai trees for them and offer inventory management as a service through your app.
8.) What are the most common billing models in the industry and how do you plan to approach billing (one-time payment versus subscription, payment plan per number of API calls, per number of team members etc.)
9.) What are the main business goals you set for your app and what is the estimated time span to reach these thresholds?
Clients
10.) What type of clients do you have? For a bonsai grower, this might range from flower shops where they sell their ready-made products to other growers to whom they sell seeds and other growing materials.
11.) What is the average size of your clients` business?
12.) What type of services do you offer to your clients? For example, this might range from retail selling through an e-commerce to vendor managed inventory services.
App look & feel
13.) Could you please give us some examples of app designs you like?
14.) Do you plan on using a UI kit or an entirely custom design?
15.) Are there any industry rules regarding look & feel, color scheme etc.? For example, in the bonsai growing industry one would expect to see earth tones and a lot of green.
Questions for the users:
Getting to know the user
16.) [For employees] What is your role and how long have you been with the company?
17.) [For managers] How many people do you have on your team?
18.) What apps do you use in your daily work? Which ones do you use the most?
19.) If you would describe your job with one adjective, what would it be?
Daily workflow
20.) Could you please walk me through what a typical work day looks like for you?
21.) What task takes up the most time out of your day? For example, the Growing team might spend a lot of time manually tracking bonsai trees based on their plant tag. A significant time-saver for them might be the ability to scan the tree tags and automatically get the code.
22.) What is the easiest task to accomplish? What is the hardest task to accomplish?
23.) Do you use any hardware in your daily work? (e.g. thermal printers, scanners etc.)
24.) How many other departments do you interact with on a daily basis?
25.) How is your work evaluated and what are the metrics, if any? (e.g. planted trees per hour, number of correct versus incorrect orders etc.)
Pain points
26.) What are the blockers you most often encounter in your daily work? For example, several members of the Fulfilment team might pull from the same bonsai inventory lot to fulfil orders. Slow loading time might lead to inaccurate inventory. When the system refreshes, the user might realize that, in fact, there is nothing left to pull from.
27.) What options do you currently have to address the blockers?
28.) What are your main issues with the software you are currently using for your work?
29.) Who are the people/departments most affected by this pain point?
30.) What has stood in the way of addressing this pain point so far?
Client-related questions
31.) Are you in direct contact with your clients? If yes, how do you keep in contact with them?
32.) What is good customer service as related to your job?
33.) What are the most frequent complaints you receive from clients?
34.) I want to do a certain action as a client (e.g. place an order). Can you walk me through the steps of accomplishing this?
35.) An issue has been raised by a client (e.g. incomplete order). Could you please walk me through the steps of raising an issue and resolving it within your department.
You can hold preliminary interviews with makers and users before you even have a design to inform any future personas, journey maps or requirements for the app you are building. These preliminary interviews will help you understand the app a lot better and the business needs it answers. It's like an onboarding process before you even start mapping an onboarding flow.
If you want to build an app and don't know where to start, drop us a line. As you can see, we love to talk software.
