This post is the second in a series about building portals for teams and groups to interact with customers. If you’re interested in reading more please follow us on twitter or subscribe in the right-hand margin of this blog —>
Whenever I see a problem or hear a solution I love working it backward. I think it’s why I loved consulting. I think it’s the inner 3-year-old in me who just loves to ask “why” until someone goes bonkers.
So why do we have web portals to teams, departments and companies?
Easy! So our customers and partners can connect with us.
So that they can get what they want, how they want to get it!
To make it easier to deliver it to them!
So they can be happy and we can be happy.
And that’s good enough for me – don’t get me started on the four types of happiness, but this basically is the goal. Keep people happy.
This brings me to the most overlooked part of every technology project: the people.
You basically have three main customer groups for every portal. The user, the provider and the provider’s partners. And each of these three categories have a TON unique characteristics. From competency to goals there are many misconceptions and assumptions that can be made of the user. There are also universal givens that can be applied since they are people and they are using the portal.
Now’s where the general basics kick in. Most people want (in all three groups):
These universal desires were stolen from an article I read about libraries. LOL. But they are fundamental elements of humans search for solutions and information; things that will make them happy in the moment they are using your portal.
Since your team is unique and provides a unique service or product – I can’t provide much more advice than these very general keys.
For instance, if you’re a hospital exposing self-service check ins #3 is probably more important than #5. And if you’re an IT shop numbers 1 and 2 are probably more important than 5.
And this is where your challenge starts. Understanding the users – ALL the users. From the customer, to the people on the queues to the people they pass the work to. Each of them wants to be heard and influence the design and execution of the portal.
This doesn’t mean you can take each person’s input into consideration. Group consensus doesn’t really work that way. Instead, you must use this information as research into the design.
If you’re not into design or have experience with this – it’s bigger than a blog post. I can’t give you all that with some words. It really comes from understanding design. If you’re not ready to learn about user research and design – I highly recommend hiring someone with the experience. It is invaluably successful.