SpaceShip

Background

One of my personal gripes about selling things from my hobby (mechanical keyboards) is that I often need to invoice my individual buyers so they can pay for the item before I ship it out to the buyer. However, the item collection (pick-up/delivery) is completely the buyer's responsibility; so in the case of when the item needs to be shipped out, I would need to invoice the buyer again for the shipping costs.

Because the buyers have different preferences when it comes to the shipping carriers, I would have to individually get shipping quotes from those carriers. I needed a quicker, more efficient, one-stop solution so I can streamline my selling process within minutes. With just one-click, I can get shipping quotes from all domestic shipping carriers and include that shipping cost on the first invoice, eliminating the need for a second invoice.

But maybe... maybe we can just make a more generalized solution?
Sending packages for the first time? Or maybe you just don’t send packages that often. The amount of domestic shipping carriers, their own list of shipping options, and their list of extra shipping services (like signature confirmation and insurance), it’s just way too overwhelming for an average person that doesn’t ship things often. What if there was a simple web tool that can simplify this process in just one-go? No need to check with each carrier one by one, just fill out your origin, destination, and package details followed by a single click to save ourselves the headache.

Storyboarding

Normally, we would start the design process by storyboarding, and this would address the problem statement using different potential solutions. However, my team and I were already considering quick and on-the-spot solutions during our 'needfinding' process. In our 'needfinding' process, we would each come up with personal/daily needs and throw them onto our board until they sticked. And when I say "they sticked", I mean that the 'needs' were capable of being more generalized to the masses, as well as considering whether our quick & on-the-spot solutions were feasible.

For this particular focus, we realized there is no other way to go around the fact that we will always require users to enter a set of information and get results. So for our storyboards, we focused on potential target audience for our mobile webapp. We separated our target audience into three different groups: a typical consumer, small business owners, and corporations.

Prototyping

For our next step of the design process, we went onto paper prototyping, which basically allows us to start mocking up our mobile webapp design as paper and pen sketches. In this process, we were stressed on the idea of 'buy-in' and 'ownership'; as a follow-up, we decided to come up with mock-up designs individually, then come together again to start pitching each other our design elements and ideas. This is contrary to the advice given by our mentor (to work on the prototypes together) because I was concerned that our each individual vision of the final product would become muddled/contaiminated by working together.

Two of the paper prototypes came out relatively very similar to each other, so they were absorbed into one. The final two paper prototypes that were submitted are shown below.

After few sessions of Heuristic Evaluation(HE) and gathering feedback, we came back to discuss what particular design choices worked well and ran our bids on 'buy-in' and 'ownership'. We also used this chance to iterate on certain elements with QoL changes and improvements with the feedback from our HE sessions. The final paper prototype with combined design elements & improvements is shown below.

Wireframing

Our wireframing process was different from others; this process was well-absorbed into our prototyping process. Because one of my teammates (Melody Yu) was very comfortable with wireframing & Figma mock-ups, we each took one paper prototypes to wireframe on Figma after we had our final two paper prototypes to be submitted. These two sets of wireframes from the final two paper prototypes are shown below.

For our final paper prototype, Melody completed the wireframes while I completed the skeleton HTML/CSS for the live version of our mobile webapp. Wireframe for the final paper prototype is shown below.

Testing

Our testing process was also different from others in the sense that we weren't necessarily testing for the purpose of design but rather for the purpose of functionality. In terms of design user testing, it was absorbed with the prototyping and wireframing process as Heuristic Evaluation Sessions. However for the functionality testing, I had to make sure that the front-end is asking for the correct necessary information for the API to fetch the shipping rate estimates.

This process also includes making sure that the addresses inputted by the users are correctly being validated (check if address exist), form validation (checking for valid numbers for package specifications), and any other error handling that may be thrown by the API. During this phase, Melody stepped up to fix up rest of the front-end and add some proper styling to the webapp. The final product with proper styling is shown below.

Reflection

Overall, I believe that this experience was a really good way for me to learn one of the ways of going through a design process, as well as gaining experience in working in teams and making difficult decisions. I learned that it is possible for people to have extremely different work ethics, priorities/focus, as well as their skill levels. Furthermore, I learned how important it is to hold people accountable for their assigned tasks and the needed soft skills in handling team dynamics. After all this, I still struggle in finding the best course of action on handling teammates that may refuse to 'learn'; however, I realized that it is still possible for those teammates to contribute as long as they work in their area of preference or expertise.

I want to personally thank Melody for stepping up with me to fill the lack of manpower and presevering throughout the rough situations and the project. I really appreciate the work that Melody put forward in making sure the front-end gets well taken care of while I focused on the backend to ensure this project is fully functional. In the future, I would like to continue on this project and build this into production level application with more interesting and QoL features.