Although our client already had a plan to develop four features, we still need to think about it systematically. And we tried to find out how these features should be organized together and what were the hidden problems.

After doing initial researches on similar SaaS tools, we found that we were not only facing some common challenges of SaaS tools, but also some particular challenges of this customized product.

Here were four main challenges we were facing:

SmartX Partner Portal would be used by both internal users (sales team) and external users (partners). These two kinds of users played different roles in the product, they had different permissions and user flows.

Inside the sales team, there were multiple hierarchies. The team was divided into several departments and sections based on industries and locations. We needed to bring these hierarchies on the web app. By doing that, managers could able to check projects and manage members by departments; leaders also could visit projects belong to their subordinate staff.

Here were the specific requirements about permissions:

• All accounts should be created and managed by head of sales team.
• Members and projects should be organized by departments;
• The managers of a department could visit projects belong to department members.
• Leaders could visit projects belong to their subordinate staff.
• The head of sales could visit logs and projects of all members.
• The permission of partners were limited, they couldn't visit some internal features.

There were four modules about above features. Besides that, there were other fundamental modules, such as account, notification, profile module, etc.

With the involvement of different roles, the product's complexity increased enormously. For example, different roles would have different user flows and interfaces under the same feature.

A project contained lots of data, and more data would be generated when this project being modified or updated.

These data generated on the application were seriously important for client, they had a high standard about keeping these data:

• Each action of members and partners should be recorded.
• Each change to a project should be recorded in order to track or rollback.
• Data should be backed up every day.

Each project would involve at least two members. For example, distributors submitted a business opportunity to the sales team, then one member at sales team will follow up.

The status of a project would be changed frequently, when this happened, everyone related to this project should be notified so that they could take actions immediately. Notification is also a fundamental function to make the system work smoothly and seamlessly.

Understanding problems is the prerequisite of finding solutions, and we started from understanding users and brand.

The product would be used by both internal users and external users. After making several calls with client, we made a list about all the roles involved in and their permissions. The list included distributors, sales, managers of each department and employees who had resigned.

Then we started to do some researches about client's brand by visiting their website and getting hands on their products. We tried to figure out the "feeling" they want to express through the product. After we had a conversation with head of sales about their thoughts on the product's "style", we knew we were going to design a clean but professional product, also aligned with SmartX brand.

After gathering enough information we need, we started to analyze them and turned them into insights. We chose online collaboration document and invited client to join in. By doing that, we could get immediate feedback from them and avoid mistakes.

We had 3 main outcomes in this step: PRD, User flows of main features and a list of all pages I need to design later.

Finally, we entered the design part. In this step, I worked on exploring visual styles and interaction design pattern.

I designed some concept pages and components of the product and I categorized them into different solutions. Then I built simple prototypes on Invision and share these solutions with clients.

After few rounds of iteration, we knew our design direction.

Setting up accounts was the first step of building the product. Considering the efficiency of manage members and receive notifications, we chose the work email as the login method. All accounts would be created and managed by the administrator.

• Administrator account: Created by default, assigned to the head of sales.
• Team members' accounts: Created by the administrator. After adding a member's email into the system, he/she would receive an email, then he/she can setting up password by clicking the URL in the email.
• Partners' accounts: Partners chose an employee as the contact, then administrator would add the contact's work email into the system.

After setting up accounts of different roles, we needed to consider the design of permissions. We untangled this complex problem in these following steps:

After solving the challenge of accounts and permissions, we began to set up the information architecture for the product.

The main job of this step was designing the navigation. We had several design exploration before, and we gathered some feedback from our client. Considering the scenarios of different roles using the product, we chose the most intuitive and flexible one.

Then we started to design specific feature modules based on the page list I made before. We set up priority for each module. I designed them from high priority to low. When a module was finished, I would share this part with client and developers, ask for their feedback. Then I would fix in the next update. If everyone had no more questions about this part, developers would start to code.

In this way, we can communicate effectively and avoid hidden risks.

In order to track every change happens in the system, we divided the log into two categories: project's log and user's log.

A user's log tracked all the behaviors of this user on the product.

A project's log tracked all changes happen to this project, it usually involved multiple users.

Every piece of log would contain these elements: People, Action, Object(Content), Time. I listed all the log events that needed to be tracked and copy for these events.

Notification was one of the fundamental function of the product. It played a very important role throughout the product. In some way, notification could determine the effectiveness of entire workflow.

We spent a lot of time on designing the form and content of notifications:

• Listed all kinds of notifications on Paper, each notification would contain these elements: Action, Target user, Notification method and copy.
• Prioritized all the notifications and chose the right way to send notifications.
• Wrote copy for each notification.

In order to ensure important notifications won't be missed, we decided to send notifications through these 3 ways.

