You open a new workspace. The sidebar offers CRM, pages, forms, projects, files, automations, and AI.
You came to do one thing: reply to an inquiry.
Which tool do you open first? Where is the inquiry? Will the AI know which customer you mean?
This is an illustrative situation, not a report about CORA’s current interface. It exposes a design problem worth checking: a workspace can explain its features without helping someone begin their work.
Give the work a front door
A feature describes what the software contains. A task describes what the person wants to accomplish.
You may need a CRM, a page editor, and a project board. You do not need to make a new user learn the whole structure before they can start a relevant task.
Nielsen Norman Group’s recognition-and-recall guidance recommends making relevant information and actions visible instead of requiring users to retrieve everything from memory. For a workspace, one practical application is to expose recognizable jobs alongside the underlying tools.
That is a design hypothesis to test, not a guarantee that task labels will improve activation.
Map a job to its working context
Consider these examples:
Publish a page opens the relevant website draft, with its review and publishing steps visible.
Reply to an inquiry opens the selected inquiry record, not a blank chat that requires the user to repeat the details.
Continue client work opens the relevant project record, with its next action visible.
These are illustrative navigation patterns, not verified CORA features. Each depends on the product actually supporting the task and the user having access to its records.
The task label should lead to work the person can begin. A shortcut that opens the same general dashboard has only moved the confusion.
Design the first visit and the return visit separately
A new user may have no inquiry, website draft, or project yet. Showing an empty record list does not explain how to create one.
For a fictional website tool, a new-user entry might say “Create your first page” and explain the inputs it needs. A returning-user entry might say “Continue your homepage draft” and identify the saved draft.
Do not display “Continue” when nothing was saved. Do not present sample content as the user’s real work. If you offer a demonstration, label it as a sample and keep its records separate.
When the user must choose among several records, show enough context to recognize the right one. A project name, current status, and last update can be more useful than an unexplained identifier.
Keep broad access without making every feature the first step
You do not have to remove the full navigation. Keep stable access to the product’s tools and add a focused place to start or resume important jobs.
Choose that initial set from customer conversations and observed work. If the evidence is thin, start with one audience and one task. Avoid treating the founder’s personal workflow as everyone’s priority.
A consultant preparing a proposal and a shop owner updating a page may need different starting points. A broad product can support both without presenting every possible job to both people at once.
Make room for discovery after the immediate task becomes understandable. Keep labels and locations predictable when users return.
Make AI a helper inside the job
An open-ended AI box can help experienced users. It should not be the only explanation of what a new user can do.
Inside a selected inquiry, a contextual action such as “Draft a reply” makes its object clearer than “Ask AI” on an empty screen. Show which record supplies the context and let the person review the output.
If the assistant cannot access the record, say so. Ask for the missing input rather than implying it already knows. A task shortcut must not widen permissions, expose another client’s data, or turn a draft action into automatic sending.
Clear navigation and careful AI behavior solve different parts of the problem. One cannot stand in for the other.
Test one task without explaining your sidebar
Give a relevant participant a concrete scenario: “You have a new inquiry from a potential customer. Find where you would prepare a response.” Use synthetic data and an appropriate test account.
Watch their first choice. Ask what they expect the destination to contain. Then observe whether they reach the right record and can identify the next action without coaching.
Record the labels they tried, where they hesitated, and what stopped them. Try a revised entry with fresh, similarly relevant participants. A few sessions can reveal usability problems; they do not establish a conversion lift or product-market fit.
Your repair brief can stay small: “People opened the general AI chat because they could not find the inquiry. Test a visible inquiry-to-reply route.” Keep the proposed route separate from a completed product change.
The CORA connection
Explore CORA’s website-and-workspace direction. The broad AI co-founder ambition can coexist with a concrete starting job that a founder recognizes.
This issue offers a design practice, not an announcement that CORA already implements these shortcuts, contextual AI actions, or resume states. Verify each behavior before promising it.
Do it today: choose one common job. Write its entry label, the record it should open, the next action, and the first-visit alternative when no record exists. Test that path before reorganizing the whole workspace.
Keep the workspace broad. Make the next useful job easy to recognize.
— Dravya Bansal
