We received a specification where assumptions and requirements were described. The general structure of the application was scratched as well. We analyzed specifications and tried to capture the current process. An essential part of this job was to understand the order and the goal of each action.
After we understood how and why the whole process was working, we could design solutions discussed with the Business Owner of the process and the Technical Manager. We suggested dividing the application into two main modules: for users and admins.
Future users of the application (vendors, to be more specific) needed to put the necessary data (which we designed as forms to fill in) and periodically update information. The goal here was to create the most efficient way of collecting data because this process initially required a lot of time and was quite complex. What’s more, our client needed to change the type of data collected from time to time. We choose uniforms to deal with those problems because of the flexibility and possibilities of using validation.
On the other hand, we had admins responsible for verifying users’ data and decision-making about further collaboration. Because we have vendors to handle from all over the world and slightly different rules or types of collected data, admins needed a system of access and permissions (e.g., admins from the USA might verify data from American vendors). We also designed a system of assigning applications from vendors to admins and functional filters.
What’s more, we saw the need to create a space for communication between users and admins. Users receive feedback from admins about data they provided and further decisions. From our perspective, it was worth reminding users about approaching the date of data update or sending them info about its application’s changed status and requiring their activity.