Although our client already had a plan to develop four features, we still need to think about it systematically. And we tried to find out how these features should be organized together and what were the hidden problems.

After doing initial researches on similar SaaS tools, we found that we were not only facing some common challenges of SaaS tools, but also some particular challenges of this customized product.

Here were four main challenges we were facing:

SmartX Partner Portal would be used by both internal users (sales team) and external users (partners). These two kinds of users played different roles in the product, they had different permissions and user flows.

Inside the sales team, there were multiple hierarchies. The team was divided into several departments and sections based on industries and locations. We needed to bring these hierarchies on the web app. By doing that, managers could able to check projects and manage members by departments; leaders also could visit projects belong to their subordinate staff.

Here were the specific requirements about permissions:

• All accounts should be created and managed by head of sales team.
• Members and projects should be organized by departments;
• The managers of a department could visit projects belong to department members.
• Leaders could visit projects belong to their subordinate staff.
• The head of sales could visit logs and projects of all members.
• The permission of partners were limited, they couldn't visit some internal features.

There were four modules about above features. Besides that, there were other fundamental modules, such as account, notification, profile module, etc.

With the involvement of different roles, the product's complexity increased enormously. For example, different roles would have different user flows and interfaces under the same feature.

A project contained lots of data, and more data would be generated when this project being modified or updated.

These data generated on the application were seriously important for client, they had a high standard about keeping these data:

• Each action of members and partners should be recorded.
• Each change to a project should be recorded in order to track or rollback.
• Data should be backed up every day.

Each project would involve at least two members. For example, distributors submitted a business opportunity to the sales team, then one member at sales team will follow up.

The status of a project would be changed frequently, when this happened, everyone related to this project should be notified so that they could take actions immediately. Notification is also a fundamental function to make the system work smoothly and seamlessly.

Understanding problems is the prerequisite of finding solutions, and we started from understanding users and brand.

The product would be used by both internal users and external users. After making several calls with client, we made a list about all the roles involved in and their permissions. The list included distributors, sales, managers of each department and employees who had resigned.

Then we started to do some researches about client's brand by visiting their website and getting hands on their products. We tried to figure out the "feeling" they want to express through the product. After we had a conversation with head of sales about their thoughts on the product's "style", we knew we were going to design a clean but professional product, also aligned with SmartX brand.

After gathering enough information we need, we started to analyze them and turned them into insights. We chose online collaboration document and invited client to join in. By doing that, we could get immediate feedback from them and avoid mistakes.

We had 3 main outcomes in this step: PRD, User flows of main features and a list of all pages I need to design later.

Finally, we entered the design part. In this step, I worked on exploring visual styles and interaction design pattern.

I designed some concept pages and components of the product and I categorized them into different solutions. Then I built simple prototypes on Invision and share these solutions with clients.

After few rounds of iteration, we knew our design direction.

Setting up accounts was the first step of building the product. Considering the efficiency of manage members and receive notifications, we chose the work email as the login method. All accounts would be created and managed by the administrator.

• Administrator account: Created by default, assigned to the head of sales.
• Team members' accounts: Created by the administrator. After adding a member's email into the system, he/she would receive an email, then he/she can setting up password by clicking the URL in the email.
• Partners' accounts: Partners chose an employee as the contact, then administrator would add the contact's work email into the system.

After setting up accounts of different roles, we needed to consider the design of permissions. We untangled this complex problem in these following steps:

After solving the challenge of accounts and permissions, we began to set up the information architecture for the product.

The main job of this step was designing the navigation. We had several design exploration before, and we gathered some feedback from our client. Considering the scenarios of different roles using the product, we chose the most intuitive and flexible one.

Then we started to design specific feature modules based on the page list I made before. We set up priority for each module. I designed them from high priority to low. When a module was finished, I would share this part with client and developers, ask for their feedback. Then I would fix in the next update. If everyone had no more questions about this part, developers would start to code.

In this way, we can communicate effectively and avoid hidden risks.

In order to track every change happens in the system, we divided the log into two categories: project's log and user's log.

A user's log tracked all the behaviors of this user on the product.

A project's log tracked all changes happen to this project, it usually involved multiple users.

Every piece of log would contain these elements: People, Action, Object(Content), Time. I listed all the log events that needed to be tracked and copy for these events.

Notification was one of the fundamental function of the product. It played a very important role throughout the product. In some way, notification could determine the effectiveness of entire workflow.

We spent a lot of time on designing the form and content of notifications:

• Listed all kinds of notifications on Paper, each notification would contain these elements: Action, Target user, Notification method and copy.
• Prioritized all the notifications and chose the right way to send notifications.
• Wrote copy for each notification.

In order to ensure important notifications won't be missed, we decided to send notifications through these 3 ways.