Redesigning a Customer Portal and Platform: UX, Roles and Protected Areas

By Edip Kilinc, founder of Webwavers. Published October 31, 2026. Last updated October 31, 2026. Reading time: about 15 minutes. This text is not legal or security advice.

Short answer: You redesign a customer portal or platform by first clarifying tasks and roles, deriving the information architecture from them, testing prototypes with real users, and only then working out the interface and a design system. Building login, permissions and integrations is a separate job. Ask every agency which of these parts it builds itself and where it hands off to your team or a technology partner.

The key points in brief

• Start with tasks and roles, not colors. A portal is a tool in which people get something done.
• Permissions are enforced on the server, not in the interface. Hidden menu items protect nothing.
• Test prototypes with a few users per role, several times, with revisions in between.
• The technology for protected areas is a separate decision. Membership services, standard software and custom applications each have clear limits.
• "Design and implementation from one source" is only an advantage if it is clear who builds what and who operates it.

Important note: This guide explains UX approaches and architecture decisions and names the source for each. It is not legal or security advice. Data protection, security and accessibility in your specific case are something you clarify with your data protection officer, your IT security team or a specialist.

Table of contents

• What is a customer portal?
• Redesign or improve step by step?
• Step 1: Clarify tasks and roles
• Access and security: permissions belong on the server
• Login, SSO and passkeys
• UX principles for complex interfaces
• Approach in phases
• Technology for protected areas: the options
• Design and implementation from one source?
• Accessibility and data protection
• Rollout and measurement
• Briefing checklist for the agency
• Questions to ask an agency
• When you don't need an agency
• How we implement this
• FAQ

What is a customer portal?

A customer portal is a protected area in which customers, partners or employees get things done after signing in: view orders, download documents, submit requests, maintain data, check invoices, track status. A platform goes further: it bundles several functions, roles and data sources in one application. Both differ from the public company website in one essential point. Here the interface is not advertising but a tool.

It follows that the yardstick for good design is not "I like it" but "does the user complete their task quickly, correctly and without support?" And: a portal depends on processes, data and permissions that sit behind the interface. If you only redraw the interface, you rarely improve the experience.

Redesign or improve step by step?

Not every portal needs a complete redesign. The following comparison helps with the decision.

Situation	Rather a complete redesign	Rather step-by-step improvement
Core tasks	Have changed or are missing in the portal	Work, but are cumbersome
Information architecture	Fundamentally not aligned with user paths	Sound at its core
Technology base	Outdated, hard to extend	Stable
Design	Inconsistent, no system	Consistent with gaps
Risk	Manageable (parallel operation possible)	Users depend on it, downtime is expensive
Time frame	There is a project with budget and owners	Improvements during ongoing operation

A redesign is riskier because users cling to habits, and every detail breaks something someone used daily. It pays off when tasks, roles or technology have changed fundamentally. Otherwise the step-by-step route is usually calmer: fix problems, unify components, introduce a design system, switch over area by area.

Step 1: Clarify tasks and roles

Before anyone draws wireframes, you need three things: a list of the most important tasks, a list of roles and a mapping between them.

You phrase tasks from the users' point of view: "I want to see the status of my order", "I want to download an invoice as a PDF", "I want to add an employee". Collect them from interviews, support tickets, usage data and sales conversations. Weight them by frequency and importance.

Roles are groups with different permissions and goals. A role matrix makes them visible:

Role	Example tasks	Can see	Can change
Customer, main user	Manage orders, invite users	All data of their own company	Users, master data, orders
Customer, employee	Check status, download documents	Data of their department or projects	Their own entries
Customer, accounting	Check and download invoices	Invoices, payment status	Payment data
Partner or dealer	Offers, prices, inventory data	Partner area	Their own terms according to contract
Internal support	Check accounts, solve problems	Customer data with logging	Limited, traceable
Administrator	Configuration, user management	Everything that is necessary	System settings

