7 problems in the design of SaaS products, and how we solved them
The mission of the TrackDuck team is to simplify the process of developing any web projects. We understand how important reliable communication and understanding between the customer and the contractor in the development process. Our project is almost 1.5 years old, but we feel that we are really just starting to work on it. And he, like any good service, constantly needs improvements. If you are interested in our experience - welcome under the cat !
')
Any developer knows his product many times better than any user, and this can lead to a misunderstanding between them. A good developer always tries to look at what he does with the eyes of his user, but he does not always succeed.
Any developer will have thoughts about reworking the web project interface if:
In any case, sooner or later the developer understands that something is not working as expected for the customers, or the process is not thought out in principle. And that means it's time to improve something!
In fact, TrackDuck , like any project, consists of several separate parts and we try to organically combine them in the product that we offer to our users:
All this should be clear and accessible to users at any time. The project should work on various platforms and devices, from mobile to tv-monitors. Below we will discuss the seven problems that we faced during the last year of product development, and the way we solved them:
In the first version of the service, we used the space at the top of the page to navigate through the key functions of the service and user projects, but over time we became convinced that this path is not very good for several reasons:
In our case, the advantages of the sidebar are obvious. Its use allows to divide the application well into zones, each of which will be associated with its functional part of the application. In addition, the right menu with a list of projects is hidden when there is no need for it, which makes it possible to more effectively use the space on the device screen.
The process of creating separate applications for mobile platforms is almost always associated with additional costs for the development and support of individual native applications for various platforms, the project does not always have these resources at an early stage. Based on this and from the received requests, including from our commercial clients who wanted to get access to our service on mobile devices as early as possible, we decided to make our control panel adaptive. The organization of the interface with vertical blocks allowed to do this with minimal cost. We used Media Queries, ngTouch, matchmedia-ng. We added the necessary styles and scripts for the main elements and now our application works almost everywhere:
In addition, our interface with a vertical separation of information representation areas allows us to focus the attention of customers on the part of the product with which they are currently working, allowing you to hide unused ones.
We carefully analyze the metrics of using various functions of our project and listen to user comments. We also try to identify the underused functionality of the project, the support of which is inappropriate, and add new functionality that allows us to solve the tasks of our clients more efficiently. The biggest problem with this is to keep the layout of the elements familiar to our customers, test the new functionality on the control group before its total implementation, and effectively notify users of the emergence of new functions and work with them. Onboarding successfully copes with some of these problems (we specifically design it so that when adding something interesting to our project, the new functionality does not go unnoticed)
Icons and icons greatly facilitate the work with the interface. Surely many of those involved in interface design are familiar with a great book : - The key point is not to make people read. We combine recognizable icons with captions to all key interface elements of our system. Very often we forgot to change the type of the cursor on special elements, we had to rework the inline text fields several times:
Also very often we were mistaken, expecting a certain user response to the interface, but did not receive it in the future. After a year of work as a project designer of this size, I can summarize the common truth from myself: do not use non-standard controls there. where you can get by with classic. For example, even a missing triangle in the drop-down menu can be misleading for your user. If your application does not require page reloading, then immediately think over the state of the controls while waiting for a response from the server (yes, we attacked this rake too) This is something that is better not to postpone for later!
What to do if for some non-trivial actions you could not come up with an elegant solution that does not require actions from the user? Tell him! For example, for full-fledged work of our application with client sites, we suggest installing js code on their resources. Initially it was assumed that this is quite simple and any user can handle it. But in the process we found that very often our users are people without special technical skills, customers, project managers. For such cases, we developed a special contextual help system that helped non-users to get lost in a difficult situation, gave brief information about working with complex functionality, redirected to our helpdesk or directly to a consultant. In addition to text comments, we also recorded and placed in the application small (20-40 sec) screencasts, which showed everything in a very visual form.
In the first version of the product, all the settings for any project could be counted on the fingers of one hand and there was no need to separate them - everything was extremely simple and clear. But as time passed, the project grew, we removed something because of lack of demand, we added something - as a result, the settings page became quite complicated for new users and we began to receive many hits. We analyzed the organization and evolution of settings in other projects and made several decisions.
First of all , we decided to hide them a little, because in fact only every tenth user who connected our product used the project settings.
Secondly , for convenience, we have divided all the settings into various subject groups with a clear purpose.
Conclusion:
If you are working on a developer service, be prepared to face a large bounce rate at the user registration stage. The most difficult step is to get the visitor to become your user. To do this, he should understand well how your service works after 3-5 minutes on the site. I strongly advise even at the design stage of the product to see how others do it, for example, here: www.useronboard.com . The guys offer some interesting case studies from well-known teams. As a result, after watching this beauty and our sad product activation metrics at that time, we decided to do something about it.
The directions for the work identified the following:
Difficult registration: users were lost at the first steps of registration. It was decided to add training material on working with the service and simplify the process of creating the first project. Total, instead of 10 steps of mastering the service, it turned out 4. Now we are testing this functionality on the control group and are confident in the effectiveness of the innovations.
Controls: we made our plug-in module for commenting sites minimalistic because we didn’t want to annoy users with huge controls with signatures and instructions. But having solved one problem, we ran into another. Despite the fact that the number of buttons on the widget was minimal and they were equipped with icons, some users still did not understand how to use them.
To solve this problem, we made a small round of 6 steps, which reinforced the practical skills of users - from adding comments on project pages to appointing a team member responsible for solving the problem.
Being engaged in product development for users, constantly check your hypotheses, test new functionality. Most of the mistakes made in the interface design can be avoided at the prototype stage by simply asking colleagues or friends to try out your product. Invite them to visit, organize the recording of their actions on the monitor and reactions (for example, we recorded the sessions with a simple smartphone or webcam), set 3-4 key objectives that will allow to cover the tested functionality of the product. After that, take enough time to study the collected material, and you will immediately understand where people are faced with problems and inconveniences.
Invite to test your product, both experienced and people far from technical innovations. Believe me, if your grandmother figured out the interface, for example, then 90 percent of users will not have problems either.
Listen to your user, try to use your own product as often as possible and constantly try to critically overestimate your own experience! Then you will have a wonderful product that you and your users will be proud of!
If you are interested in learning more about our service, we recommend that you read our previous article or try it in action .
')
Why recycle the interface?
Any developer knows his product many times better than any user, and this can lead to a misunderstanding between them. A good developer always tries to look at what he does with the eyes of his user, but he does not always succeed.
Any developer will have thoughts about reworking the web project interface if:
- You get a lot of questions from your users asking them to help them deal with a complex function.
- too few users are converted to permanent;
- A large number of resource visitors begin the registration process, but do not complete it. Those. visitors are not converted to users;
- part of the application functionality is outdated or not popular;
- you add new features;
- It has been more than a month since the last edits in the application.
In any case, sooner or later the developer understands that something is not working as expected for the customers, or the process is not thought out in principle. And that means it's time to improve something!
What did the experience of developing your own product teach us?
In fact, TrackDuck , like any project, consists of several separate parts and we try to organically combine them in the product that we offer to our users:
- widget for commenting on third-party sites;
- managing and loading thumbnails and images;
- task list with error reports and screenshots;
- list of projects with the ability to add new ones;
- project settings;
- user profile settings, billing, personal data.
All this should be clear and accessible to users at any time. The project should work on various platforms and devices, from mobile to tv-monitors. Below we will discuss the seven problems that we faced during the last year of product development, and the way we solved them:
1. Sidebar or top navigation
In the first version of the service, we used the space at the top of the page to navigate through the key functions of the service and user projects, but over time we became convinced that this path is not very good for several reasons:
- it is difficult to make an adaptive version of the product that would work on tablets and devices with a small diagonal,
- inefficient use of space
- sidebar and vertical sections allow you to better and more clearly organize the space of the control panel
In our case, the advantages of the sidebar are obvious. Its use allows to divide the application well into zones, each of which will be associated with its functional part of the application. In addition, the right menu with a list of projects is hidden when there is no need for it, which makes it possible to more effectively use the space on the device screen.
2. How to create an interface that works for mobile, tablets, PC, TV
The process of creating separate applications for mobile platforms is almost always associated with additional costs for the development and support of individual native applications for various platforms, the project does not always have these resources at an early stage. Based on this and from the received requests, including from our commercial clients who wanted to get access to our service on mobile devices as early as possible, we decided to make our control panel adaptive. The organization of the interface with vertical blocks allowed to do this with minimal cost. We used Media Queries, ngTouch, matchmedia-ng. We added the necessary styles and scripts for the main elements and now our application works almost everywhere:
In addition, our interface with a vertical separation of information representation areas allows us to focus the attention of customers on the part of the product with which they are currently working, allowing you to hide unused ones.
3. Introduction of additional functionality to the interface
We carefully analyze the metrics of using various functions of our project and listen to user comments. We also try to identify the underused functionality of the project, the support of which is inappropriate, and add new functionality that allows us to solve the tasks of our clients more efficiently. The biggest problem with this is to keep the layout of the elements familiar to our customers, test the new functionality on the control group before its total implementation, and effectively notify users of the emergence of new functions and work with them. Onboarding successfully copes with some of these problems (we specifically design it so that when adding something interesting to our project, the new functionality does not go unnoticed)
4. Intuitive interface
Icons and icons greatly facilitate the work with the interface. Surely many of those involved in interface design are familiar with a great book : - The key point is not to make people read. We combine recognizable icons with captions to all key interface elements of our system. Very often we forgot to change the type of the cursor on special elements, we had to rework the inline text fields several times:
Also very often we were mistaken, expecting a certain user response to the interface, but did not receive it in the future. After a year of work as a project designer of this size, I can summarize the common truth from myself: do not use non-standard controls there. where you can get by with classic. For example, even a missing triangle in the drop-down menu can be misleading for your user. If your application does not require page reloading, then immediately think over the state of the controls while waiting for a response from the server (yes, we attacked this rake too) This is something that is better not to postpone for later!
5. Contextual user assistance
What to do if for some non-trivial actions you could not come up with an elegant solution that does not require actions from the user? Tell him! For example, for full-fledged work of our application with client sites, we suggest installing js code on their resources. Initially it was assumed that this is quite simple and any user can handle it. But in the process we found that very often our users are people without special technical skills, customers, project managers. For such cases, we developed a special contextual help system that helped non-users to get lost in a difficult situation, gave brief information about working with complex functionality, redirected to our helpdesk or directly to a consultant. In addition to text comments, we also recorded and placed in the application small (20-40 sec) screencasts, which showed everything in a very visual form.
6. Settings
In the first version of the product, all the settings for any project could be counted on the fingers of one hand and there was no need to separate them - everything was extremely simple and clear. But as time passed, the project grew, we removed something because of lack of demand, we added something - as a result, the settings page became quite complicated for new users and we began to receive many hits. We analyzed the organization and evolution of settings in other projects and made several decisions.
First of all , we decided to hide them a little, because in fact only every tenth user who connected our product used the project settings.
Secondly , for convenience, we have divided all the settings into various subject groups with a clear purpose.
Conclusion:
- Hide away what is rarely used, but without which you can not do!
- Delete unused to give more attention to working functions!
- Group!
7. Registration
If you are working on a developer service, be prepared to face a large bounce rate at the user registration stage. The most difficult step is to get the visitor to become your user. To do this, he should understand well how your service works after 3-5 minutes on the site. I strongly advise even at the design stage of the product to see how others do it, for example, here: www.useronboard.com . The guys offer some interesting case studies from well-known teams. As a result, after watching this beauty and our sad product activation metrics at that time, we decided to do something about it.
The directions for the work identified the following:
Difficult registration: users were lost at the first steps of registration. It was decided to add training material on working with the service and simplify the process of creating the first project. Total, instead of 10 steps of mastering the service, it turned out 4. Now we are testing this functionality on the control group and are confident in the effectiveness of the innovations.
Controls: we made our plug-in module for commenting sites minimalistic because we didn’t want to annoy users with huge controls with signatures and instructions. But having solved one problem, we ran into another. Despite the fact that the number of buttons on the widget was minimal and they were equipped with icons, some users still did not understand how to use them.
To solve this problem, we made a small round of 6 steps, which reinforced the practical skills of users - from adding comments on project pages to appointing a team member responsible for solving the problem.
Instead of concluding:
Being engaged in product development for users, constantly check your hypotheses, test new functionality. Most of the mistakes made in the interface design can be avoided at the prototype stage by simply asking colleagues or friends to try out your product. Invite them to visit, organize the recording of their actions on the monitor and reactions (for example, we recorded the sessions with a simple smartphone or webcam), set 3-4 key objectives that will allow to cover the tested functionality of the product. After that, take enough time to study the collected material, and you will immediately understand where people are faced with problems and inconveniences.
Invite to test your product, both experienced and people far from technical innovations. Believe me, if your grandmother figured out the interface, for example, then 90 percent of users will not have problems either.
Listen to your user, try to use your own product as often as possible and constantly try to critically overestimate your own experience! Then you will have a wonderful product that you and your users will be proud of!
If you are interested in learning more about our service, we recommend that you read our previous article or try it in action .
Source: https://habr.com/ru/post/229259/
All Articles