To make the most of the constraints in place, each project was given an estimated time frame to allow proper planning. However, with any project uncertainties and iterations are always possible. Thus, it was important to consider each individual project as a standalone assignment. To ensure proper time management the assignments were divided between the team members based on the estimated time it would to take to complete the project.

Project 1: UI Consistency

With the overall goal of launching a mobile application, it was important to make sure that there was consistency in the UI design between both the web app and the mobile app. By having both platforms look and feel similar, not only does the service that Mizaru offers feel normal, but the user experience is one that can be flexible, meaning that the users can use both the web app and mobile app without having to feel the need to relearn either platform. To begin with this process it was important as a designer to learn the design system provided by Mizaru.

Firstly, it was important to look at how Mizaru as a service brand themselves, thus the usage of the logo and colors were looked at.

#FF5A5F

Bittersweet

This color serves as the primary color of the web app, where any important call-to-action buttons, titles, and notices were used. This was also the case in the current mobile app iteration, where all important areas in the visual hierarchy were denoted by the use of this color. Furthermore, within the typography, the font “Manrope” was used.

With these few things in mind, it was now time to look at the current mobile design and provided assets to see what patterns were being established and what changes potentially needed to be made.

From this point on, my partner Emily took the responsibility for the rest of this project, with the task of making sure the colors, typography and even things such as spacing between components were the same throughout the design. Furthermore, even changes to the user flow and design of components were involved, with Emily working on over 150+ screens each consisting of review and revision. Throughout this process, I also provided some assistance, as certain aspects of other projects that I personally worked on were also affected by these changes.

With any design it is important to think about accessibility when working towards a final product. This means applying WebAIMs color contrast test in which we can test for both AA and AAA conformance under the guidelines of Web Content Accessibility Guidelines or WCAG. What this essentially means is that the level of contrast in the foreground and background must pass in both samples of small texts, large texts, and UI components. Of the compliance levels, AAA is the hardest to achieve, with over 50+ criterias having to be met. With the case of this mobile product, there were certain areas where not even AA contrast was being met. So to help with accessibility in the typography some simple changes were made.

As suggested by Emily in our meetings with Mizaru, a simple black was needed. As we can see, the simple change between #FF5A5F and a simple black in the typography was used to create an easy-to-read sentence. Even with this change, the use of a large and bolded font still held the visual hierarchy of the overall screen.

Project 2: Rating System (Provider)

After discussing and implementing UI iterations, it was time to proceed with one of the projects I worked on for Mizaru. One of their goals was to implement a rating system for both clients and providers/support workers to leave feedback on the service they received or provided. In the current stage of the app design, the focus was on implementing this system for providers. To start the process, I conducted research on how other companies have implemented similar UI and UX designs.

I began by looking at Uber's approach to handling ratings at the end of each session. Based on my personal experience with Uber, I know that after each ride, users are asked to leave a tip and a review of the trip. However, Uber doesn't require users to do this immediately after the service ends; they can leave a review later. Uber's rating system is simple, starting with a 5-star rating component, and users can also select tags that represent the overall trip experience.

From here, I looked at Airbnb and how their rating/review system works. Based on my experience, it is very similar to that of Uber, with the only difference being the option to write a thorough review of the stay. One important thing to note is that the rating/review is not reflected on either the host or user until both parties complete a review. This seems to be in place to prevent any side reviews.

User Flows:

With insight into how rating and review systems work from two of the top services that require client and provider interactions, it was now time to ideate and think about a potential user flow. This is an important step in the design process as it allows for me to step into the user’s shoes and see how they would likely react and use the application. In this case, I wanted to make sure that the rating system flowed well with the already established screens of the app design. I also wanted to keep a similar flow to that of the web design in order to keep that cohesive experience. 

From this, I was able to decide on my starting, that being the requests page and more specifically the completed tab within that page.

With the user flow and systems insight in mind, it was now time to synthesize that information into sketches. Sketching serves as a medium to bring life to the solution ideas and information architecture created, allowing for an initial design concept to come to life.

Sketching:

These sketches were inspired by the already existing web design and assets provided by Mizaru. Generally, when designing for an application, you begin with the mobile and then scale up to create a web design. However, in this case, it was the opposite, so that is why it was important to create a sketch as it was important for me to get a feel of how the scaling would look and to see if certain components would not translate at all between the web and mobile design.

Using the assets and branding of Mizaru it was now time to create a high-fidelity mock-up based on the previous sketches and already existing web design. In total 3 different iterations were made before concluding on a “final” design before handing it off.

The first iteration would serve as the basis of continued design and how design can evolve fast. To begin looking at the first iteration, we can divide it into 3 main aspects. 1st we have the assignment card where the provider can which services they have completed.

Assignment Cards: Sketch vs. High-Fidelity

1st Iteration aspect 1:

From the sketch to the high-fidelity mock-up we can see that there were some issues with the spacing, primarily in displaying the total earning of the event. To locate this information in the high-fidelity design, the user would’ve had to scroll down. This is one area of the design that will change in the next iteration.

From this point, the initial design was shown to my partner and the Mizaru team for feedback.

From here, the second iteration of the design was created. This iteration would consist of changes to the UI and its consistency with the overall mobile app, changes to the user flow, and user experience design to provide a less overwhelming experience as well. The first change that was made was the overall design and feel of the “View Details” page:

