Best Practices5:18 with Hope Armstrong
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.
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 up