In order to understand the problem, I started interviewing a few users of the application. These user interviews are a crucial step in gaining insights into their experiences and pain points. However, before conducting interviews, I initiated an observation of the current problem to see what people feel and see when using the application.

Important findings:

• "The information is not specific enough. I don't see what I need to know. It feels like there's no way to know where the request is at in the process".
  
  

  The available information lacks the desired level of detail, making it challenging for users to find the specific information they need. Users are left with a sense of uncertainty about the status and progress of their requests, and it's not clear where these requests currently stand in the process

• "I can't filter between the different statuses of each request, so I often don't know where a request stands in terms of its status. I have to look within each request to determine its status. Is there a different way to do this?"
  
  

  To address this, it would be helpful to have a feature that allows the user to filter and sort requests by their status. This way, the user can quickly identify requests with specific statuses without the need to open each one individually. Implementing such a filter option could greatly improve the workflow and make tracking request statuses more efficient.

• " I often can't assign requests to my name, so I may not be aware, for instance, that my colleague is already working on them."
  
  

  To adress this problem a possbile solution could be a function where the user simply could assign the reqest and at the same time implement an automated notification system that informs team members when a request is assigned to them. This way, everyone is kept in the loop regarding their responsibilities and the status of requests.

• "I'm seeking improved affordance in the user interface. I've observed that labels are frequently not optimally positioned, and buttons sometimes seem to be misplaced."
  
  

  To resolve this, a comprehensive evaluation of button placement and structured usability testing should be conducted to determine the most user-friendly arrangement.

• " As a production employer, I should not be able to modify requested information. Information can be sensitive, and it should be up to the requester to make any modifications."
  
  

  This could be an easy fix. Since at the moment there are edit buttons next to the label. Remove them and it should be resolved.

• "I wish I could simply upload my files in the request without manually having to upload the files when sending an email to notify the requester."
  
  

  To address this and to simplify the file attachment process, exploring the implementation of a feature that allows the user to upload files directly within the requests. This enhancement will not only saves time but also make the process more convenient.

In order to understand the product I created a flowchart of the current application. This was needed to have a beter understanding what was actually going on.

In order to understand the problem better, to use of a costumer-journey helps to better understand the situation.

Opportunities

Regarding the Informatie app, there are good opportunities to enhance the current problem of internal communication.

• Applying filters and the improvement of the structure could lead to quickly filter information so users can efficiently find what they are looking for.
• Another opportunity is to build a function where the user simply could assign the reqest on their name and at the same time implement an automated notification system that informs team members when a request is assigned to them. This way, everyone is kept in the loop regarding their responsibilities and the status of requests.
• Creating notifications to notify the users in their respective roles if a status has changed. This adresses the problem of users not knowing where the request is at in the process.
• Users being able to simply attach documents and files into the requesters form will enhance and saves time what will make the process more convenient.

In order to get the best result, using the Moscow methods helped a lot to clear out what was important and what not. Most Have - Should Have - Could Have - Won't have.

Most have's

• Filter between statuses
• Assign requests between active roles
• Removing edit mode on specific requesters information
• Be able to add files within requesters file
• Make a better affordance where labels are better structured with more margin.

should have

• Be able to switch between working on IRR and IRVI
• Be able to see the phone number from request form
• Be able to edit journalpost within request form

Won't have

• Make it mandatory to file management number within the system

Ideation fase

Creating such a complex application is not an easy job. a big help in the Ideation fase was the use of the so called CMD methods packs it uses familiar paterns that can be used in various moments in your design. They are the building blocks to your design. It is also a great help when you stuck and you need something to remind yourself.

One of the cards I used was the ideaton card. Together with the UX team we used this card to brainstorm ideas what could be working to the problem were having.

One of the cards I used was the ideaton card. Together with the UX team we used this card to brainstorm ideas what could be working to the problem were having. This mentioned brainstorm techniques like: Mindmaping-linking words with the main idea. Another ideation method us the Scamper method-uses various ways to think of the idea in another so to say coat.

More on this here.

The water lock

With the ideation came various concepts. The final concept involves a process where a request goes through several stages before it is processed:

1. Request is submitted.
2. Frontdesk checks and registers the request.
3. Request goes into a general queue.
4. Employees handle the request.
5. Request is forwarded to the next department.
6. After processing, the request returns to the front desk.
7. Frontdesk prepares the request for the customer.

Prototyping

With the feedback from the user and with the finalized concept, I was assigned to design the idea with a prototyping tool. I took in account the requirments from the MOSCOW list. I share I few screens to demostrate the new features.

feedback from te usability test

Upon completing the design phase, I initiated the creation of a Usability Test, focusing on ensuring the product's seamless operation without the necessity for explicit guidance. The primary objective of this test was to assess the intuitiveness of the product's functionality, treating it as if it were already an established reality in the user's experience.

Results

1. The majority of the participants were able to use the product without any issues and understood its basic functionalities. Including filtering on request and uploading required files.
2. Some participants encountered difficulties with specific tasks, such as locating certain features, indicating potential areas for improvement in the user interface. Overall feedback from the participants was mostly positive, with praise for the product's intuitive nature.
3. .A small number of participants required some additional explanation, for instance did not know what the buttons on top meant with the account icons, meant to switch between roles or to go to personal requests.

Overall, the usability test proved valuable in gaining insights into the product's user-friendliness and identifying potential areas for improvement.