The public part presents the service, and the app helps to use it. A well designed transition explains the difference and leads both to the new and current customer.
Give both parts separate tasks
The new recipient needs an explanation of the scope, examples and way of contact. The current client may want to enter the panel immediately and perform a specific action. The page should not force both people to go through the identical path.
Save which information is public and which requires login. The very existence of an account does not mean that all knowledge about the service must be hidden behind it. Description of the possibility and how to start cooperation should be available without guessing the rules of access.
Mark the transition unambiguously
The link to the application is called according to its role. “Customer panel” gives a different context than “Learn More”. Once you have passed, keep your recognizable brand and explain where the user is, especially if the domain or header appearance changes.
For example, a customer watching a service offer may want to check his own application. A clear entry to the panel saves him from re-filling the form for new cases.
Prepare situations without ready access
The new person may not have an account, forget the data or go to the address for authorized users. The interface should present the right next step, in accordance with system rules.
When receiving, check:
- the entry of a new consignee;
- login of the current client;
- information on how access is obtained;
- return to the public tender;
- help with the account problem;
- behaviour after the end of work.
Agree Joint Responsibility
The site and application can be developed separately, but the names, scope and contact should remain consistent. Changing the panel function may require improvement of the offer description. Determine who is guarding both places. Read more about the inside of the system in client panel design i roles and state of application.
