Learning to design UX case study

This is collection of class assignment notes on drafting UX case study throughout Spring 2024 Semester at UW Madison

Shelcia David

--

Case study Link: https://www.behance.net/gallery/212977041/UPS-Madison-Case-Study

P1: How Might We.

During this “How might we” assignment, I delved into various design principles and conducted accessibility checks for the websites featured in A1. The primary objective was to pinpoint pain points and frustrations, with the ultimate aim of identifying areas for improvement in the digital space.

For the initial trading card, my approach involved in-depth research, where I meticulously identified and defined problem statements based on data collected through user interviews and surveys. In contrast, for the other two trading cards, I turned to Google and Yelp reviews, along with personal experiences and insights from friends, to discern and delineate the associated pain points.

Once the pain points were identified, I synthesized the findings into concise summaries within the trading cards. Subsequently, I embarked on drafting “How might we” statements by scrutinizing opportunities within the defined scope. To ensure a comprehensive evaluation, I considered accessibility and design principles such as the 8 Golden Interface Rules (notably, the lack of feedback and inability to undo in the second trading card), Fitts Law (applied to the CTA button and add to cart buttons in the third trading card), Hick’s Law (highlighting the issue of too many options in the second trading card), aesthetics (identified as lacking in the second and third trading cards), and adherence to the Web Content Accessibility Guidelines (WGAC).

Based on these assessments, I sketched rough outlines on the UI to visualize the areas that could benefit from improvement. Subsequently, leveraging the identified opportunities, I formulated potential solutions for each “How might we” statement, focusing on applying relevant design principles to enhance and refine the spaces.

This process involved a careful consideration of the design principles previously highlighted, ensuring that each proposed solution addressed the specific challenges outlined in the “How might we” statements.

The drafted solutions aimed not only to resolve the identified pain points but also to elevate the overall design and usability of the UI, providing a holistic approach to optimizing the user experience

For the analyzing on screens I took screenshots and went through the pain points mentioned and identified the space on screen which could be improved and added labels accordingly.
for accessibility checks I used WAVE extension (WGAC compiled and industry standard) to understand the accessibility flaws and addressed the way it could be fixed.

P2: Brainstorming.

During this “Brainstorming” assignment, I truly appreciated the collaboration and teamwork typically involved in brainstorming sessions (which wasn’t there much was this assignment). After discussing with my classmates, I decided that improving Madison’s UPS store website, focusing on printing, would be a good fit, as there are numerous opportunities for enhancement.

In class, I highlighted aspects not aligned with UX principles and generally confusing for users to my classmates, who provided feedback for further refinement. Following the class discussion, I revisited the pain points and frustrations to identify additional opportunities through brainstorming on FigJam. I initiated a timer widget on FigJam to adhere to the 40–45 minute timeframe mentioned in the assignment description, although I found that the most viable ideas emerged within approximately 15 minutes and very few popped out after that.

I attempted to address constraints such as ‘What if users lack technical experience and don’t know where to begin?’ and ‘What if users prefer not to use the website?’ Additionally, I considered whether existing features would require more development time, thus increasing costs. To tackle these challenges, I decided to prioritize essential features to avoid overwhelming users and potentially save on development costs. I also opted to streamline features and refrain from delving into AI integration (but I do have one idea based on it without constraints), which could demand more time and resources.

Once satisfied with the ideas, I stopped the timer and utilized FigJam AI to group them together, requiring multiple attempts to achieve satisfactory groupings. Upon successful grouping by the AI, I worked on refining those groups, adjusting headings, and trading ideas across themes for better fit. This process led to the identification of five major themes, which I further refined to three promising ideas to pursue for the semester.

I documented these three ideas and delved into exploring and explaining the specific opportunities associated with each. I believe these idea summaries provide a solid starting point and can be further explored during the semester.

My brainstorming board. One of the best things Figjam has to offer is its community driven widget and plugin which gives me access to features like summarize, sorting, timer widget and stickers. UX2 A2 — Shelcia David Raj

P3: Sketching.

