What Should Be Defined Before UI/UX Design Begins?
— QUESTIONS & ANSWERS
What Should Be
Defined
Before
UI/UX Design Begins?
Project Management + UI/UX Delivery
Before UI/UX design begins, the team should understand the business objective, primary users, important user roles, core workflows, scope priorities, and major technical or operational constraints. You do not need a perfect specification before designers get involved. In many projects, the design process helps expose missing requirements and unanswered questions that were difficult to see in a document or ticket backlog.
The goal is not to eliminate uncertainty. It is to create enough shared understanding that the UI/UX team can move forward deliberately and the project manager can see which decisions still need owners.
Define the Business and User Outcome
The design team should understand what the product is trying to accomplish, who the primary users are, and what those users need to do successfully. A list of screens or features is not a substitute for that context.
The same functionality can require a very different interface depending on whether the user is an administrator, customer, specialist, executive, employee, or external partner. The purpose of the workflow shapes the design.
Clarify Roles, Permissions, and Primary Workflows
Complex software often has multiple user types with different responsibilities, permissions, data access, and goals. Those differences should be surfaced before the interface is treated as one universal experience.
The project team should also identify the workflows that matter most. Which tasks happen constantly? Which actions have the highest consequence? Which journeys are essential to the release? Those answers help UI/UX focus on the product areas that deserve the most attention first.
Separate Confirmed Scope From Open Questions
Not every requirement has to be final, but the team should know what is committed, what is still being evaluated, and what belongs outside the current scope. That distinction prevents every new idea from quietly becoming a current design requirement.
Open questions should be visible. If a workflow depends on a policy decision, business rule, integration, or stakeholder approval that has not happened yet, the project manager should know that before the design is treated as blocked or complete.
Surface Technical and Operational Constraints
Existing APIs, data structures, security requirements, third-party systems, platform rules, performance constraints, compliance requirements, and engineering limitations can all affect the user experience.
Designers do not need to become engineers, but they need enough information to avoid solving the wrong problem. Early technical consultation helps the UI/UX team distinguish flexible product decisions from hard constraints that must be respected.
ACI Worldwide
Universal Online Banker
ACI Worldwide Universal Online Banker had to support complex banking actions, multiple user roles, approvals, administrative capabilities, and high-trust financial workflows. Those kinds of products cannot be designed from a flat screen inventory.
The design process has to understand who is acting, what they are allowed to do, what information they need, and what happens before and after each action. Defining those relationships early gives both design and engineering a clearer target.
View the ACI Universal Banker Project →Common Questions
Frequently Asked Questions
Do we need a complete product requirements document before UI/UX starts?
No. A complete product requirements document can be useful, but it is not a prerequisite for starting UI/UX. A strong product brief, known business rules, primary user roles, key workflows, release priorities, and major constraints may be enough to begin. As designers translate that information into flows and interfaces, they often expose missing requirements, unclear states, or decisions that still need an owner. The important thing is that the team knows what is confirmed, what is still open, and who can resolve the remaining questions.
Can UI/UX designers help clarify requirements?
Yes. Turning requirements into user flows, wireframes, prototypes, and interface states forces the team to answer practical questions that higher-level documentation may not reveal. Designers need to understand sequence, permissions, data, errors, empty states, decision points, and what happens before and after an action. That process frequently exposes ambiguity, conflicting assumptions, or missing requirements before those issues reach development. UI/UX can therefore be part of requirement clarification, not simply the visual execution of requirements that were already finished.
What if requirements change during design?
Requirements often evolve during design because the team is seeing the product behave as a system rather than as a list of features. The key is to separate normal refinement from uncontrolled scope growth. Changes should be documented, their impact on approved flows and screens should be understood, and the project manager should keep everyone aligned on whether the change belongs in the current release or a later phase. That keeps iteration productive without allowing every new idea to quietly become a current design requirement.
Continue Exploring
Explore More
SaaS UI/UX Design for Enterprise Software
See how The Skins Factory approaches complex SaaS and enterprise products where user roles, business rules, workflow priorities, and technical constraints all shape the experience.
→ Further ReadingThe Definitive UI/UX Design Guide
Explore the broader UI/UX design process, from product definition and user flows through wireframes, interface design, prototyping, and developer handoff.
→Need Help Turning Requirements Into a Clear Product Experience?
The Skins Factory helps product and project teams translate complex requirements into user flows, interface decisions, prototypes, and development-ready UI/UX. We can work with your existing stakeholders and engineering team to clarify the experience before implementation gets expensive.
Have an idea? Let's chat.
Thank you for reaching out.
We will be in touch within one business day.