An employee portal is opened for four things: booking leave, checking a payslip, updating a detail and finding one specific document. Everything else placed on it is read once at launch and then never again. Designing for those four tasks produces a portal people use; designing for communication produces one they do not.
Design for the four tasks
Put them on the first screen, make them work on a phone, and make each completable in under a minute. A portal where booking leave takes four clicks from the home screen will be used; one requiring navigation through a menu of policies will be abandoned and the requests will arrive by email again.
Documents people need, not documents you have
A portal accumulates policies because publishing them is easy and nobody removes anything. The result is a search that returns eleven versions of a handbook. Keep a short, current, findable set, put a review date on each, and delete superseded versions rather than archiving them somewhere people can still find them.
Frontline access is a separate question
People without a desk or a work email frequently cannot reach the portal at all, which makes it a tool for office staff that is described as a tool for everybody. If that describes part of your workforce, the honest answers are an app, a shared device, or accepting that those people are served another way.
Questions people ask about employee portal
Should the portal be the internal communications channel?
Rarely successfully. People open a portal for transactions and read communications where they already are.
How do we get frontline staff on it?
A phone app that works on personal devices, or a shared device on site. Email based access excludes them by design.
How much content is too much?
If search returns several versions of the same policy, too much. Currency matters far more than coverage.