One of my initial tasks was to reflect on the assignment feedback from A2, where the Professor highlighted the need to refine the “how might we” statement for greater specificity. I decided to drop the idea of streamlining the overall flow and focus solely on pricing and placing orders for printing. This approach provided a unique and narrowed perspective for the flow I needed to design. Diligently, I revised the statement to enhance its precision. Following this, I revisited the ideas I had brainstormed in A2, exploring various topics. Armed with these insights, I devised several solutions to address the issue at hand. Opting for the sketchboard, I delved into the design solution that best embodied the core idea. Subsequently, I sketched out the flow, detailing the process of placing orders for printing.

Despite having a well-planned storyline, there were some aspects I overlooked, such as a missing text field, which required me to go back and overwrite it. This realization underscored the significance of sketching any UI/UX idea. Additionally, I discovered that I’m not proficient at sketching; I had to redraw the storyboards three times, but with each iteration, they improved. Levels, annotations, and captions proved invaluable in helping me convey my thoughts with even greater clarity.

Once I was satisfied with the captions and storyboards, I decided to gather them in a document and number them. The storyboard began with my own experience: “I am a graduate student who wants to print two PDF files and is not familiar with the platform, which could be confusing.” I ensured that the idea of the storyboard aligned with the design idea I chose, which was “reducing frustration among users regarding price and placing orders.” I also made sure that the UI in each screen could be changed or modified, just in case of replacing dropdowns with checkboxes, as I had mentioned in the caption of each storyboard. I believe this would be a good starting point for prototyping the product for the rest of the semester.

My Sketching process. After laying out the plan, I drew the first iteration in pencil to quickly make any improvements and then, in the second and third iterations, I focused on making the sketch clearer.

P4: Task Flow.

One of my initial tasks was to reflect on the assignment feedback from A3. Unfortunately, it seems I skipped a few steps, such as creating low fidelity mockups and constructing a storyline. However, this oversight proved to be quite useful in this assignment. Having already formed a clear picture of how my mobile web app should look, it was easier for me to figure out the task flows. The challenging aspect of the assignment was breaking down these flows and considering them as individual tasks.

For this assignment, since I already had predetermined task flows in mind, I started by jotting them down and placing them in blue boxes, which would later be connected to signify flow. Once that was done, I drew a rectangle of mobile size with the app bar always on top and used that as the base template. Then, incorporating the insights discussed in previous assignments, I proceeded to draft screen by screen. After completing this for a particular flow, I wrote down the description and title for the flow and screen name. I attached the label afterward.

After completing the task, I made changes wherever I felt necessary to further refine the task flow. Once that was done, I began assigning labels based on the purpose of the screen or the functionality it served. Another interesting observation I’ve made is that with each iteration of working on this, I find myself adding more nuances to the overall flow. This is particularly evident now, as I reflect on my fifth time thinking and drafting the entirety of the platform. (ITERATIONS !!!)

Overall, I believe that this will be a good starting point for developing high-fidelity mockups later on during this semester, setting a solid foundation for further refinement and enhancement of the project.

The FigJam workspace contained task workflows. Notice the diverse use of elements on the screen for various purposes. Items positioned as layers above are depicted in a darker shade, indicating they represent distinct UI elements.

P5: Screen Design.

As common practice, I looked through feedback from previous assignments. One of the things mentioned was that the “add to cart” functionality was overlooked. Upon further inspection, I realized that the flow connecting to “add to cart” should be clearer, and it’s important to provide straightforward access to the cart functionality, allowing users to undo their actions without confusion.

For this assignment, I selected three task flows from previous assignments and attempted rough sketches of UI elements that would better fit the described tasks. I aimed to ensure that the elements were intuitive enough to be self-explanatory. After drawing the screens, I annotated and labeled them as necessary, without going overboard. Once my first iteration of design sketches was complete, I conducted further inspection to identify any overlooked elements that could disrupt the flow. One of the issues was not having a straightforward cart icon on the menu bar itself. Similar to other e-commerce or shopping apps, it’s usually placed on the menu bar. Another aspect was adding a checkbox for users to indicate if they wanted the same painting option for the uploaded files. Additionally, I realized that I had overlooked how users could add files. In the second iteration, I ensured that there were multiple user-friendly methods available, without overcrowding or overwhelming the interface. Each action button was designed to match existing patterns familiar to users.

In the second iteration, I also considered the spacing between UI components. For example, on the printing options screen, users can delete, edit, and zoom in/out. Grouping them together in one place might be confusing for users, so I separated and grouped them according to Gestalt’s law. Once I was satisfied with the design screens, I annotated them as necessary to eliminate any ambiguity regarding UI elements and flow design.

