How To Use Portals To Jack Up Your UX Level
Portals are peculiar systems. They come in all sizes and shapes. A lot are done badly and are based on false assumptions about what users need. Some are out of the box solutions and some are custom build. In a complex ecosystem of applications and services, a well crafted portal could seriously increase the experience for your users. It can cover up the bad UX decisions in systems and become a tool to change workflows and mindsets.
The early days of portals
Portal are old. They have been with us since the beginning of the Internet. Before there was Search, a portal was the way to discover websites on the Web. In the old days a portal was nothing more than a curated set of links. But for most people it was the place where you started your journey on the Internet. In the 1990s a portal was a way to control what sites people visited. A lot of people used it as their homepage to go online. When Google came along, the importance of portals was greatly reduced. But still today companies like Yahoo use a portal as their homepage. In a sense the Google homepage is also a portal, but it uses a totally different metaphor, the user experience is totally different.
Personal portals
In a sense the Medium homepage is also a portal into the world of Medium posts. It shows you what Medium thinks might interests you. This is based on what you have read before, what you liked and what others like. The goal is to keep you as engaged as possible. It’s a personalized collection of links generated by an algorithm. The same goes for platforms like YouTube or Spotify. These modern portals use data, algorithms and machine learning to build up personal portals. In the era between the first portals on the internet and these modern portals, there was a time when portal designers thought that users might want to personalize their portals themselves. They gave them options to turn on and off various portlets and even allowed them to change the color schemes. It turned out that hardly anyone ever used these features and most portals dropped these options. The problem with data driven personalization is the first use period. If you have no behavior data, you have nothing to work with. Most applications that have portal-like functions use some form of on-boarding forms to ask the user a couple of short questions to have some first data points to work with.
Corporate portals
Most large corporations use portals. Most probably call it the Intranet. It’s usually a collection of links to systems you can use. It will also contain some internal news feed, ways to connect to colleagues and some kinds of KPI metrics. If you use a out of the box application it will have lots of widgets and portlets you can install and configure. Mostly I see these systems being owned by internal communication departments. The combination of too much technology push from alle the widgets and the problematic role intranets play in the strategic goals of internal communication departments usually does not result in great user experiences. Because people are practically obliged to use them, there is also no high sense of urgency to up the UX levels.
Portals and micro services
The service an organization delivers typically consists of a collection of smaller services. Each of these services can be developed, maintained and delivered by different teams. In a micro services IT architecture the teams have and end-to-end responsibility for those micro services. They can also use different IT systems to deliver the service. For the end user these services have to come together somewhere. They have to work together in the end. This is where the service portal comes in. Some services can be delivered directly in the portal, while other services just have a dashboard view on the information but require using a different application to perform the tasks of the service. Modern websites and applications are in a sense portals to multiple services. If you look at a website like Coolblue or Zalando, they are build up of multiple small services that come together on one page. Finding products, customer service, recommendations, sales, user feedback, social, customer relationship management, security, logistics etc. all come together on one page.
These views all link to different services like the customer service portal or, when you want to order, to external payment services like iDeal.
You see in the Coolblue example that not all services are fully integrated. For the payments they use systems that open a new application outside the Coolblue that is in a totally different style and requires accounts from third parties. Users are used to this stepping outside the world of Coolblue and after the payment getting back. But this is a choice. There are also companies that offer a fully integrated payment system. Apple for instance has a fully seamless payment experience in which you never leave the Apple universe.
Levels of integration of services
What you see from these examples is that there are different levels of integration possible for the services you want to offer in your service portal. There are seven levels of integration of services in a portal:
- Linking: you just link to other services, information or systems that your user can use to perform the tasks they need to perform. The service you deliver here is saving people time and maybe explaining the system to which you link.
- Theming: if the systems you link to have the same interface as the portal, the user thinks he is still using the same service. This will reduce cognitive load and make it more enjoyable to use your services.
- Single Sign On: if you link to other services you can set up a system that will allow your users to be automatically logged in to the systems you link to. This way users just have to log in once, just have to have one account. This is very convenient.
- Deep linking: if you have Single Sign On (SSO) in place, you can send your users to a specific location in the service you link to. This way they won’t arrive on a general homepage of the service in which they have to find the thing they are looking for all over again. This saves time and energy.
- Dashboard: the next level of integration is showing some of the data from the service. This wat users don’t have to go to the specific system if there is no need. From the information on the dashboard they can see if there is any action required.
- Perform tasks: one step further is allowing the user to perform tasks in other systems through your portal. If you can read and write to the service, you can allow the user to perform tasks without accessing the back-end services. This is easier with simple tasks, but if you have to rebuild entire interactions it’s mostly wiser to use the interactions of the back-end service.
- Personalization: if you know exactly what your users need, you can offer them the right service, the right information at the right time. Just-in-time service delivery is about knowing what your user needs when. If you just have the information you need and the time that you need it, this greatly enhances your service. As a back-up you might need to offer links to the complete information and service for the cases the user needs something else.
Why portals work
One of the reasons portals can work well for your UX is that most out of the box applications suffer from bad UX. They generally offer to many features and are designed for too general use. They are unable to tailor to very specific needs for your situation and your users. They are also notoriously hard to theme for a unified, seamless experience. If you can rebuild a part of the interactions in your portal, you can still use the other powers of the system but with a different interface. You always have the back up of the system for really specific tasks that a user only incidentally uses. If you can design and control these services yourself like Coolblue, you can easily create a seamless experience. But even they choose to link to an external payment system. Sometimes this offers a better user experience than full integration like Apple does because the Creditcard-only policy creates a hurdle for users that doesn’t outweigh the benefit of full integration.
There are also more and more application developers that tailor specific to the fact that they are being used to created larger, connected services. Through APIs you can connect services easily. Services like AirBnB and Uber use a whole technology stack to build up their services. Most of the services they use are third party and available to anyone. They connect all these services and technologies in one service portal. Most of these services are intentionally headless, designed to work in other systems.
The alternative
If you don’t want to use a portal architecture for your services, the alternative is an ecosystem of services. This is the way Google is set up. Google offers multiple services that stand alone and have varying levels of integration. The whole suite consists of services like Mail, Maps, Search, Drive, Chat, Documents etc. The challenge here is to create cohesion between all these services. They have value on their own, but for users and for the company the experience is enhanced if it’s one suite. This works if the services are built for specific tasks and don’t require too much integration to offer a service to the user. With Google it’s not like you expect one service from them like you do from Coolblue. If Coolblue would be set up in multiple services like Search, Payments, Mail, Logistics etc this would not work. They are going for a seamless experience with one mindset and one flow. The Google alternative is aimed at supporting different tasks at different times that might have some links to each other. It doesn’t use data and functions from different systems to create one service.
If you choose to go for the ecosystem of apps strategy, you need to invest in the coherence. What companies like Google, Microsoft and IBM are doing right now is invest heavily in design. Design can play a huge role in creating coherence, the idea that it’s one connected suite of applications. Design principles, rules, templates etc like Google’s Material Design are created for this very purpose: to create unity for the users. This makes it easier for users to learn and use different apps from the suite and creates the mindset that they are connectable. When you build all your own applications like Google, this is already hard, but if you rely on third party apps, creating unity is even harder.
The other solution is education and agreement. In a modern working environment where you use Adobe apps to design, Microsoft apps to write, Atlassian apps to manage projects, Slack and Google apps to communicate, Git to manage code etc, you have to know what you are doing. You have to know your tools, how they work. You have to agree how and why you use certain tools and agree on similar workflows and systems. If you can educate and agree, there is no need for a service portal.
Choices to be made
The question is if a portal is the way to go if you want to enhance the UX level of you service.
You don’t want a portal if:
- If everybody knows what they have to do,
- everybody agrees on the toolset,
- the UX of the tools are good enough,
- everybody agrees on the use of it,
- if the tasks are complex and
- there is no need for dashboard-like overviews.
But in many cases you cannot educate the users, it’s impossible to get everyone to agree on the tools and their use, the tasks are not that complex and an overview based on data from multiple systems is the basis of your service. In those cases a portal can do wonders. It can not only enhance the UX, it can create the right mindset, seduce people to agree and move people to work and organize themselves in a different way.
There are multiple levels of integration of the services you want to combine. Choosing the right integration for each user task is a viability discussion that should be held with all stakeholders. Developing a service typically consists of iterations, continuous improvement. So the choices you make in the beginning should be in line with your ambition, but also be flexible enough to accommodate new insights. The different levels of integration give you the room to play that you need to continuously improve your service/UX level and decide on MVPs. For each part of the service you can choose on of the integrations. And in each iteration you can move up one level. It’s all about deciding what is the most valuable part of your service, what is the core and what paths you can create to continuously improve it. Each move up the ladder cost time, energy and money and you should make a business case for each and validate with all stakeholders. But not each move up the ladder costs the same. If services are headless and built with good APIs, the costs of moving higher up the ladder are lower. So choosing the applications you use and the architecture has impact on the costs of moving up a step on the UX ladder.
If you want to know more about the levels of UX, you can read this:
