A software brief often starts with a list of screens: a dashboard, a portal, an approval page. Those screens are useful to discuss, but they are the visible part of a larger system. Behind each one are people, records, rules and a decision about what should happen next.
Our preferred starting point is a piece of work moving through the business. Take one request and follow it from the person who creates it to the person who knows it is complete. The details along that journey make the brief more useful.
Follow one real journey
Consider a partner submitting a request that needs an internal review. What information arrives? Who checks it? Where does the agreed version live? What happens if a document is missing, the reviewer is away or the request changes halfway through?
The normal path matters. So do the exceptions. A workshop becomes much more concrete when the team can bring an example of a request that went smoothly and another that needed several emails to resolve.
This is also a chance to understand the tools that already work. A new application may need to sit beside an accounting system or an existing operational database. That relationship should be part of the design from the beginning.
Give each record a clear home
When two teams maintain separate versions of the same information, a new dashboard can make the disagreement more visible without resolving it. Before designing a shared view, agree which record is authoritative and who can change it.
Ask practical questions. Which system owns the customer identifier? Who corrects an address? Is an approved amount editable? What should happen to a report when a record is revised?
These answers establish the meaning of the interface. They also give the engineering team something specific to test.
Design for responsibilities
Different roles need different levels of detail and different actions. A person entering a request may need a clear next step. A reviewer may need the supporting history. A leader may need exceptions that require attention.
We prefer to describe a role in terms of its responsibilities before listing its permissions. That makes it easier to distinguish viewing, editing, reviewing and approving. It also helps avoid interfaces that present every action to every person.
Define a useful first release
A first release should complete a meaningful journey. That might be one request type, one group of partners or one operational team. The boundary should make the work manageable while still letting the team experience a complete outcome.
Agree what completion means. Examples might include a request reaching its final state, a failed integration being visible to the right person, or a record being traceable through a review. The criteria should reflect the operation rather than a count of completed screens.
Leave room to learn
Real use will reveal questions that discovery did not. Build a way to collect those observations and decide which changes matter next. A shared issue list, an accountable owner and a regular review can make that learning part of the partnership.
The result is a more useful starting point for enterprise software: an application shaped around how a business works, with a clear path for improving it.
Explore our enterprise application practice, or talk to us about a workflow.