Overall, I believe this marks an excellent starting point for low-fidelity wireframes, providing valuable insights into how I want to position UI elements on the screen.

Returning to my notebook, I dedicated a separate page to each task flow to enhance clarity. Throughout the process, I extensively utilized various UI elements such as buttons, modals, icons, avatars, and images to effectively convey the design concepts.

P6: Design System.

As a common practice, I reviewed feedback from previous assignments. One aspect highlighted was the potential benefit of providing users with a numbered progress. With this in mind, I considered implementing steppers with appropriate labels. Completion of each step would be indicated by a change in the stepper’s icon, while the overall progress would be denoted by how much the stepper line has filled in.

In selecting colors, I referenced (https://m3.material.io/theme-builder#/custom) to grasp the foundational themes, though the primary UI colors were drawn from Flowbite UI (https://flowbite.com/docs/customize/colors/). After choosing the primary background and other major colors, I generated color hues based on these primaries using the Foundation Color Generator plugin.

For typography, I aimed for a friendly and accessible style that would be versatile across all UI elements. Contemplating options such as Avenir, Figtree, Outfit, and Uber fonts, I ultimately chose Uber Move font for its adaptability and range of variants. Subsequently, I began setting up the typography definitions necessary for the design system, ensuring they would meet the needs of all UI screens.

With typography established, I shifted focus to elemental design. Beginning with the basics, I concentrated on essential atom elements essential for UI screens. I initiated with avatars, allowing for variations in size and style to accommodate future design requirements. Responding to feedback, I then proceeded to design the stepper progress indicators. Additionally, I crafted a comprehensive text field element capable of accommodating various states, including error and success notifications.

In adherence to the feedback, I recognized the importance of not relying solely on colors for critical UI elements like input fields and alerts. To address this, I incorporated icons aligned with the messaging of each UI element. While my intention was to primarily utilize filled and outlined variants throughout the screen, I included color variants as a contingency measure if needed. Some of the components are inspired from the Uber base design ecosystem (https://base.uber.com/6d2425e9f/p/294ab4-base-design-system).

With these elements in place, I believe I can now begin contemplating a high-level fidelity prototype.

One of the standout features of Figma is its plugin ecosystem. My recent discovery was the Foundation Color Generator, which not only generates hues based on the color but also creates font palettes and sets variables. I found this feature quite amusing and valuable for my design workflow.

P7: Paper Prototyping.

As a common practice, I went through the feedback and this time implemented a stepper form to track the user’s progress. One thing that truly stood out to me was how different users interacted with the UI screen, always surprising me. I never once thought that the stepper form could be interpreted differently, perhaps due to the not-so-good drawings.

Some of the user feedback I received included the following: The screens appeared unfamiliar to the user, and the design seemed foreign (one user tried touching the stepper to upload). There is no option to view the printing material as a separate PDF or file. The user is confused by the options dropdown, as they are unsure of what each option corresponds to; for example, what “letter” size means. Scheduling seems hectic, and there is a need for an option to pick up the material as soon as possible. The user is unsure of where to pick up the printing material.

The initial process of drafting paper prototypes was easier for me as I was already familiar with what I wanted to achieve. I used assignments A5, A4, and A3 to draw the screens, and the tasks we completed in the classroom were very helpful.

Once I drew up the prototype, I tested it once to see if I missed any screens in between. After the unit testing, I approached users one by one and asked them to complete three tasks, which predominantly covered what the web app is made for. I asked them to think out loud so I could take notes, and I tried my level best not to explain anything on the screen. Once I received their feedback, I collected it and started thinking about solutions.

With the feedback, I tried to objectively create solutions to avoid confusion, while also incorporating best design practices and implementing some UX laws. I believe that with this approach, I will be able to further improve the interactivity and decide which components to place where, as I now have a more nuanced idea about how users interact with the paper prototype I made.

User 1 encountered an issue while completing the payment screen and navigating to the completion screen. There were instances where I couldn’t indicate that the button is disabled until the scheduled time, preventing the completion of the process in real-time.

P8: Wireframing.

As a common practice, I usually review feedback before beginning work. This time, the feedback involved three additional users from the previous assignment on paper prototyping. They particularly expressed uncertainties about certain UI elements and interactivity. One positive aspect of the last assignment is that as soon as feedback was received, it was thoroughly examined and suggestions were objectively documented. I have now incorporated those suggestions into the designs I created. The wireframes are based on paper prototyping, while typography and some UI elements are derived from the design system I developed in the previous assignment.

Although there may be gaps in the overall app, my primary focus is on comprehensively building the flow based on the three tasks mentioned in the assignment submission. The identified gaps primarily concern non-essential pages that will not disrupt the main flow expected from the app.

I began by developing components and then progressed page by page for each flow, addressing the gaps that would connect these flows and adding page titles. For each page, I start by developing the skeleton and then systematically build upon the elements I want, revising multiple times as needed based on the completion of other pages. To ensure a seamless flow, I conducted baseline prototyping and performed preliminary tests on the Figma app on my mobile device.

Once I confirmed the interactivity, I proceeded to address the points mentioned in the assignment description, such as visual hierarchy and organization. Following this, I began annotating to eliminate ambiguity and address any remaining questions.

I carefully incorporated the suggestions and made some minor revisions to increase clarity, such as adding labels to pages slated for deletion based on user feedback.

I believe this approach will form the foundation of the mobile web app I will be designing in the future.

I used my paper prototyping image as a reference along with my mini component library for wireframing. I made multiple revisions on this page before transferring it to the final completion page.

P9: Static Mockups.

As a common practice, I usually review feedback before beginning work. This time, I received four major pieces of feedback to work upon. The first one suggests using a 6-column grid to evenly space both 3 and 2 column layouts. This became incredibly helpful as it provided me with more flexibility to place my UI elements around.

The second feedback concerns the complexity of the Selecting Options page, making it difficult to navigate visually. I attempted to address this by replacing it with an accordion to create a multicolumn layout. However, upon reflection, I realized it might be better to keep it as a single column to simplify the user’s navigation and selection process. Although I intend to gather more feedback on this layout decision through experimentation with multiple users.

The third feedback points out that bounding boxes are distracting, which were only introduced for the sake of wireframing. Although I had introduced subtle shadows for mockups, I reconsidered their necessity.

The last feedback suggests introducing a hatch button in the checkout process, which I implemented. This prompted me to rethink some of the naming choices for buttons, leading to revisions in the mockups.

After considering the feedback, I duplicated the wireframing page and decided to create mockups for the same set of tasks. One significant change based on peer feedback from the previous class was the removal of the zoom in/out functionality, which was deemed unnecessary for mobile screen interfaces. Therefore, I completely removed it this time, intending to incorporate it later when adding interactivity to the screens.

I followed a similar approach to the previous assignment, utilizing a mini-component library for complex UI elements or combinations of atomic elements. These atomic elements are derived from the design system from A6. Once I built the complex component mini library, I began incorporating them into the screens. The images were all sourced from copyright-free resources such as pexels.com, and the information presented was generated by my AI.

After replacing the wireframing elements with the current library components, I reviewed the visual hierarchy, considering factors such as whether to use outlined or filled buttons in certain places and how to elevate multiple UI elements that are overlapped. This was particularly relevant in the case of the cart summary, where I needed to demonstrate differences in levels for three elements.

Once I completed the entire process, I conducted a mini-prototype run to test the assignment tasks and identify any potential issues or confusion for users. After feeling satisfied, I rearranged the pages and prepared them for submission.

This is my playground screen, where I typically keep my work separate from my submission screen. Here, I develop the complex component library, create copies of my wireframes, and post feedback, allowing me to iterate on my designs. I utilize this space to make multiple revisions before transferring them to the final completion page.

P10: Heuristic Evaluation.

As a customary practice, I reviewed the feedback received on my previous changes, addressing all but one issue. I focused on enhancing readability and user experience, with particular emphasis on visual hierarchy. This involved increasing button height, relocating icon buttons for improved accessibility, and adjusting background colors for better visual organization within the UI elements. While the payment screen and file/page deletion functionality saw some improvements, there remains room for further enhancement.

After duplicating the existing screen, I incorporated the feedback and carefully reviewed the task. Despite my familiarity with the task, which may have introduced bias, I conducted a thorough heuristic evaluation and iteratively refined the design.

For the evaluation process, I structured a framework to systematically identify and document issues. Through several iterations, I identified areas where presentation could be improved.

Additionally, I utilized online resources for preliminary evaluation. A website guided me through a series of questions, generating a heuristic evaluation report. While somewhat limited in usefulness, it prompted valuable self-reflection during the evaluation process.

Throughout the evaluation, I meticulously paused at each screen to identify potential heuristic violations, referring to the framework of heuristic principles. Once issues were identified, I focused on devising solutions, drawing upon UX laws and principles to inform my feedback for the next iteration.

Despite initial obstacles, the heuristic evaluation provided valuable insights into nuanced issues and underscored the importance of continual design improvement.

This is my documentation screen, where I generated documents for heuristic evaluation. This time, I included components that I use for mockups on the same page. I refined the mockups based on previous assignments. For quick reference, I also added a frame with heuristic evaluation guidelines to review within the same document

P11: Interactive Mockups.

I approached the heuristics evaluation as a feedback loop, using it to guide my implementation of fixes suggested by the evaluation. This process helped me streamline some of the unnecessary internal flows, such as deletion, and instead incorporated more standard methods of segregation.

Additionally, I made other fixes such as adding an undo alert for native file uploads, enhancing visual hierarchy, and refining various screen UI elements, including the payment screen.

For this assignment, I also included intermediate screens to complete interactions that weren’t specified in the static mockups.

Given the complexity of managing 33 screens, I opted to prototype from the component level wherever possible to avoid redundancy. I ensured that all close and cancel buttons (or similar buttons) were coded to have backward functionality, simplifying prototyping due to its dynamic nature.

Regarding page transitions, I predominantly used slide-in animations for navigating to the next steps, with the previous slide transitioning out in a different direction. For keyboard interactions, I employed overlay functionality to ensure ease of use, allowing users to close the keyboard by touching outside its area.

Furthermore, I introduced minor interactions such as customized toggle buttons for checkboxes within the components. While most interactions were straightforward, some, like implementing timer interactions, required more intricate solutions. For instance, I played with layer names to create different states and establish interactive connections for smooth transitions.

In conclusion, I believe the product now closely resembles the final vision I intended to showcase. It’s remarkable that even after numerous iterations, there’s still room for improvement at every step. While the UI elements are largely finalized, I anticipate minimal changes in layout moving forward, with a focus on optimizing the three major task flows.

This screenshot represents my final prototype screen, encompassing all flows and interactions. I find it visually striking, particularly with the intricate connections between each screen.

P12: Draft Case Study.

The entire process of crafting the UX case study was truly rewarding as it allowed me to reflect on months of work, transforming it into a meaningful prototype through multiple revisions based on feedback and design evaluations. This document became an invaluable tool in drafting the study, helping me construct the narrative that delved into the obstacles and new learnings, which I might have otherwise forgotten.

To begin drafting, I opened the portfolio entries and accessed all my files, conveniently stored in the same folder but on different pages. For visuals, I utilized pictures from portfolio entries and some taken from old assignments.

I was initially concerned about how to structure the case study. While I had worked on a few studies in the past, they lacked depth and mostly focused on UI elements like typography and screen explanations. This time, I wanted to create a more comprehensive study that encapsulated the true essence of the semester-long process. Despite not finding the exact portfolio study I was looking for after browsing through multiple UX designer portfolios, I stumbled upon a Medium article outlining the essential components needed for the study.

With that information, I outlined the structure. For mockups, I used the Art Generator plugin to generate visually appealing iPhone mockups. I opted to stick to a grid of 6 for consistency throughout the study and began designing it on Figma. I chose a dark background shade to contrast with the mostly white screens. To maintain consistency, I reused the design system I had in place for the prototype.

To ensure that users could skim through the content in 1 minute, I included a lot of visuals and bolded certain text in larger paragraphs to highlight key points. I added appropriate headings in each section for additional clarity, and for a five-minute read, I aimed to keep it concise and engaging by summarizing the entire process in a few points.

I believe this draft is a good starting point, and I look forward to collecting more feedback in class and making further iterations.

This screenshot showcases my playground, where I had the final mockups, wireframes, and screen mockups lined up, all of which I added to the case study frame. Having everything in one place was tremendously helpful, as it allowed me to easily generate screen mockups.

--

--

No responses yet

Write a response