Workish - UX/UI journey
Background
Workish is a time control system to be integrated into the Teamish application, with the idea of being a module or product sold separately.
My jobs
Research, analysis, visual design development and testing.
Case challenge
Workish is a product derived from Teamish, therefore, it must follow its logical standards and visual identity, even in the absence of a Design System that is still in the development phase.
Discovery
To conduct the discoveries, the CSD Matrix tool was used. It helps to better understand the project, eliminating guesswork and conducting data collection, ideas and project decisions in a more accurate way.
This picture changes throughout the project journey.
Benchmarking
Users of the initial demand used the Pontomais app, so it was the focal point of the research, but other market players also received attention at this time, helping with comparison and raising hypotheses.
Search
After comparisons and the raising of some hypotheses, qualitative research and interviews were carried out with 25 users to validate these hypotheses in addition to collecting feedback in order to obtain detailed information facilitating insights.
Insigths
From the research, the following points were found:
– There are no difficulties in using the current app.
– The Web system is also frequently used.
– Users like the objectivity of the app.
– The Web system has some bugs.
The individual interviews helped a lot to refine the qualitative research, generating 4 points of interest:
– Explicit time bank on the main screen.
– Only the explicit day records on the main screen.
– Explicit pending alert on the main screen.
– Easy tracking of total hours.
Personas
Inspired by the existing user base and the research results, it was possible to create 3 personas to increase understanding and empathy, focusing on end-to-end development, that is, solving the problems of both the end user and the customer.
MVP Wireframe
Based on the information so far, it was possible to conceive the visual idea of the app’s main screen and a wireframe of the system’s main functionalities, forming an MVP.
Information Architecture
After understanding the main activities that the product needs to have to fulfill its basic function with as little resources as possible, it is necessary to organize the functionalities, and then explore new solutions and possibilities within this.
User journeys
With the general flow well defined, now the objective is to understand the steps that the user will need to take to perform the tasks, identifying possible opportunities for improvement and differentiation for each action in the journey.
"As a Workish user, I need to log in for the first time so that I can fully enjoy the application."
Use case flowchart
Knowing the user’s steps, the next step is to outline a flow identifying possible decision-making and alternative paths for each use case, so that the flow does not have any blind spots.
Low fidelity prototype
Once all possible paths have been mapped, it is time to represent the screens in a low-fidelity prototype and submit the flow for testing.
High fidelity prototype
After testing and approving the low-fidelity prototype, a flowchart of the high-fidelity screens was illustrated, along with the high-fidelity prototype, and submitted the flow for testing.
What I learned
– When you have the opportunity to do a good job of researching and interviewing users, the flow of the entire journey runs more smoothly and quickly.
– Creating flowcharts helps a lot in testing, especially those involving flow.
The next steps
After building the flow, there were some insights that can be considered:
– No need to wait 24 hours to adjust the point.
– Being able to cancel the request when made incorrectly.
– Optional comment to justify hours, points, allowances.
– Automation of time off compensated from the time bank.
– Go to the other end of the business (managing user).