This past month I had the exciting opportunity to lead a project with Femmecubator’s team of volunteer UX Designers. Femmecubator is a community that emboldens and supports women of color who are transitioning into the tech industry by providing them mentorship opportunities and resources.
The organization is currently working on building a mentor matching platform and has become lost in feature creep. I joined the company to help design their Account/Profile Settings page and Onboarding process. I ended up helping pair down their product to the core MVP features so they can begin user testing and have a working product by the end of the year.
While I had my hands on a couple of parts of the platform this case study is about the design process for their Account/Profile Settings Page.
Here’s the problem
How might we provide a page that allows users to easily and efficiently customize their account settings and profile information?
We worked in Agile and Lean UX
Femmecubator’s UX Design team consisted of 3 Volunteer Designers and a Lead Designer. Each designer led the design of a section of the web application and then reported back to the Lead Designer. I, as a Volunteer Designer, led the Profile/Account Settings and Onboarding process.
Originally the process was simple. Conduct competitive analysis, study the user insights we’ve already collected, consider user scenarios, prioritize features, sketch out some ideas, design critiques, create the final mockup for the Developers to build out, and then test. We worked in a Lean UX Process so at each step we had the Design and Dev team involved for quick feedback.
Unfortunately, and fortunately, the process was interrupted by a major pivot. But first here is how far I got before the interruption.
The Competitive Analysis
I chose to look at the account pages of Linkedin, Dribbble, Upwork, and Dev.to to understand how our competitors and other companies in the industry approach the organization of their settings information. Our team wanted a simple yet functional design that allowed users to easily access their account settings and information without any excess features.
Linkedin made me realize that our profile information does not need to live in our settings. Instead, it could be easily editable from the user’s profile view. We eventually chose to go with a similar solution.
Dribbble, Upwork, and Dev.to all provided great examples of how to display information in a simplistic way that did not distract from the functionality of the page.
I then chose to also take a look at some companies outside of our industry that had similar basic functions to our web app.
Pinterest was fun to look at and gave us some insights on how to ask for sensitive information like gender identification.
ZocDoc did not provide much new information for organizing the account settings, however, it was one of the inspirations that sparked the interruption. More on that to come. ;)
3 User scenarios for the Account Settings
When creating sketches for the Account Settings page I thought about how and why the user would access these pages. The account settings wouldn’t be accessed immediately after signing up for an account. They are usually accessed after the user has engaged with the platform for some time and want to change their settings to customize the user experience of the platform.
These are three user scenarios I thought of when considering why a user would want to access the account pages. When designing the account pages, I made sure to run through each user scenario and ensure that they were easily accomplishable.
- User wants to change their password for security reasons.
- User wants to update their bio information.
- User wants to change their membership status.
Feature prioritization for the MVP
Because the team is building an MVP, I wanted to keep the Account/Profile Settings to the most minimal number of features while still be functional for the launch. Here are the features I prioritized after a short brainstorming session. Some were reprioritized after the first iteration of the designs.
I drew up quick sketches for design critiques, once finalized I then designed the mockups.
I realized very early on that in this fast-paced environment where the team wanted updates every few days, I preferred to sketch out my designs on my iPad instead of designing wireframes for feedback.
This was the first sketch I drew up for the team to critique. I considered adding a Documents page to edit materials and links that users may want to add.
I also made a suggestion to add an inbox to the header because of feature creep that was happening in the Calendar section of the web app that had a chat function.
This was the final sketch version of the Account/Profile Settings page. I reorganized the information in the Account and Profile pages and completely removed features for the Documents Page. The team agreed that the features for the Documents Page would be added on in a later version. The design was severely paired down and the team ran through our user scenarios to ensure it worked. Everything was going according to plan.
I’d like to point out here, as I mentioned earlier, the approach to asking for gender identification information was inspired by Pinterest’s account settings page. It was a feature the client wanted in order to collect demographic information about our users. I provided a multiple-choice form fill for the user to choose to provide their own preferred gender identity.
Once my lo-fi sketches were approved by the Design Lead and Dev team, I got to work on mockups.
As I was working on mockups for the in-between stages of each user experience, everything ground to a halt. We had to make a pivot!
The Great Interruption: Redetermining MVP Features for the entire product
One evening after a meeting with the developers about the Onboarding process, another project I was working on at the time, I realized that both the Design and Development teams were not on the same page about what should be in the MVP of the overall product. I spoke with the Design Lead and we agreed to set up a meeting to finalize the MVP features. We were going back to square one!
Before this meeting, from my own experience in building MVPs, I drew up a potential solution.
I reorganized the structure of the web app and provided a complete breakdown of our MVP features. We built up from there.
The original product we were building had a calendar system that was suffering from major feature creep. It was slowly becoming a dashboard even though it was meant to simply help the user keep track of and schedule meetings with their mentor.
I looked at all the main features we had and reorganized them into four parts — the directory, the dashboard, settings, and onboarding. The calendar was moved to be integrated with the directory, and all those other features that crept up were organized into a dashboard that also acted as a public profile for the user. It might sound complicated but it actually simplified the entire structure of the site. For a detailed breakdown, you can check out my full notes here.
This solution was inspired by ZocDoc’s organization of their information architecture. They also had a booking feature but for doctors. I found that the way they integrated their scheduler made a lot more sense than a calendar and their simple dashboard allowed for users to manage their appointments without any fuss.
During the meeting, I discussed my solution and looked for feedback and opinions from the other team members. We agreed to build upon my solution and conduct an affinity map for just the dashboard. This was because the dashboard was the new unexplored feature and we wanted to simplify it as much as possible to include only the absolutely necessary features.
An Affinity and MoSCoW map was perfect to help brainstorm user scenarios and prioritize solutions. Here’s what the Design team came up with for the Dashboard.
The Final Results
So what happened after all the reorganizing and what do the Account Settings look like now? Well, I offered that we moved profile editing out of Settings and into the Dashboard.
Now, when a user is logged in they can edit their information directly from their Dashboard instead of looking for a hidden settings page. This allowed for easy accessibility and simplicity to the user experience.
The Account Settings Page now only includes three features — Email, Password Change, and Membership Status Change.
I conducted some more competitive analysis looking to understand how I can present such little information in a clear yet interesting way. I came across Substack’s account page which became the inspiration for my design.
For the UI, I adhered to an already established Style Guide developed by our Design Lead. The organization uses Material Design IO as our design system and so I utilized their Chip design for our Membership Status Change feature. This was decided on during a design critique with my Design Lead.
In this mockup from the Mentee’s perspective, ‘Mentor’ is grayed out. When the user wants to change their status to become a Mentor, they can click on the chip which will activate a pop-up modal that provides the Mentor application form.
Overall, designs were kept minimalistic for easy development of the MVP.
What did I learn?
Where this project ended up surprised me. With my experience building MVPs I instinctively like to find the simplest solution to things. Although I originally approached the design of the Account Settings with simplicity in mind, I didn’t consider that the other moving parts of the web app would provide an even simpler solution.
My two main takeaways were:
- The Design and Dev team needs to be on the same page about what features are prioritized during any phase of the product’s development. And they need to stick to them to avoid feature creep!
- Don’t just look for solutions externally. Solutions may come internally from your own product.
What’s next?
The next steps for the team would be to conduct some usability tests for the Account Settings page and the Dashboard. I will share our insights in an update to this article once we complete them!
