_edited.png){kind=small}
Key Lessons Learned from Developing an Access Based Portal for a Maritime Recruitment Agency
- Neda Yavari
- Aug 19
- 12 min read
I recently developed a portal for a client with very specific requirements. The central idea was simple: different groups of users should be able to see different content depending on their role. In practice, this raised some interesting challenges.
In this post I want to share how I approached the project, the decisions that had to be made along the way, and some lessons that might help anyone tackling something similar.
These were the main steps I followed during development. You can jump straight to the one that feels most relevant, but I would recommend reading through them all as each stage carried its own lessons and shaped the final result:
1. Login and Signup Development
Getting the basics of login and signup right is crucial, because it sets the tone for the entire portal. If this stage feels confusing, insecure, or inconsistent, users will lose confidence straight away. In this project, we had to think carefully about what information to collect, how to use it, and how to keep the process both simple for users and safe for the client.
Collecting the Right Information
When designing the signup process, the first question was: what information should be collected from users to determine their level of access? At a minimum, this included their name, email, and role within the organisation. However, even with these details, it wasn’t always clear what content they should be allowed to see. A job title might suggest one thing, while their actual responsibilities or seniority might suggest another. This meant the system needed flexibility built in from the start.
Moving Away from Job Title Based Access
The initial idea was to assign access automatically based on job title. It was a neat solution in theory, but real-world use revealed the flaws quickly. Job titles are inconsistent across organisations, and in some cases the same title could carry different responsibilities. There were also exceptions where individuals needed more or less access than their title suggested.
Introducing Access Levels
Instead of linking access to roles or titles, we created a tiered system of Gold, Silver, and Bronze levels. These levels acted as broad categories for permissions. Gold users could access all content, Silver users had access to most resources, and Bronze users had limited visibility. This structure gave the client clear, simple rules that could be applied consistently across the portal.
Security and Admin Approval
Security was a key consideration. Allowing users to gain access automatically at signup would have created risks, so we implemented an approval stage. Once someone registered, their details were reviewed by an administrator. Only after approval were they assigned an access level. This ensured the right people had access to the right content, and sensitive materials remained protected.
Flexibility for Exceptions
One of the strengths of this system was its flexibility. If a user’s circumstances changed (for example, a promotion or a shift in responsibilities) their access level could be updated quickly by an admin. This was far easier than trying to redefine access rules around every possible role or title, and it meant the system could adapt over time without major changes.
Future Proofing Access Management
Another consideration was growth. As the portal expanded, more users would sign up and more content would be added. By building the access system around levels rather than rigid role definitions, the client now has a framework that can scale without becoming unmanageable.
2. Portal Navigation Planning and Development
Once users were able to log in, the next challenge was making sure they could actually find their way around. A portal can succeed or fail on navigation alone, so we put a lot of thought into how someone new to the system would explore it. The aim was to make the journey clear, logical, and as intuitive as possible, with no hidden corners or unnecessary complexity.
Guiding Users After Login
One of the first considerations was what should happen immediately after a user logged in. The portal was designed to take them straight to the dashboard with the content area that mattered most. This reduced unnecessary clicks, avoided confusion, and gave users the sense that they were being guided rather than left to figure it out for themselves.
Mapping the User Journey
It was important to think like someone visiting the portal for the very first time. How would they know where to go? What would they expect to see? By mapping out the user journey step by step, we were able to identify potential sticking points and remove them before launch. This included decisions about what appeared on the dashboard, how categories were ordered, and what cues would make the next step obvious.
Designing Clear Sectioning
A portal can quickly feel overwhelming if it lacks structure. To avoid this, the content was divided into clear sections, each reflecting a distinct category. The navigation menu matched these sections exactly, so there was always a direct link between the content users expected and the path to get there. Consistency in naming and organisation made it much easier for users to move around without second guessing themselves.
Balancing Simplicity and Depth
The challenge with navigation is often balance. Too many categories can make the system cluttered, while too few can make it difficult to find specific items. In this case, we aimed for a structure that was broad enough to cover different content types but not so detailed that users would feel lost in endless sub-menus.
Consistency Across Devices
Another consideration was how users would access the portal. Many would log in from desktop, but some would rely on tablets or mobiles. Ensuring the navigation worked consistently across devices was crucial. A responsive layout, clear labelling, and touch friendly menus kept the experience smooth regardless of screen size.
Reducing the Need for Support
A well planned navigation system reduces the number of questions and support requests. By putting thought into how users would naturally move through the portal, we created a system where people could find what they needed independently. This frees up administrators from answering routine queries and allows them to focus on managing content and approvals instead.
3. Content Management with Databases and Dynamic Pages
Content is the real heart of a portal, but the way it is managed can make all the difference between a smooth experience and a frustrating one. Early on we realised that simply uploading files to static pages would quickly become unmanageable. To avoid that, we focused on building a structured, database-driven system that could grow with the client’s needs.
Why Static Pages Were Not Sustainable
At the start of the project, one option was to upload each file or piece of content directly onto static pages. While this would have been quicker to set up, it would have caused major problems later. Every new document would have needed its own page, and any design change would have had to be repeated manually across all pages. For a small library this might be manageable, but as soon as the portal began to grow it would have turned into a nightmare of repetitive work.
Building with Databases
To avoid this, we built the portal around a database driven structure. Each piece of content (PDF, video, link, etc.) was stored as an entry in a central database. This database held key information such as the title, description, content type, and assigned access level. Instead of duplicating work, administrators only had to add content once, and the portal would use that data to create the necessary pages automatically.
Designing Dynamic Pages
With the database in place, the next step was to design dynamic pages. These pages pulled information directly from the database and displayed it in a consistent layout. This meant the design was created once, then reused for every new item. The result was a uniform look across the portal, with no risk of one page drifting out of sync with the others.
Handling Different Content Types
The portal needed to support multiple formats, including downloadable PDFs, embedded videos, and external links. To manage this, we created templates within the dynamic pages that adapted based on the content type. For example, a video entry automatically displayed an embedded player, while a PDF entry showed a preview window with relevant metadata. This flexibility allowed the portal to scale across a wide range of resources without requiring separate designs for each format.
Simplifying Future Updates
Another key advantage of this structure was the ease of future changes. If the client wanted to update the way content looked (for example, adjusting the layout or styling) they only needed to make that change once. The update would then apply across every page generated from the database. This drastically reduced the time and effort needed for ongoing maintenance.
Improving Organisation
By using a database, content could be categorised and filtered in ways that static pages could never support. Users could browse by type, category, or access level, while administrators could sort and search the database to manage content more efficiently. This organisation ensured the portal remained usable as the library expanded.
Preparing for Scale
Finally, building on a database meant the system was ready for growth. Adding a few dozen documents was just as straightforward as adding a few hundred. The structure removed the limits of manual page creation and gave the client confidence that the portal could keep up with their future needs.
4. Access Levels in Practice
Having a login system and a well-structured library is one thing, but making sure users only see the content they are entitled to is another challenge entirely. This was where access levels came into play. By linking content visibility directly to assigned permissions, we were able to keep the system secure without creating unnecessary barriers for genuine users.
Linking Content to Access Levels
Once the database and dynamic pages were in place, the next step was to connect each item of content to an access level. Every entry in the database was tagged as Gold, Silver, or Bronze, ensuring the portal could cross-check this against a user’s assigned level. This meant the rules for who could see what were built directly into the system rather than being managed manually.
Checking Permissions on Login
When a user logged in, the portal compared their access level with the permissions attached to each piece of content. If the user’s level matched or exceeded the required level, they could see and interact with the content. If not, the content remained hidden and a clear message explained that it was restricted. This created a consistent and predictable experience for all users.
Avoiding User Confusion
It was important that users were never left guessing why they could not see something. Instead of blocking access without explanation, the portal displayed a friendly notice when a user clicked on content above their level. This helped manage expectations and reduced the risk of support queries.
Tailoring the Experience
By linking content directly to access levels, we could also tailor the navigation menus and categories. Bronze users only saw what they were entitled to, so their menus were shorter and simpler. Gold users had access to everything, so their view was broader and more detailed. This meant the portal felt designed for each user group rather than presenting a one-size-fits-all structure.
Supporting Admin Flexibility
The tiered system also gave administrators flexibility. If someone’s responsibilities changed, their access level could be updated with a single adjustment. There was no need to rewrite permissions for each individual item. This balance of simplicity and control kept administration light while still offering strong security.
Security Through Simplicity
The clear levels also added a layer of security. Because content was locked to specific categories, there was no risk of users stumbling across material they should not see. The consistency of the system meant that sensitive content stayed protected without admins having to double-check each file.
Preparing for Future Expansion
Finally, the level system left room for growth. New levels could be added if needed, or existing levels could be subdivided for greater granularity. The framework was designed to scale, ensuring the client would not need to overhaul the system as their requirements evolved.
5) Bonus Feature: Requesting Hard Copies via Email
One of the most interesting parts of the project was developing a way for users to request hard copies of files. On the surface, this sounds like a small feature, but in practice it solved a very real problem. Users needed an easy way to get hold of documents, while administrators needed a process that wouldn’t eat up all of their time. The solution turned out to be one of the most efficient parts of the entire build.
Why a Request System Was Needed
By default, users could view PDF documents within the portal but not download them directly. This restriction was important for security and content control, but it created a challenge: some users genuinely needed access to a copy of the file. A manual approach where admins fielded every request by email and attached documents one by one would have been unmanageable, especially at scale.
Capturing Requests in Context
The solution was to allow users to submit a request for a hard copy directly from the page they were viewing. When a user clicked the request option, the system automatically captured key details about the file, such as its title and ID, along with the user’s information. This removed the possibility of confusion about which file was being requested.
Storing Requests in a Dedicated Database
All requests were logged in a separate database that linked back to the content library. This meant administrators could see at a glance who had requested which file, when the request was made, and whether it had been actioned. Having a structured record not only made the process smoother but also provided a clear audit trail.
Streamlining Admin Approvals
Rather than expecting administrators to download files, write emails, and attach documents manually, the system was designed to make approvals effortless. With a single action, an admin could approve a request, and the system handled the rest. This simplicity was vital because not all admins had technical backgrounds or the time to manage a complex process.
Automating Email Delivery
Once a request was approved, an automated email was triggered. The system pulled the file details from the database and inserted them into a pre-designed email template, including a secure download link. This ensured that the user received exactly what they needed without delay, and administrators avoided repetitive manual work.
Saving Time at Scale
The automation made a significant difference. Instead of dealing with individual requests one by one, administrators could process them quickly and focus on other priorities. For a portal with dozens or even hundreds of requests each day, this efficiency was essential.
Improving User Experience
From the user’s perspective, the process felt seamless. They made a request in context, and once approved, the file arrived directly in their inbox. This avoided the frustration of waiting for someone to manually respond and meant users could continue working without unnecessary delays.
Building Trust Through Transparency
Finally, the system included clear messaging at every step. Users were informed that their request would be reviewed, and administrators could see exactly what was pending. This transparency built trust in the system and helped set realistic expectations on both sides.
Main Lessons Learned
Reflecting on the project, several lessons stood out that are worth keeping in mind for anyone designing or developing a role based portal.
1. Automate whenever possible
Manual processes can seem harmless when the system is small, but as the portal scales they quickly turn into bottlenecks. In this project, automation made a tangible difference: dynamic pages eliminated the need to duplicate layouts for every new item, and automated approval emails saved administrators hours each week. Every time you find yourself repeating a task, it is worth asking if it can be automated.
2. Stay flexible in your approach
The original plan to link access to job titles made sense on paper, but real use showed its flaws. Rather than forcing the system to fit that idea, we introduced admin-assigned access levels. This flexibility not only solved the immediate issue but also gave the client a way to handle future exceptions. Projects rarely go exactly as planned, so being willing to adapt makes the end result stronger.
3. Keep things structured from the start
Databases added some initial setup time, but they transformed how the portal could grow. With structured data feeding dynamic pages, content remained consistent, easy to manage, and far more scalable. Without this approach, even small updates would have become tedious and error prone. Investing time in structure early pays off many times over later.
4. Prioritise the admin experience as much as the user experience
It is tempting to focus only on the people using the portal day to day, but the administrators managing the system are just as important. If the backend is too complicated, the portal will eventually break down, no matter how polished the front end looks. Simplifying approvals, automating file requests, and making sure non-technical staff could manage the system confidently were all essential.
5. Plan for scale, even if you don’t need it yet
The client began with a manageable amount of content, but the system was designed with growth in mind. By planning for scale at the start, we avoided redesigning workflows later. Thinking ahead about growth in content, users or functionality keeps a system stable and avoids costly rework.
6. Map the user journey in detail
Navigation was not just about menus, it was about predicting how a new user would think, where they might click, and what could cause confusion. By mapping the journey step by step, we created a structure that guided users without the need for instructions. A portal can have advanced features, but if people feel lost, those features will never be used effectively.
7. Balance security with usability
Security was central to this project, but it had to be balanced with ease of use. A system that is too restrictive frustrates genuine users, while one that is too open risks exposing sensitive content. The approval based signup struck that balance, keeping the process straightforward while ensuring the right content stayed protected.
8. Document everything
With multiple databases, approval steps and automated workflows, documentation became essential. Clear records of how the system worked gave the client’s team confidence to maintain it themselves. Without documentation, even the best system risks becoming dependent on the original developer, which limits flexibility later.
I hope sharing this experience proves useful as you plan your own projects. If you’d like to discuss an idea or need support with something similar, feel free to get in touch!
Comments