COMPANY: PROGRESSIVE LEASING

Retail Dashboard

About the project

Progressive Leasing has a product called Store Portal. Store Portal helps our customers, the merchants, to create leases for their customers. The Store Portal is over 10 years old, outdated, and it has compliance problems. One of the problems it had was a single login for everyone in a store. This was a compliance issue on several levels. My team and I were tasked to create an MVP experience that would be compliant with the standards of the company. Retail Dashboard will eventually replace Store Portal.

My role and the team

The Retail Dashboard team was made up of a Product Triad but it’s more like a quad. The Triad included the Product Designer (PD), Product Manager (PM), the Lead Engineer. The fourth person in “triad” was the Delivery Manager. Let’s also not forget about the front end and back end Engineers that were under the Lead.

My role in the Triad was the Product Designer. As the PD, I worked very closely with the PM in the discovery phase. I was also in charge of the UI of the project. Lastly, I also kept in close communication with all of the engineers to make sure they understood the experience of the project.

The challenges

There were several challenges with this project. First of all Store Portal was a complete train wreck. It was over 10 years old and it had a lot of issues. It was designed by engineers that didn’t appreciate or understand the importance of UX. Retail Dashboard was in development for two years without any real accomplishments because it was at the bottom of the business priority list. There had been several designers that had worked on it over those two years who all had different views on what it should become.

When I took over Retail Dashboard it was finally prioritized as a major project for the company and upper management wanted fast results which was a challenge on its own. This specific project took 6 weeks. Each phase took 3 weeks.

Another problem was that this project was actually two projects in one. First, to meet compliance we needed to create an experience where each user had their own login. There needed to be structure, each user needed a role level and there needed to be a place where all these roles could be managed.

Next, there needed to be a place where all the users could be managed and new users could be added. We needed to connect the users with their designated stores. The MVP version would only cater to small to medium-sized retail stores but we also had to think about the future which included large stores such as Best Buy. The challenge is that the needs of the users were so different.

Other challenges came from the Covid-19 Pandemic of 2020. I had never worked remotely before so it took some adjustment. A new engineering team was assembled to do the work that was previously outsourced. It was a budget cut decision to discontinue outsourcing. I also had to deal with a broken laptop. Consequences of being a remote rookie.

The users

The most common user of this product would include Store Managers and Sales Associates. Other users that would potentially use Retail Dashboard would be Regional Managers, Human Resource Representatives, and the Owners/CEO’s of the company.

The range and level of the different types of users made it a challenge in this project. We detected early on that this would not be a cookie-cutter type of feature. A small one-off store would not have the same needs as a medium or large store. Every store has individual needs.

Design approach

My approach to every project is Human-Centered Design. I take many steps within each phase of the project. In the discovery phase, I like to work closely with the PM and Lead Engineer to assure the project is going in the right direction. In the design phase, I like to collaborate with other designers by asking for constant feedback. In the final phase, I like to gather all of the work I have done, I document it, and then I ship it for development.

Discovery

The discovery phase is the most important part of the project. This is when requirements are gathered, stakeholder and user interviews take place, sitemaps are created, and so on.

As my PM and I gathered requirements we very quickly realized this project needed to be broken down into two different sections. First would be roles and permissions and second would be the team page.

ROLES & PERMISSIONS

We decided to work on roles and permissions first because we needed to give structure to the users. We believed once we had structure we would be able to connect each user to an individual store and give them a role.

As we gathered requirements, we noticed a couple of things. Every business had its own needs. The mom and pop shops had a completely different structure from the medium-sized businesses. Whatever would work for one would not work for the other. As an example, the mom and pop shop would only have the business owner who also would act as the manager. They may or may not have an assistant manager. The rest of the employees would just be sales associates. One of those associates would maybe have higher level permissions. For a medium-sized business, they could have 50 stores. They would have regional managers, managers, assistant managers, HR reps, sales associates, and maybe other roles. Also, every business has its own language, so while one business says regional manager, another says area manager or district manager.

The big question was, how can we make this work for everyone.

Our solution was “simple”. Have the business create their own roles from a list of permissions. That way they could have two permission levels or 20 if they so desired. They could also name the permissions whatever they wanted. In the beginning, this approach was not received well by some leadership who thought it wasn’t the right approach. They thought we should just create all the roles with their specific permissions. We already knew this experience would not work for everyone. After several meetings and presenting what we had learned about our audience along with some persuasion, we were allowed to move forward.

