Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
As a wrap-up, let's consider a few best practices when designing user roles. Keep it simple, provide pre-defined roles, be transparent, and lastly, consider if a separate product is needed.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Now, let's take a step back and
consider the best practices for
0:00
defining user roles.
0:04
As a user experience designer,
0:06
you'll be a key voice in deciding
what user roles are needed.
0:08
Here are a few tips.
0:12
Keep it simple, provide predefined roles,
be transparent.
0:14
And lastly,
consider if a separate product is needed.
0:19
Let's delve into that first point.
0:23
Keep it simple.
0:26
Try to keep it to two to three user roles.
0:27
Don't overdo it by adding too many user
roles with granular permission settings.
0:30
It'll get confusing for everyone involved.
0:36
Make sure the product truly needs
complexity before going that route,
0:40
which leads me to my second tip.
0:45
Provide predefined user roles, as opposed
to relying on users to build their own.
0:47
Interview the customers and tweak as
necessary based on what's working and
0:53
not working.
0:58
Predefined user roles allow
users to get going without
1:00
overthinking the permission settings.
1:03
They're also easier to maintain and
support.
1:06
If you allow users to create their
own permission settings, and
1:10
they run into a problem,
1:14
it can be a headache when the support team
tries to detangle a user error from a bug.
1:16
It can also create
a complicated audit trail,
1:21
which is particularly an issue for
financial products.
1:24
That said, there are edge cases.
1:29
Some products serve a broad range
of businesses with different needs.
1:31
In that case, giving users the control
to edit user roles can be a big win.
1:36
An example of this is Amazon Web Services,
also known as AWS.
1:43
It's a large cloud platform with
dozens of products built on top of it,
1:49
such as cloud storage and databases.
1:53
Their permission settings
are highly configurable,
1:56
enabling you to allow and
deny access levels with precision.
1:59
Permissions are set in a part of their
app called IAM, which stands for
2:04
Identity and Access Management.
2:08
There, you can create policies.
2:11
For instance, I can choose the service S3,
which is a cloud storage service.
2:13
Then in the Actions panel, I can select
the access levels, such as view only,
2:21
or the ability to also write or
change a file.
2:26
The Resources tab allows me to constrict
access within a certain part of
2:31
the product, such as a specific bucket or
folder on S3.
2:35
But I'll just select All resources for
now.
2:40
Then I can specify a conditional such
as a Source IP, which will allow access
2:44
only when the request comes from
the specified IP address range.
2:49
After setting up this policy, I can apply
it to a role, such as the one shown here.
2:56
That's where the policy gets
applied to actual end users.
3:01
Anyway, like I said, this example is
far on the spectrum of complexity
3:05
when it comes to configurable user roles.
3:10
Most products don't require
this level of configuration.
3:13
The next best practice is
to provide transparency.
3:18
Make permissions easy to understand for
3:22
the admin assigning the permissions and
for the basic user.
3:25
Keep everyone informed of their user
role and what they can and cannot do.
3:29
It can be frustrating as an end user
if it's unclear what access they have.
3:35
Make it clear who is the admin, who can
provide them access if they need it.
3:41
The project management tool Asana
is a great example of this.
3:46
As a final note,
consider if a separate app is needed.
3:54
If the user roles are very disparate,
3:58
an entirely different app
may need to be created.
4:00
For example, Lyft has an app for
riders and an app for drivers.
4:04
In the consumer-facing app,
riders can request a ride and pay.
4:11
In the app for drivers,
people can sign up to be a driver,
4:16
find rides to accept,
see the best times to drive, and cash out.
4:20
Looking back at the Slack example,
4:26
there's plenty of common
content between the user roles.
4:29
For example, all users can chat,
read messages in the general channel,
4:32
leave emojis under comments, and so on.
4:38
But for Lyft, there's actually only a bit
of content in common between the rider and
4:41
driver view.
4:47
Lyft could have created a single
app to serve drivers and riders.
4:49
But it would have been confusing to
build a single app that solves two very
4:53
different sets of goals.
4:57
So, in cases like these,
it makes sense to create separate apps.
4:59
That concludes this overview
of designing for user roles.
5:05
As you work on your next project,
consider how different types of users
5:09
may benefit from having a unique
experience based on their goals and needs.
5:13
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up