To create a less crowded and overwhelming screen, all event-based information was nearly organized under accordions. This would allow for an organized look, as well as providing the user to instantly see their earnings as well.

The second and third changes were made on the review/rating screens, where I first worked on the color contrast and spacing of certain components based on the suggestions of my partner:

The first change is obvious and easy to spot, the change in the color of the tagline. The second change, however, was subtle and that change was the spacing between the two lines in the tagline.

The third overall change in this iteration was for the overall flow of the rating user flow. In the first iteration, we see that all the options to rate the event appear all at once. This was found to be slightly overwhelming, thus changes to the overall flow were made:

The 3rd and “final” iteration consisted of one minor change, that being the dropdown arrows for the accordion, where originally they had no symmetry:

With this 3rd iteration done, it was now time to hand it off to the Mizaru team and receive feedback from them in order for us to provide guidance for the next design team.

Feedback:

Overall, the majority of the changes made from iteration to iteration was based on feedback provided from both my partner and Mizaru itself. However, due to the time constraints we were given, it was not possible to go past the 3 iterations I designed, thus, it was important for me to receive feedback on what I designed and leave notes and guidance for the future design teams to iterate further on the designs.

One important note that was provided from this feedback session was the crowded feeling of the assignment card component

It was noted that “View Details” seemed both overcrowded and redundant when there was already a “meatball” menu in place. What this meant was rather than having two ways to look at further details, this component can consist solely of the “Rate Service” button and the “Meatball” menu to look for further details. This would also place focus on the primary objective, which is to get the users to rate the completed event. With this final consideration in mind, this particular project was put to a close.

Project 3: Assignment(s) Visibility (Provider)

With the larger UI project now completed, it was now time to work on changes that would improve the usability and visibility of certain components in the mobile app design. The overall goal for this project was to improve the user experience when it came to realizing assignments were available and ready to be accepted. Prior to this, there was no clear indication when an assignment was available.

To accomplish this goal, it was discussed that a small UI change would be best, as the dashboard was already full of information. Based on these criteria I was able to ideate 3 simple designs:

Ultimately, between the 3 ideated designs to help improve the visibility of the available jobs, it was discussed that the simple red “blip” was the best choice. Looking at the middle choice we can see it is difficult to distinguish what is being shown, as the number within the circle is hard to read. The middle choice also fails the color contrast test based on the AA criteria. The bell icon is barely distinguishable, where from a distance it would be seen as a bell. 

Feedback:

Upon having a discussion based on the user flow and user experience in the final feedback call, a few points were made in regards to the initial navigation bar. Originally, the navigation bar consisted of 4 buttons, however, from the work of Emily and feedback from Mizaru, it was discussed the use of 3 buttons would be much easier to follow.

With further discussion on how to create visibility for the users and in this case the provider, it was noted that the word “Requests” did not make the most sense, especially when looking for an assignment. Originally as we saw, within the homepage/dashboard there were 3 tabs to navigate between, with one being the “Available” button. Because of this layout, the home button (now shown as schedule), was taking the function of the “Requests” screen. To fix this flow, “home” was now renamed to “Schedule” and “Requests” was to be renamed to “Assignments”. This allows the providers to view upcoming and even completed assignments in the schedule screen, while the assignments screen would display potential work opportunities.

With this discussion, the original design to make job availability visible was not needed anymore, however, to keep with the same concept of notifying users of potential offers, the red “blip” could be used in the navigation bar.

Project 4: Web Updates

Service Animals:

This final project was based on changes for the web UI, more specifically the provider portal. In particular,  2 sections within the registration user flow had some changes that needed to be made.

The first section that needed to be updated was the Service Animal section. When first arriving on the page, the user is greeted with the option to select whether they have a service animal or not.

However, if the user selects yes, the option of yes and no still remained:

This led to a strange look on a page where there is an option to go back. We can also see that the text fields also needed updating as well. It was noted by Mizaru that the wording of the text fields felt redundant, for example: “Service animals vets office name” and “Service animals vets phone number”. So to help alleviate that feeling some changes were made to the wording.

Old UI and Typography:

VS.

Hand Dominance:

The next change that was made was also a part of the registration/profile section, where the user was to select their hand dominance. Originally there were 3 options to choose from, however, one of the options did not make sense in the context.

“Hard-of-Hearing” was replaced with “Right-handed”

Admin Portal & User Management :

The final piece that I worked on for the web design was on the admin portal and more specifically the user management page. The issue that was looking to be solved in this case was a UX problem. Currently, if an admin were to accidentally click on the toggle switch for any of their users, the account would be automatically disabled and the user would receive an email saying. The same thing would apply when it was re-enabled. 

This would create a potential abundance of emails for the users of the app, as well as allow for the admins to accidentally cause that issue. To solve this issue, the user flow needed to be adjusted, and for this due to the time constraints, I was able to ideate 2 different designs.

The first design was centered around single-user targeted actions, meaning that changes to the status of the user base would only be able to be made on a user-to-user basis. For example, as we see in the image above, Matt Murdoch has a toggle switch that could activate or deactivate his account. However, if that switch was now clicked, the admin would be presented with this message: 

This would be that none of the changes would be made until the confirmation was also made as well, thus creating a system that would prevent easy-to-make changes.

With both these user flow designs in mind, it was taken to Mizaru for further feedback. In this feedback session, we discussed that a better solution that provides a balance for the admin and a clear UI, would be to completely omit the access toggle switch and replace it with an edit button instead.