The matrix has two functions. For design, it determines which home page and navigation each role sees. For technology, it is the specification of the permissions. The same table has to be right in both worlds, otherwise gaps appear.

Access and security: permissions belong on the server

A common mistake in portal projects: the interface hides functions a user isn't allowed to use, and the team considers the topic done. But security doesn't come from what the interface shows, it comes from what the server allows.

The OWASP Top 10 of 2021 ranks "Broken Access Control" first, up from fifth place in 2017. According to OWASP, 94 percent of the applications tested were checked for some form of this problem, and the average incidence rate is 3.81 percent. As examples, OWASP names insecure direct object references (an attacker views or changes another user's account by supplying its identifier) and directly calling protected URLs. As a principle it states: except for public resources, "deny by default" applies (OWASP Top 10:2021, A01 Broken Access Control).

What this means for your project:

1. The role matrix is enforced server-side. Every request for data is checked against role and ownership, even if the interface doesn't offer the path to it.
2. Identifiers in URLs are no protection. If invoice number 1042 appears in the address, user A must not be able to see user B's invoice by changing it to 1043.
3. Allow nothing by default. New functions are only released to roles once someone deliberately grants them.
4. Log access. Especially for internal roles that see customer data.
5. Test. Penetration tests, or at least structured permission tests, belong before the rollout. This is a job for security specialists, not for the UX team.

For design this means: don't show what a user isn't allowed to use, but never rely on hiding being enough. The interface follows the permission logic, it doesn't replace it.

Login, SSO and passkeys

Login is the first hurdle in the portal. It has to be secure and still not get in the way.

Single sign-on (SSO). With business customers, many want to sign in with their employer's account. A widespread standard for this is OpenID Connect, a layer on top of OAuth 2.0: an identity provider authenticates the user and issues the portal an identity token. The advantage for the portal: it doesn't have to set, store or manage passwords (OpenID Foundation). SAML also exists, an older standard that is common in enterprise environments. Which variant your customers need is something you clarify with their IT, not at your desk.

Passkeys. The FIDO Alliance describes passkeys as passwordless, phishing-resistant credentials based on FIDO2 and WebAuthn: sign-in happens with the device's unlock method, and there are no shared secrets that could be stolen on the server (FIDO Alliance). For portals, passkeys are an option that can improve security and convenience at the same time, if your target group can use them.

Two-factor authentication and invitations. For sensitive data, a second factor is standard. The invitation process for new users (who invites whom, how the first login works) is one of the underestimated parts of a portal, because this is where most support requests come from.

Accessible login. Success criterion 3.3.8 of WCAG 2.2 (Level AA) requires that authentication steps don't depend on a cognitive function test, such as remembering passwords or retyping characters, unless an alternative exists. Pasting and autofill must not be blocked (W3C, Accessible Authentication). This particularly affects two-factor codes, which must be pasteable.

UX principles for complex interfaces

Portals have many functions and a lot of data, and that is exactly why they fail through overload. Jakob Nielsen's ten heuristics (1994) are useful here too (Nielsen Norman Group). Four of them matter especially for portals:

Heuristic	What it means in a portal	Typical problem
Visibility of system status	Users see what is happening right now: upload running, request received, approval pending	Actions without feedback
Match between system and the real world	Users' terms instead of internal jargon	Menu items named like database tables
Error prevention	Confirmation before critical actions, sensible defaults	Deleting without asking
Recognition rather than recall	Options visible, filters rememberable, recently used items at hand	Users have to know numbers and paths by heart

Further elements that often get short shrift in portal projects:

• Home page per role. The dashboard shows what this role needs first, not everything at once.
• Tables and filters. Data lists are a core component: selectable columns, sorting, search, saved filters, export.
• Empty states. What does a new user see when no data exists yet? A good first view explains the next step.
• Error states. Timeout, missing permissions, integration outage: every case needs a clear message with a next step.
• Notifications. Which events trigger an email, which stay in the portal? Choose deliberately, otherwise you get noise.
• Help in the right place. Contextual hints instead of long manuals.

A portal is also a place where consistency counts. If buttons, tables and forms behave differently in every area, the user never learns, they guess. That is why a design system belongs in the redesign: define components, variants and states cleanly once and use them everywhere. How the handoff from Figma to development works is described in the guide Design systems from Figma to Webflow.

Approach in phases

An agency that takes a portal redesign seriously works in traceable phases. The table shows a typical approach with the results you can demand in each phase.

Phase	Content	Result	Who is involved
1. Starting point	Interviews, support tickets, usage data, inventory of functions	Problem list, task list, role overview	Product owner, support, sales, customers
2. Structure	Role matrix, information architecture, key processes as flows	Sitemap, flows, permissions concept	Product owner, technology
3. Wireframes	Rough screens for the most important processes	Clickable wireframe prototype	Product owner, departments
4. Test	Prototype test with users of all main roles	Test report, prioritized changes	Users, product owner
5. Interface and design system	Visual design, component library, states	Design in Figma, documented design system	Brand, technology
6. Handoff	Documentation, acceptance criteria, open questions	Handoff package for development	Technology
7. Implementation	Frontend, permissions, integrations, tests	Working application	Development
8. Rollout	Pilot group, training, parallel operation, support	Completed migration	Support, customers

On testing: As early as 2000, Nielsen described that a test with about five users finds roughly 85 percent of usability problems, with a single user uncovering about 31 percent on average. He recommends several small tests with revisions in between, and for several user groups three to four users per group with two groups and three users per group with three or more groups (Nielsen Norman Group). For a portal with four roles, that means: rather several small rounds with three people per role than one big survey. This is a rule of thumb for usability problems, not proof of the success of the overall project.

Technology for protected areas: the options

Technology decides what is feasible, secure and maintainable. The following options each have clear limits.

Option	Suited for	Limits
Member area on the website through an add-on service	Simple protected content (downloads, knowledge area)	Limited role logic and data processing
Standard customer portal in the CRM, ERP or ticketing system	Processes the specialist system covers anyway	Design and flow follow the product
Custom web application with its own backend	Complex roles, workflows, integrations, special data models	High development and operating effort
Hybrid: marketing website plus portal at its own address	Separating public site and application	Two systems, coordinated design needed

A current example of the risks of add-on features: Webflow discontinued its membership feature "User Accounts" (formerly Memberships) on January 29, 2026. Since January 31, 2025, it could no longer be activated on new sites. With the shutdown, access to accounts and data ended, content gates were removed, members could no longer sign in on published sites, and the related APIs and webhooks were turned off. Webflow recommends Outseta and Memberstack as alternatives (Webflow Help, User Accounts sunset). The lesson is not "Webflow is unsuitable" but this: if you build protected areas on a platform feature, you become dependent on its roadmap. So for every building block, check what happens if the provider changes or discontinues it, and how you export your data.

A website in Webflow can be a strong frontend for marketing, documentation and public areas. For a portal with roles, specialist data and processes, you usually need an application with its own backend or standard software. The sensible boundary lies where content ends and application logic begins.

Design and implementation from one source?

Many ask: "Which UX/UI agencies also implement their design technically themselves?" It pays to ask the question more precisely.

Model	Advantages	Risks
UX/UI agency implements design and frontend	Fewer handoff losses, single point of responsibility	Backend, permissions and operations are often not part of the offer
UX/UI agency hands off to your development team	Your team knows the system and runs it	Handoff must be documented, follow-up questions cost time
UX/UI agency plus technology partner	Specialization	Coordination effort, shared responsibility
Development house with its own UX team	Design and technology closely linked	Design quality and brand work vary widely

What matters is not the model but clarity: who builds the interface, who builds the permissions, who builds the integrations, who tests, who operates? Have this written down in a responsibility chart. You'll find more arguments for and against in the guide Design and development from one team and in the general selection aid Choosing a UX/UI agency.

Accessibility and data protection

Accessibility. The Accessibility Strengthening Act (BFSG) has applied since June 28, 2025 and covers services in electronic commerce toward consumers. An offer that is actually and exclusively aimed at businesses is in principle not subject to the consumer rules, although the label "B2B" alone is not enough. Microenterprises are exempt for services (IHK Schwaben on the BFSG). Whether your portal is affected is a legal question, see Accessible website and BFSG. Independently of that, WCAG is a sensible quality yardstick for portals: contrast, keyboard operation, focus management and labeled form fields (glossary: WCAG).

Data protection. A portal processes customer data permanently. Art. 25 GDPR (DSGVO) requires data protection by default, meaning only the necessary data by default (Art. 25 DSGVO). Art. 32 GDPR requires security measures appropriate to the risk, such as encryption, ensuring confidentiality and regular review (Art. 32 DSGVO). For design this means: show only data the role needs, limit exports, plan deletion functions and logs. For technology: tenant separation, encryption, permissions concept, backups and a procedure for incidents. For data processing on behalf of others, you need contracts under Art. 28 DSGVO. When professionals bound by professional secrecy run a client portal, additional professional-law requirements for service providers apply (§ 43e BRAO, the German Federal Lawyers' Act, and § 62a StBerG, the German Tax Advisory Act), see Initial consultation funnel for consultancies.

Rollout and measurement

A new portal is only good once users adopt it. Plan the rollout like a project of its own:

1. Pilot group. A small group of friendly customers works in the new system first and gives feedback.
2. Parallel operation. Old and new portal run side by side for a limited time, with a clear end date.
3. Migration. Data, accounts and permissions are transferred and checked by sampling.
4. Communication. Users learn early what changes, why and where they can get help.
5. Training and help. Short guides, hints in the portal, reachable support.
6. Fallback plan. What happens if the launch fails? A plan B has to exist before the start.

You should measure by tasks, not by page views: How many users complete the core tasks? How long do they take? How many support requests on which topics are there before and after launch? Which functions are used, which aren't? Set these values as a baseline before the redesign, otherwise you can't prove success. Measuring inside the portal itself is also subject to data protection, especially when behavior is attributed to individual people.

Briefing checklist for the agency

The better your briefing, the more comparable the offers become.

1. Objective: Which problem should the redesign solve, how will you recognize success?
2. Users and roles: Who works in the portal, with which tasks, how often?
3. Current state: Which functions, pages and processes exist today? Screenshots, process descriptions, access to a test environment.
4. Data and systems: Which data sources, integrations and specialist systems are connected?
5. Login: SSO, two-factor, invitation, password reset, existing identity provider.
6. Security and data protection: requirements, conditions, approval processes, contacts.
7. Brand: guidelines, design system, component library, if available.
8. Technology: existing frameworks, development team, operations, hosting.
9. Constraints: time window, dependencies, decision makers, internal resources.
10. Rollout: pilot group, migration, training, support.

Questions to ask an agency

• Which portals or platforms have you designed, and which part did you implement yourselves?
• How do you work with roles and permissions, and who designs the permissions concept?
• How do you test prototypes, with whom and how often?
• How do you document the design system and the handoff to development?
• Who implements login, permissions, integrations and security tests? If not you, who?
• How do you handle accessibility, and against which standard do you test?
• How does the rollout work, and what does support afterward include?
• What happens if a building block you use is discontinued?

Anyone who gives concrete answers to these questions is better placed than someone with a nice reference image. You should be wary of statements like "We do all of it from one source" without a split of responsibilities.

When you don't need an agency

If your portal is a standard product that you configure (such as the customer portal of your CRM or ticketing system), the product's own options and an internal team are often enough. If you have your own development team with design support and only a design system is missing, a small consulting project can also be enough. And if the problems lie more in processes than in the interface, clarifying the process helps before any design. An agency pays off when roles, processes and brand have to be rethought together and you lack the outside view and the method.

How we implement this

A project at Webwavers typically runs the way it is laid out on our process page: initial conversation, onboarding with briefing (34 strategy questions), strategy session, moodboards, design in Figma with feedback rounds, development after final approval and launch with training. Our UX/UI Design page states that besides company websites we also design portals, customer areas and web apps: first the user paths, then the interface, then the design system. In clickable prototypes you can, for example, play through a login before any code exists. We build the components with variants and tokens in Figma and document them. On request we implement the design in Webflow, Framer or WordPress. For portals and web apps, the duration depends more on the processes than it does for websites. On implementation, our Web Development page describes that required integrations are defined in a technical concept before the build. Webflow is our focus, we also implement WordPress and other systems and advise neutrally. We build complete customer portals and web apps with login, roles and specialist data together with Vertion, our partner agency from the Webwavers group, which among other things takes care of the security concept. We clarify the scope for your portal in the initial conversation. More about our work for software companies is on the page IT, Software and SaaS. Want to talk about your portal? Use the contact page.

FAQ

Which UX/UI agencies also implement their design technically themselves for a B2B customer portal?

It depends on the scope. Many implement the interface themselves, while permissions, login, integrations and operations are a separate job. Ask every agency which part it builds itself and where it hands off to you or a technology partner, and have the split put in writing.

How do I design a portal with several roles so it stays clear?

Start with a role matrix: tasks, viewing rights and change rights per role. From it you derive the home page and navigation for each role, instead of building one interface for everyone. Test with three to four users per role.

Is it enough to hide functions that aren't allowed in the interface?

No. Permissions must be checked on the server. OWASP ranks Broken Access Control first in the Top 10 of 2021 and recommends denying everything by default except for public resources ("deny by default").

Can I build a password-protected customer area in Webflow?

Webflow discontinued the membership feature "User Accounts" on January 29, 2026 and recommends Outseta and Memberstack as alternatives. For simple protected content, an add-on service can be enough. For roles, specialist data and processes, you usually need standard software or a custom application.

Do I need SSO for my customer portal?

With business customers, often yes, because employees want to sign in with their employer's account. OpenID Connect is a widespread standard, SAML an older one. Which variant your customers need is something you clarify with their IT.

Does the Accessibility Strengthening Act apply to my B2B portal?

The BFSG covers services toward consumers. An offer that is actually aimed only at businesses is in principle not covered, and microenterprises are exempt for services. Classification in your specific case is a legal question. As a quality yardstick, WCAG still makes sense.

How many users do I need for a prototype test?

According to Nielsen Norman Group, about five users uncover roughly 85 percent of usability problems. With several user groups, three to four users per group is the guideline. Several small tests with revisions in between are better than one big one.

Conclusion

A good portal redesign starts with tasks and roles, enforces permissions server-side, tests early with users, builds a design system and plans the rollout like a project of its own. The decisive question for every agency is not "Do you do this from one source?" but "Who does what, and who operates it afterward?" If you want to take a first step today: create the role matrix and have three users demonstrate their most important task in the existing portal. You'll see right away where it gets stuck.

Sources

• OWASP Top 10:2021, A01 Broken Access Control
• OpenID Foundation, How OpenID Connect works
• FIDO Alliance, Passkeys
• W3C, Understanding SC 3.3.8 Accessible Authentication (Minimum)
• Nielsen Norman Group, 10 Usability Heuristics
• Nielsen Norman Group, Why You Only Need to Test with 5 Users
• Webflow Help, User Accounts sunset
• IHK Schwaben, Barrierefreiheitsstärkungsgesetz (Accessibility Strengthening Act)
• Art. 25 DSGVO (Art. 25 GDPR)
• Art. 28 DSGVO (Art. 28 GDPR)
• Art. 32 DSGVO (Art. 32 GDPR)
• § 43e BRAO, Gesetze im Internet
• § 62a StBerG, Gesetze im Internet
• Webwavers, Process
• Webwavers, UX/UI Design
• Webwavers, Web Development