Add Entity Forms
To add or not to add. How to do it faster?
This project was a quality of life improvement for existing Viberate contributors. By making new forms clearer thus improving the process of adding new entries to the Viberate database, and making the job of our internal database administrators easier by implementing inline checks. This was planned so we could save time on reviewing duplicates that are sent through the forms to our database
Through user feedback, and seeing the behavior of users using Hotjar, we decided that there was a lot of room for improvement.
This was one of my personal self-initiated improvement projects, that was started in April 2018. As of yet it still has not lived to see the light of day, because of other projects with higher priority.
One of the main issues identified was losing progress while filling out the forms. It turned out that users often lose their work by accidentally clicking outside the modal window, which in turn prompted the whole thing to close.
This provided unnecessary frustration to the users that needed to be addressed. But users are paid to provide new data entries so the pain was sufferable.
But the biggest issue was that all in all the old forms failed at most of the common UX practices as in field validation, visible labels, contrast etc. This was also the main motivation for starting the project.
It made sense to start this project by defining the user flows. This way I could easily imagine the steps the users have to take to successfully complete the task of adding an artist. As usual, I started with a pen & paper and transferred the flows into digital for easier presentation.
With these flows, I was able to define crucial moments where we could implement in-line checks, to prevent duplicates, and to prevent unnecessary work, for no reward.
I was able to split the form in digestible chunks, for easier input, and it made the whole picture much more clearer to us.
We did not exactly use wireframes for exploring our options here, as the whole form field design was relatively undemanding.
We decided to follow material design guidelines, but still including our own already established language, to quickly design and test our solutions.
All in all, we did about 20 iterations while testing the prototype.
See the screens for Add Event below
User testing for this was quite fun. As we also have internal contributors to our database, we had the perfect user segment already in the house.
The testing took two days, one day to set up and another to test the prototypes. Around 9 participants were involved, most of them used to our old forms.
As the developers had some extra time on their hands, some of them decided to join in and actually create a quick front-end version of the forms. To save time I would not recommend this approach but at the time of testing, it was feasible.
The tasks mainly revolved around successfully completing the form. I did, however, try to surprise them with one of the tasks ending in error, to gauge their reaction and to see if they understood how to proceed.
This proved successful in most cases, we did discover a few issues, most notable of them was the way we designed and executed the select time and date fields, which proved to be very user unfriendly.
Priorities often switch in startups and I wish this project would have gotten more attention. The main thing I learn from all of this is that I should be more persistent while trying to achieve my goals especially when they concern our users the most.
I did, however, learn a lot about proper form fields, for instance when to validate, how to validate, what is the best approach etc., this knowledge will certainly come in hand in the future