Bummer! You have been redirected as the page you requested could not be found.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Designing for User Roles!
You have completed Designing for User Roles!
Preview
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