My PM and I did a lot of interviews with stakeholders, engineers, and customers to figure all this out. I created sitemaps, did competitor analysis, performed design audits, and performed critique presentations.

TEAM PAGE

After having a structure in place we needed a platform where Managers could manage their employees. We decided to break the team page into three different sections. These included the employee list, the employee details, and the invitations.

The discovery for the team page was fairly simple. There was an older version a previous designer had created. The goal with this version was to make it better and to add features the previous version didn’t have.

For the employee list, I performed user interviews to identify what was important to the user. This information helped me decide the content of the columns in the list. I also performed some design audits to identify the best experience for a list. A challenge that came up with the list was the order of the employees. Some of the people on the team had the opinion of making the list alphabetical. I disagreed. I knew a small business would have no problem finding employees because the employee list would be small. This was not so in medium or large-sized businesses. There could be a business with 100 employees or more. This would make it more difficult to find an employee. I also knew the likelihood of going into the list to find an older employee would be low. A manager would most likely go to the list to modify the details of newer employees. So I thought we should make the list from new employees to old. This would avoid the need to use a search, sort columns, or use a filter. The new employees would just be at the top of the list.

The employee details section was a new feature of the team page. The biggest challenge with it was also a big challenge for the invitations. Being able to assign a location to an employee. Once again a small business would be easy because most likely they only had one location. Bigger businesses were a different story. A business like Mattress Dealz sometimes has Managers or employees that work in more than one location. Also, there could be many locations within a region. Structuring this to fit in a small modal was going to be a challenge. I created a sitemap and performed some design audits to get some ideas. Then I put a presentation together and showed it to some stakeholders and engineers. After some collaboration, we came up with a good solution. I communicated the most important part of this was to make it simple. We first wanted to see how the user would interact with it so we could learn and make it better later on.

My PM and I did a lot of interviews with stakeholders, engineers, and customers to figure all this out. I created sitemaps, did competitor analysis, performed design audits, and performed critique presentations.

UI and usability testing

At this point in the process, I took everything I had learned from the discovery phase and I started creating wireframes. I collaborated with several members of the design team by participating in design critiques and working sessions. Once all the wireframes were done, I presented them to the engineers so they could have a visual of what they were up against. I also gave them an opportunity to give me feedback and present any concerns they might have. Once I got to a comfortable spot with the wireframes, I developed a test plan and performed some usability tests. The goal of these tests was to identify any red flag with the experience.

Once the wireframing phase was done, I moved to high fidelity. I did some more collaboration with the design team to make the UI up to the team standards. I participated in many design critiques and working sessions to be able to end up with the final mocks. As I finalized the mocks, I created another test plan. This test plan would include more interactions and would have a more well-rounded experience. It would include unhappy paths in some of the interactions.

Overall the usability testing went well and there were no significant setbacks. The bigger focus of the project is to get it into the hand of our users and track every single movement with Google Analytics. We want to see how they use the MVP version so we can learn and make the appropriate adjustments.

Accessibility

Accessibility is a big focus at Progressive Leasing. We do a round of testing to make sure everything is accessible. We work off a design system that we constantly keep up to date. It makes it really easy to stay on top of it.

Lessons learned

I learned a lot from this project. First and foremost, with the pandemic, I learned how to work with a team remotely. I learned how to manage my time better and not get distracted at home. Since I was unable to whiteboard with the people on my team I figured out alternatives like using Mural or making Zoom calls instead.

I learned that not everyone is on the same page. Upper management was not as deeply involved in the project as I was. It was my job to remind them of the goals of the project. It was my job to show them what we had learned in the discovery phase and that we were going in the right direction.

I learned the importance of saying no. This was difficult for me to do at first. I’m more of a people pleaser and I’m competitive. I want to show my value and that I can perform at a really high level. At the beginning of this project, people wanted me to do all of this work in two to three weeks. My nature was to say yes, let's do it! After having a conversation with my design lead, I realized this would not be possible. He shared an experience he had in his career which I took to heart. I talked to my PM and told her each phase of the project would take two to three weeks. I explained to her the approach I wanted to take and why it would take that long. She saw that it was reasonable and two to three weeks for each phase would still be a good timeline.