Imagine someone opening a professional software application for the first time. They have a straightforward goal: complete their first meaningful task. Instead, they encounter dozens of menus, advanced settings and unfamiliar technical terms.
Now suppose we simplify the interface by hiding much of that functionality. What happens to the experienced users who rely on those capabilities every day?
This is a fundamental product design challenge: how do you make a sophisticated product easier to use without compromising the capabilities that make it valuable?
The answer is not necessarily to remove features or create a cleaner-looking interface. Sometimes the better decision is to change how and when users encounter complexity, rather than what the product can actually do.
What Is the Interview Question Really Testing?
The twelfth question in the series asks:
"How do you simplify the startup experience of a complex professional tool without undermining its power?"
This is a product sense and user experience design question.
The interviewer wants to understand whether you can distinguish genuine user problems from the apparent complexity of an interface.
A strong response should demonstrate that you can:
- Segment novice and experienced users according to their needs and behaviour.
- Identify where users struggle and investigate why.
- Shorten the journey to a first meaningful outcome without removing essential functionality.
- Balance simplicity, flexibility, implementation cost and expert-user requirements.
- Evaluate the proposed solution using evidence and measurable outcomes.
The interviewer is interested less in whether you can propose an attractive interface and more in whether you can explain the reasoning behind your choices.
First, Understand Where the Complexity Comes From
Not all complexity is bad.
A specialist application may require numerous settings and capabilities because the underlying work is genuinely complicated.
For instance, an analytics platform may need to support multiple data sources, custom calculations and granular user permissions. Removing these capabilities could make the interface look simpler while significantly reducing its usefulness.
We therefore need to distinguish between two forms of complexity.
Essential complexity arises from the nature of the task and legitimate user requirements. Removing it may prevent people from completing specialist work.
Unnecessary complexity results from poor interface design, ambiguous terminology, repetitive steps, weak information architecture or presenting advanced settings before they are relevant.
Our job is not to eliminate complexity indiscriminately. It is to reduce unnecessary complexity while making essential complexity understandable and manageable.
What Should We Clarify Before Proposing a Solution?
The first step is to establish the nature of the problem.
Are users struggling because the software is difficult to navigate, or because they lack the domain expertise required to perform their work? These problems require different responses.
What do people actually want to accomplish during their first session? Which steps are essential to that outcome? Is the product intended for an individual professional or for several organisational roles with different permissions?
We also need to identify where users get stuck. Is it during initial configuration, when encountering unfamiliar terminology, while connecting data sources, or because the next action is unclear?
Where reliable evidence is unavailable, we should make assumptions explicit and investigate real user behaviour rather than treating our guesses as facts.
Novice and Expert Users Are Not Necessarily Fixed Groups
A common mistake is to assume that all new users are beginners and all established users are experts.
An experienced data analyst might be opening our product for the first time. They understand the professional concepts but need to learn the application's structure.
Conversely, someone who has used the software for years might be attempting an advanced feature for the first time.
It is therefore more useful to understand users according to their goals, relevant skills and intended tasks, rather than account age alone.
For research purposes, we could initially consider three situations:
- Someone completing a common task for the first time who needs guidance.
- Someone comfortable with everyday workflows but unfamiliar with a particular advanced capability.
- An expert who wants direct access to specialist functionality without unnecessary steps.
These are working hypotheses for segmentation, not rigid categories into which every user must fit.
Three Approaches to Simplifying the Experience
Approach One: Remove or Extensively Hide Features
An obvious proposal is to introduce a simpler, restricted version of the application.
This may be appropriate when the product genuinely serves two distinct markets with substantially different needs.
However, if new users are expected to develop into proficient users of the same professional tool, an overly restricted version may hinder their progression.
Maintaining two substantially different experiences also increases development and support costs and may make switching between them difficult.
I would therefore avoid this approach unless there were evidence of enduring differences between user needs.
Approach Two: Explain the Entire Product During Onboarding
Another option is to introduce every major feature through a comprehensive product tour when someone first signs in.
This may sound helpful, but it overlooks an important point: users rarely open professional software simply to study its features. They generally have a job to complete.
Research published by Nielsen Norman Group indicates that intrusive, out-of-context onboarding tutorials are frequently skipped and do not necessarily improve task performance.
That does not mean guided instruction is always inappropriate. Step-by-step support can be valuable for unfamiliar interaction patterns or particularly sensitive workflows.
The decision should depend on when instruction is needed and how it helps the user accomplish a task.
Approach Three: Task-Based Onboarding and Progressive Disclosure
For many professional applications, my preferred starting hypothesis would combine two approaches:
Task-Based Onboarding and Progressive Disclosure.
The principle is straightforward: initially present the capabilities most relevant to the user's immediate task, while keeping specialist options clearly discoverable and accessible.
For example, when someone creates their first sales report, we need not expose every configuration option for filtering, calculations, data connections and permissions simultaneously.
We can first help them create a valid report, with specialist settings available when required.
Crucially, those capabilities have not disappeared. An experienced user can access them directly without working through introductory guidance.
This reflects the principle of progressive disclosure described by Jakob Nielsen: prioritise the essential options initially and make more specialised functionality available on demand.
There is an important limitation, however. If frequently needed features are hidden too deeply, or the route to them is unclear, the design merely moves complexity elsewhere.
Progressive disclosure succeeds only when the distinction between primary and secondary capabilities matches actual user tasks.
What Should an Effective Onboarding Experience Include?
1. Help Users Achieve Their First Meaningful Outcome
The purpose of onboarding should not be to complete a tutorial or click through several introductory screens.
We need to establish what a valuable first outcome looks like.
In project management software, creating an empty project may not constitute meaningful value. A user might only experience the benefit when they have entered real tasks, assigned responsibilities and gained visibility of progress.
We can describe this initial meaningful outcome as First Value.
2. Provide Guidance When It Is Needed
Rather than presenting every instruction at the beginning, we can introduce guidance when it becomes relevant.
For example, an explanation of an advanced filter might appear when someone opens that feature.
Guidance should be dismissible and available again later. Users should not be forced to remember instructions delivered long before they need them.
3. Preserve Fast Paths for Experienced Users
Experts should not have to repeat introductory steps whenever they use the application.
Direct access to functionality, keyboard shortcuts, command search and workspace customisation can help preserve their productivity.
This aligns with Nielsen's usability heuristic concerning flexibility and efficiency of use, which recognises that interfaces should accommodate both inexperienced and experienced users.
4. Keep Users in Control
Helpful onboarding should not trap people in an inflexible sequence.
Where appropriate, users should be able to skip guidance, revisit earlier steps, change initial settings and recover from mistakes.
However, essential security checks, permission requirements and other safeguards should not be removed merely to shorten the workflow.
Practical Example: Redesigning Onboarding for a Sales Analytics Platform
Hypothetical scenario
Imagine a software company providing a web-based analytics platform for business sales teams.
The product allows users to import sales data, build dashboards, create customised reports and manage team permissions.
Two user groups are particularly relevant.
The first consists of sales professionals who want to produce weekly sales reports quickly.
The second consists of experienced analysts who need multiple data connections, custom calculations and advanced configuration.
In our hypothetical current experience, both groups encounter the same extensive set of technical options immediately after signing in.
The question we need to investigate is: does presenting specialist configuration before the first meaningful task prevent new users from achieving value?
We would begin by examining the existing user journey, interviewing representatives of both groups and observing where people encounter difficulties.
If this research supported our hypothesis, we could test the following experience.
A focused entry point for new users: Someone selects the goal of creating their first sales report. The application requests only essential information, supports valid data import and guides them towards creating and saving a genuine report.
Preserved expert access: Experienced analysts can immediately access advanced configuration, custom calculations and specialist tools without entering the guided flow.
Contextual assistance: Brief, relevant explanations appear when users encounter more complex features, without unnecessarily interrupting their work.
Risk controls: Data validation and permission enforcement remain consistent across both paths. A simplified experience must not permit invalid data or unauthorised access.
The outcome is not assumed in advance.
We would need to establish whether new users complete meaningful tasks more easily and whether the speed or accuracy of experienced users deteriorates.
How Should We Measure Success?
One significant mistake would be to make tutorial completion the primary success metric.
Users might finish every onboarding screen and still be unable to accomplish the task that brought them to the product.
For our hypothetical sales analytics platform, I would define the measures as follows.
Primary Outcome Metric
The percentage of eligible new users who create and save their first genuine, valid sales report within seven days.
The denominator would consist of new users with appropriate access to reporting functionality. Users blocked by outstanding organisational permissions would be examined separately, preventing access-related problems from being confused with interface usability issues.
Diagnostic Metrics
Median time to the first valid report, abandonment rates at individual stages, data-import errors and unassisted task success in usability testing.
Guardrail Metrics
Time required for experienced users to complete advanced tasks, errors involving sensitive configuration, support requests about missing functionality and security or access-related problems.
These measures should be defined before testing begins.
We would then compare the proposed experience with an appropriate baseline or comparison group.
A faster first-report experience would not constitute success if report accuracy deteriorated or experienced analysts encountered substantial obstacles.
The objective is better task performance, not simply fewer screens or more clicks on an onboarding button.
What If We Had Only Two Weeks?
With such a short timeframe, a complete product redesign would be inappropriate.
The priority would be to identify the smallest meaningful opportunity to learn.
During the first week, I would review available analytics, map the existing onboarding journey and conduct a focused set of interviews and observations with novice and experienced users.
The aim would be to identify one or two recurring obstacles supported by evidence.
During the second week, the team would develop a limited prototype that simplifies the first important task while preserving access to advanced functionality.
We would test it with representatives of both groups, observing task success, time taken and any difficulties discovering features.
Promising results would justify planning a controlled test in the actual product. Weak results would prompt us to revisit the hypothesis before committing to wider development.
Two weeks would not establish the long-term effect on retention. It could, however, provide enough evidence to reject a poor idea or identify the next useful experiment.
What Would Make Us Change Our Decision?
Progressive disclosure is a conditional product decision, not a universal rule.
Suppose research showed that new users were primarily struggling because they lacked domain knowledge rather than because the interface was complicated.
Changing the initial screens alone would not solve the problem. We might need practical training or specialist support instead.
If experienced users had to make more clicks to access frequently used features, we would reconsider the information architecture, shortcuts or level of direct access.
Where initial configuration involved sensitive security requirements or regulatory obligations, streamlining the experience could not justify removing essential controls.
And if research demonstrated that two user groups had genuinely independent, stable requirements, separate workspaces might prove more suitable than a shared onboarding route.
A competent Product Manager should be able to explain both the evidence supporting a decision and the evidence that would justify changing it.
A Natural Interview Answer
Here is how I might answer the question in an interview:
"I'd start by understanding exactly where users are struggling and what they're trying to achieve. A professional tool isn't necessarily badly designed just because it's complex.
"First, I'd distinguish users according to their goals and familiarity with both the task and the software. Then I'd identify which capabilities they genuinely need to reach their first meaningful outcome.
"My initial hypothesis would probably be a task-based onboarding experience with progressive disclosure. New users could complete their first task without being overwhelmed by irrelevant settings, while experienced users would retain direct access to advanced tools.
"Before making a major change, I'd test a prototype with both groups. I'd want to see whether new users could complete their tasks more successfully without making experienced users slower or less accurate.
"If the evidence showed that the real problem was specialist knowledge, or that my proposed changes made professional workflows harder, I'd reconsider the approach.
"The goal wouldn't be to remove functionality. It would be to make the product easier to learn and use while preserving what makes it powerful."
Follow-Up Interview Questions
What Would You Do If You Had Only Two Weeks?
This is one of the two follow-up questions included in the original source.
A strong answer prioritises learning.
Rather than promising a complete redesign, we would select a recurring, high-impact problem, review existing evidence and evaluate a focused prototype.
We should also explain what we can reasonably learn in two weeks and what remains uncertain.
This demonstrates an understanding of the difference between validating an interaction concept and proving a lasting product outcome.
What Evidence Would Make You Reject Your Proposed Solution?
This is the second source follow-up and an important test of decision-making maturity.
If new users still failed to complete their first task using the simplified journey, we would need to investigate the underlying cause again.
If removing details from the initial screen concealed important information, or if experienced users required substantially more time for routine work, the design would need revision.
Equally, if interviews and usability testing challenged our original assumptions about user needs, we should be willing to abandon those assumptions.
A strong Product Manager does not defend a solution simply because they proposed it.
Common Mistakes in Interview Answers
Equating simplicity with removing features. This can undermine the very capabilities that make the product valuable to professionals.
Designing a single experience for everyone. Users with different goals and levels of expertise may need different entry points and levels of guidance.
Making design decisions without evidence. A cleaner-looking interface does not automatically mean users can complete their work more effectively.
Assuming a product tour will solve everything. Instructions delivered outside the relevant task may create another obstacle rather than remove one.
Relying on tutorial completion or click counts. These measures do not demonstrate that users have achieved a meaningful outcome.
Burying advanced functionality in obscure menus. This can increase the cost of performing everyday tasks for experienced users.
Ignoring operational and security risks. A shorter workflow is only valuable if the quality and safety of the experience are maintained.
Conclusion
Simplifying the initial experience of professional software should not begin with indiscriminately removing functionality. It should begin with understanding users, identifying their essential tasks and discovering which obstacles prevent them from reaching a meaningful outcome.
For many professional applications, task-based onboarding, progressive disclosure and contextual guidance provide a sensible starting point. But the approach must preserve expert efficiency, essential safeguards and the product's flexibility. If research reveals a different underlying problem, or testing shows that expert workflows are being harmed, the decision must change.
A powerful product does not have to become less capable to feel simpler. It needs to make the right capabilities available to the right users at the right moment.
