Team of Engineers, Head of Product, Product Designer, Community Success Team
Forem is open-source software for building modern and independent communities for developers, peers, customers, and users. Forem is already powering communities that serve over 10 million monthly unique visitors.
Member list view is part of the admin area where admins can have a list of their community members. This looks like a pretty straightforward project, but there was lots of back-and-forth designing this.
⚠️ Unclear three tabs at the top People usually miss those tabs at the top because of the hierarchical issues.
⚠️ Simple filtering Based on the current implementation, you could filter by one role only. Every community has roles like admin, super admin, moderator, etc. The problem was you could filter by role, but there was no indicator or value of that role in the table. How would you identify it?
⚠️ Outdated design language and absence of data in the table The implementation looks very basic. A lot of information is significant for this table, like the members’ status. For such information, the admin had to go inside the member detail view to check, which is very time-consuming and not intuitive.
At the same time, some information is redundant, like ID here.
⚠️ No actions You can not perform any member-related action from this view. Like sending an email, add not or add/remove the role.
⚠️ Time-consuming invitation flow As you can see in the current invite method, you must write your name and email to invite any member. And you can request one member at a time.
Forem is used to build the DEV community, so our organization is a mix of the DEV and Forem teams. So we had our team who would interact with these screens, so we decided not to go for user testing this time.
Our team was excited to try these new features and test them out. They are also very keen on sharing their issues and ideas with us, which helps us get to the right solution.
The conversation started with what information is essential for admins to have in this list view. Tables are always simple yet complicated. It depends on how you use that space.
I listed out some essential information that needs to be displayed. Those were status, list of organizations, roles, last activity, and joined date.
After that, we start iterating on how to make this list view more useful. For example, what member actions can we take from here? So, our Head of Product (Jennie) asked the team for suggestions on what member actions they would want here.
This is where we ended up. Lots of great ideas and insights. From this chat with the team, we can get the idea of bulk actions, such as assigning multiple people roles, Changing their status, etc.
This would save significant time for our team, where they have to go to individual member profiles and perform actions.
So, we had a few action items in place.