#nm3221

Short Summary

The second event I attended was part of BIDA’s (British Industrial Design Association) online series of events under the banner of Design in Extraordinary Times. This particular event was entitled Designers in Sustainability: What Metrics?. I found the event on Eventbrite, and it took place online on Thursday the 14th of October 2021 from 7:30 to 8:30pm Singapore time. 

The event featured five speakers, one being the event chair, who each shared their experience (~10 minutes) working within the design field and how sustainability plays a role in the design decisions that they make. Each speaker had very different design backgrounds, with two who were design consultants, one who runs a manufacturing company, one who runs a web plugin startup, and another who works with sustainable biomaterials. After every speaker had introduced themself, there was a brief Q&A session where the event chair asked his own directed questions as time was running short.

Notes Taken

Below are the notes I took during the event. It was quite fast-paced, hence I was unable to capture everything that was shared.

Reflection

I selected this event to attend as I noticed it was hosted by BIDA and thought that it would be insightful to listen to experts within my field discuss sustainability, something that I am always interested in incorporating more of into my design practice. Most of the speakers did not deal much with technology-based sustainability initiatives and the discussion that was presented during this event was quite technical, revolving around KPIs, the circular economy, sustainable design engineering, carbon net-zero initiatives, etc. 

Technology as a whole was only briefly mentioned by some speakers, such as when Chris Sherwin (a design consultant), asserted that “technology on its own won’t solve most problems”. This resonated heavily with me as I feel that design and mobile interaction design often serves to make the user’s life easier and more frictionless with little consideration to how this impacts the environment. I took a GE last semester called Globalisation and New Media, and the main thing I learnt was about media materiality and that every communication (digital or physical) is material. Oftentimes we view technological products, particularly those which are intangible, as having no negative effects on the environment. However, every digital interaction and physical piece of technology actually does impact various low-income communities (such as e-waste processing in Guiyu) and their respective environment (chemical poisoning). 

With this knowledge, I think it is important for me to understand what does and what doesn’t necessarily have to be digitalised or automated. Although, as a designer, we seek problem statements and ways in which we can alleviate the prominence of particular pain points within a user’s context, perhaps some things do not necessarily have to be solved by technology. The first idea that always arises when ideating, within Industrial Design modules or this module, is to fix a problem with an app or with a feature within an app or with some sort of tracking device or sensor, etc. However, I think it is important to have a balance between what merits a technological solution and whether that solution brings enough of a positive impact to its target audience to outweigh the negative impacts on low-income communities and the environment they live in. 

One of the speakers, Sille Bertelson, was the only designer who currently worked in creating digital products. She co-founded shADe by shadey.club, an anti-greenwashing web plugin that overlays an emoji on products when online shopping, allowing users to see whether the product is sustainable based on “planet”, “people”, and “animals” indicators. It allows users to make more informed decisions when online shopping and learn more about the companies behind specific products or discover more sustainable alternatives. I thought that this was an interesting product in relation to designing web apps, as it builds upon existing infrastructure to provide users with more autonomy when online shopping. 

There is a myriad of mobile apps that already exist, hence I think it is an interesting opportunity to design for or around apps that the typical user would already have on their phone instead of introducing a whole new app that users may not trust or know about, hence are uninclined to download. This is similar to Google Chrome extensions and how users trust Chrome enough to download all sorts of silly extensions even when they are not created by established web developers. Hence I think that it is an interesting opportunity within the field of mobile interaction design to leverage the trust that users already have for specific apps or infrastructures installed within their phones to introduce new interactions which could elevate their experience. A key slide that Sille had in relation to this is shown above, where meaningful collaborations and mutual understanding in meeting a common goal is paramount in creating compelling and sustainable digital products. 

Short Summary

I attended Storytelling in Product Design, an event hosted by Wanted Jobs and presented by Rucha Wairkar, who is a product design lead at BigPay. The event was hosted online and was roughly one hour long, with Rucha presenting for half that time and hosting a Q&A session for the remaining 30 minutes. The main idea of Rucha’s presentation revolved around the story arc (ie. exposition –> rising action –> climax –> falling action –> resolution), which is used as the basis in narrative storytelling in television, books, graphic novels, etc. The main message she aimed to put forth was that designers are able to apply the story arc to various design contexts to better facilitate the design process and understand and fulfill user needs. The two charts below are from the presentation. 

She further provided examples of how the story arc and storytelling in general has been successfully applied by different apps, citing Headspace’s onboarding redesign and Duolingo’s gamification in making learning languages more fun. The conclusion of the presentation portion then emphasised the overall importance of integrating storytelling from the beginning to the end of the design process. 

Notes Taken

Below are the notes I took from both the presentation and Q&A portion of the event. It goes a little more in depth with regards to specific things Rucha mentioned and her responses to questions she received during the Q&A. 

Reflection

In studying for my major, Industrial Design, we are always encouraged to design physical products with a compelling narrative as it is what makes designs unique and sets certain designers apart. Hence, I was very excited to attend this talk, especially since Rucha works for BigPay, a mobile app that tracks expenses and provides instant money transfer. I was intrigued to learn about how storytelling can be applied to digital products, as opposed to only physical ones, and how a compelling narrative can best be applied to mobile interaction design, as I previously was unsure of how this might be achieved. 

I appreciated the introduction of the story arc as I feel it is an idea familiar to most people, from childhood English lessons, but I have never actually seen it applied or implemented outside of writing stories. I think that the idea of the design process as the process of telling a story is quite a poetic re-interpretation of design. I thought that Rucha’s reinterpretation of the story arc was simply about breaking down the scenarios we create as designers into smaller parts in order to better pinpoint where to implement a design solution, rather her perspective was one where the story arc paralleled the design process as a whole (as shown below). 

Since we learnt about user personas and scenarios within this module and implemented them in our very first group assignment, I think that breaking scenarios down further into specific parts of a story arc would aid in getting a more well-rounded understanding of issues that a user faces, as opposed to just looking at the design process as telling a story like Rucha does. I think that the chart shown below would make for a more compelling scenario that a persona faces and provide a better understanding for designers when attempting to implement a solution. Though it is a similar interpretation to Rucha’s, based on what we’ve learnt throughout this semester, I see a story arc applied to the design process within mobile interaction design as:

ACT 1: BEGINNING – Used to understand and identify current habits of the persona 

Establishing Routine – Noting down the habits of the persona, what they do on a daily basis and within the context we are interested in investigating 

Inciting incident or trigger – Leads the user towards performing a specific action 

ACT 2: MIDDLE – Used to break down the current user experience and identify pain points

Rising Action / Conflict – User attempts to complete their task with existing mobile or web app or looks for existing infrastructure which can facilitate the task they wish to perform 

Crisis – Users are unable to efficiently or effectively complete their task with existing apps or technology they need is unavailable on the market 

Climax – Highest point in tension where users experience frustration or diminished productivity

ACT 3: THE END – Used to ideate and test potential design solutions 

Falling Action – User testing and design proposals are introduced in accordance with identified pain points 

Resolution – Creating and implementing a viable design solution 

I think that breaking down scenario building into more palatable parts will aid designers in better understanding and empathising with the user in the “beginning” stage (ie. understanding their habits and context), rather than immediately jumping into the issues they face and how they can be solved (“middle” and “end”). I think that this style of breaking down a design problem is highly applicable to mobile interaction design and can build upon the existing practices of personas and scenarios. Initially, I experienced confusion as to how the story arc differed from simply putting a user persona through various scenarios and Rucha answered my question. 

Building upon the story arc within the design process, I think that the idea of “adding a twist” like Rucha mentioned is one which is quite compelling. I think that, within UI/UX design, there are a lot of conventions to follow due to mental archetypes that users have regarding how a design should function based on a specific interaction. However, I also think that the interactions which become more fun are the more novel ones which reinterpret mental archetypes or create gestures or interactions which are still intuitive to the user (potentially because it draws upon something from the physical world – like how pinching to zoom in and out was inspired by origami folding). 

This week was about collating all the work we’ve done over the past few weeks and prepping everything for submissions. Because of this, we had a call every day of the week (Monday to Friday). Although this was quite a lot and a little bit tiring, it was necessary for us to meet, especially to record our presentation and ensure that different sections of the pitch document that we wrote individually flowed well together. In hindsight, we should have worked on the pitch document throughout the semester concurrently with our presentations and added to it as we continued through our design process. I feel as though this would have resulted in a lesser workload so close to the deadline and allowed for us to write about specific parts of the design process when they were fresher in our mind. However, we were still able to put together a solid and coherent pitch document due to our numerous discussions and our preparation for weekly in-tutorial presentations. 

One part of the pitch document that there was a lot of uncertainty around was the criterion which required the calculation of costs and market rates. As this was in a separate area of the assessment requirements document, we had not previously paid much attention to it. Hence, in the two to three days leading up to our submission, we were confused as to how we were to calculate costs and how we would even figure out current market rates. Further research was also confusing due to the numerous articles online which talk about different ways to charge for design consultancy work, and we were a little stuck at this part of the process. None of us had any design experience which required taking costs into account and none of us had taken a business class or even knew where to start. This was probably the first time all three of us had felt confused. This was not helped by the fact that we had been working on the pitch document for a few days straight now, and we were slightly fatigued at this juncture. In order to overcome this, I proposed that we each did our own individual research and came up with our own estimated cost table. This allowed for us to spend some time independently learning and researching, and later come together to see how our research and views varied / were similar. We were able to then create some sort of combination between all our proposals and research, hence working through our confusion and allowing for us to come up with something better and stronger as a team. 

Throughout the past weeks, one of my main roles has been to organise the information we have discussed into visually appealing slides and submit our presentation every Monday by 1am. From the beginning, I have ensured that our slides weren’t too wordy, flowed well together, and looked over the content before submission. The first week, I accidentally submitted our slides with the many other slides that came with the theme template (oops) but, since then, this arrangement has been smooth for our group. Having one person always responsible for the appearance of the slides allows for the presentation to be visually coherent and ensures that there is always one last set of eyes on everyone’s contribution before the presentation submission deadline. I enjoyed having this responsibility as it helped me engage with all aspects of each week’s presentation (even the parts that I wasn’t presenting) and ask questions for clarification when certain parts of my team’s contributions were slightly confusing. Additionally, as a design student, I felt like doing up the slides nicely was where I was able to best contribute, hence I think that this responsibility was both one that I enjoyed and one I was able to complete efficiently. 

This week was our last week before submissions, hence it was time to get down to business. As usual, we had our established weekly meeting on Wednesday morning, followed by two other meetings later in the week. In order to manage our time better and ensure that we were well prepared come our Tuesday submission time, we organised our three meetings as follows: 

Wednesday – Persona + Scenario 

Friday – Navigation Flow 

Sunday – Wireframes

This allowed for work to be divided up into shorter chunks of time, avoiding the need to stay on a Zoom call for four hours. It also allowed for us to individually digest the discussion we had as a team and we would often begin our meetings with a team member suggesting a blind spot or improvement we previously not realised throughout or discussion. This system worked well for us, however, my Thursdays and Fridays are entirely full every week with lessons and other group meetings. Hence, we agreed for only Jessica and Qing Ru to meet on Friday to discuss the navigation flow since it was important for all of us to stick to the plan we had set out. Because I was missing this meeting, I felt as though I had to do preparatory work in order to aid in their discussion. Hence, I worked on an additional navigation flow for the LumiNUS web app, as opposed to only having the current mobile app navigation flow to rely on. Although I couldn’t attend this meaning, I was able to put in some work beforehand to ensure that issues we had identified earlier, such as consistency between the web and mobile version, could be addressed within their discussion without constantly having to refer back to the LumiNUS website itself. Following our plan allowed us to be well finished with the content of our work prior to our Tuesday submission. However, we do still have our presentation slides, scripts and final pitch document to work on this coming week. 

As I checked back in with my team on Sunday, I realised we were easily falling into creating wireframes that reflected only minor tweaks to the preexisting UI. Based on the feedback from our initial presentation, our aim was to adapt the LumiNUS mobile app to quick on the go interactions and asynchronous learning, rather than make simple tweaks to the UI. As I brought this up to my team at this juncture, we had to be honest and upfront with ourselves regarding what we thought we were able to achieve. We realised that there were solutions to the pain points we had identified, but these solutions didn’t necessarily lie in our scope of improvement. One of the major pain points we had identified since the beginning was the lack of fluency between the LumiNUS mobile and web app. In our user research, this was also evident as interviewees stated that they wanted to be able to continue watching a Zoom call from their mobile to web device (or vice versa). However, we are not proposing a redesign of Zoom’s interface or trying to make Samsung and Apple products compatible. Instead, we reframed our line of inquiry into how LumiNUS can aid or facilitate fluency across devices. This allowed us to design solutions that focused primarily on the target user experience, whilst still appealing to the school as a main stakeholder with feasible design improvements. 

In terms of designing our wireframes, I had a lot to learn from Qing Ru and Jessica. The navigation flow they put forth, which was slightly tweaked amongst the three of us on Sunday, was what we based our creation of wireframes on. I have never done any form of UI/UX design before, hence was unaware of common tools / programs or how wireframes are meant to be laid out in a cohesive manner. During our meeting, we had a clear list of the wireframes that needed to be completed and the three of us worked individually on the same Miro board. The clear structure of what had to be done helped me target my contributions where I felt they were most beneficial and working side by side on the same Miro board allowed for constant affirmation that individual wireframes were cohesive on a macro level. This was very productive, as we could rely on one another to check the work we had completed and always ask questions that we were unsure of. Although I tend to be someone who enjoys working alone, I felt as though this arrangement allowed me to enjoy the benefits of working independently, whilst having the security of knowing I could always ask for help if I was stuck or that my mistakes would not go unnoticed. Furthermore, I didn’t feel any stress in terms of getting things wrong or asking stupid questions like I usually do when working in a more public setting, as my teammates were also focused on getting their tasks done too. Ultimately, I was able to contribute substantially due to my familiarity with Miro (as an Industrial Design student) and my deepened knowledge of LumiNUS as a whole after completing the current navigation flow of the web app. 

The first submission for our group this week was a presentation – which I felt was cohesive and fluent as all three of us worked on the slides and put a brief outline of what we were going to say into the speaker notes. This allowed for us to give each other feedback if they were saying something potentially convoluted or bring forth a discussion if some of the dialogue was conflicting between slides. Based on the feedback from Dennis on this presentation, we had a clear focus on our mobile asset of choice (LumiNUS) and, on the presentation side, there were no major issues in terms of group cohesion. I think that it was important that we decided to split the slides up between the three of us, rather than have one or two group members present the entirety of the slides, because it forced all of us to be involved and in tune with one another, hence we will continue this sort of division of labour. 

The verbal feedback from our presentation aided in directing our next steps, as Dennis was able to provide us with information about LumiNUS we previously would not have been privy to (ie. new technologies NUS is considering and the school not wanting to be responsible for providing certain services). This helped us to streamline our design process and put down some of the ideas we previously had as unfeasible – such as combining LumiNUS with UniVus, or incorporating NUSMODS into LumiNUS – and refocus our attention improving LumiNUS with the school as the main stakeholder in mind and current NUS students as the users whose daily experiences we are trying to value add to. 

A challenge I feel like we have been grappling with a little bit since choosing LumiNUS as our mobile asset of exploration is that we also fall into the user group of the app itself. Hence, we have inherent biases which often cause us to over generalise and extrapolate our own issues with LumiNUS to the entire target audience. When there is agreement amongst the three of us regarding a certain problem all three of us have experienced, it makes us even more inclined to generalise the issue to our user group. Hence, throughout our user research stage, I constantly reminded myself to approach user responses from a neutral standpoint. This can be difficult given that we were interviewing peers, but I think at least being mindful of our biases helped us in creating a more accurate and whole picture of the user research we collected. As we continue through our design process, we often have to keep eachother in check by reminding one another that our research should guide our pain points, instead of reverse engineering a solution based on what we feel as individuals would be most appropriate. 

Another issue that we didn’t foresee when choosing LumiNUS as our mobile asset of choice derived from the feedback session after our presentation. We understood that obvious user interface changes that improve the overall functionality of the app (which we initially proposed within our group) was an easy way out and not necessarily the solution to the issues we put forth. Previously, we honed in on how the experiences across the mobile and web app could be more consistent and fluent. Moving forward, we need to rather discuss opportunities that the app could provide regarding mobility, asynchronous learning, and informing a new type of academic experience. These were not questions we previously had addressed and spurred our consequent discussion when deciding upon how we were going to collect and synthesise data. 

Keeping in mind the potential biases we may have and our new more finetuned direction, we followed a ‘fly on the wall’-type approach to the collection of data, where we asked our participants to send in screenshots throughout their day when they were doing a school-related activity. We felt as though issues surrounding biases would be less prevalent when simply observing what another student uses their phone for in regards to school-based activities. Furthermore, by investigating students from a variety of contexts (eg. those living at home vs. those staying on campus) who weren’t necessarily users of the LumiNUS app, we were able to get a fuller understanding of what their mobile phone is used for in terms of broad school-related activities and also what they would identify as a school-related task. The feedback we received and our subsequent discussion thereby informed our user research, as we didn’t conduct research that would focus on quick UI fixes for LumiNUS, but rather what our target audience currently need their mobile phone for in regards to their university experience. 

06/Live Stream Event 2

Live stream event: 22 & 23 Aug from 3:00 to 5:00 am on Behance, hosted by Adobe Live

Host: Julian Crespo (Interaction Designer Star)

Guest speaker: Andrea Marquez (Art Director, UX/UI Designer @ZAGCreates)

Link: stream 1, stream 2

Background

Tonight’s guest speaker is Andrea who had studied graphic design and specialised in animation. She is a self-taught web designer and had learnt how to use Adobe XD through YouTube videos and Behance daily challenges. She is designing an app called Storyteller, which is a creative app that allows users to create and animate illustrations for their social media channels.

The live stream event was split into two days, the first day, she showed her design system, how to create abstract art on Illustrator just by using basic shapes and app design. On the second day, she went through the auto-animation function.

Being Organised

Andrea had an entire board that showed her design system, which flashed out all the fonts, colours, and icons that she was going to use in the app. While she mentioned that one can always add on to the board as they continue to create the app, it is useful and does make it more efficient to have at least the basic elements that one wants to use for the app. Both she and Julian also pointed out that having a design system would be useful for team collaborations as everyone would know what are the fonts and icons that are going to be used in the app.

Andrea had also suggested having a ‘junk drawer’ to just play around with. Here, one can test, mix and match, or try out different designs before filtering and seeing what works well. This promotes creativity as there is no fear of doing something ‘wrong’ or ‘ugly’ as it is like having a rough paper to do designs. One can organise this file after and clean up the designs and elements that have not been used. I find this to be rather useful since I am someone who when working on something would only like to put the final result when I start instead of having a bunch of random works around, I believe this would be useful when doing mid and high-fidelity prototypes in the upcoming project.

Auto-Animate Function

The auto-animate function is relatively new in Adobe XD and it essentially moves vectors for a certain duration with some type of effect. I found this function really useful as one can create a simulation video of how a user can use the app. To animate something, one has to duplicate the artboard (tip: all the layers and elements need to stay the same – if the layer names are different or there are new elements, auto-animate may breakdown) and change the shape, colour or size of the vector in the following artboards. Auto-animate will then look at the changes and transitions from one artboard to another.

Andrea had shared a few more tips regarding this function. The first is to leave the presenter window for the animation function open, making it easy to see what changes as one plays around with the different specifications under the ‘interaction’ and ‘action’ tabs. Another tip is that she likes to go through the video and then save it on her phone. This allows her to experience what the user would feel and evaluate the performance as the effect is different on a phone and a browser. One big difference in this interaction would be that on a phone, one would use their finger to tap the touch target which is far less accurate than a mouse which one would use on the browser, thus it is important to test and view the preview on one’s phone to ensure that touch targets are easily accessible by users.

Idea of Accessibility

Throughout both days, Andrea and Julian kept emphasizing on the idea of accessibility. She had brought up that during testing, one should test out the design of the app on different phones to ensure that they look the same or to cater for the physical differences of the phones (e.g. some iPhones have a notch, which must be designed around). They had also discussed touch targets and how to make it easier for users. Rather than making an icon or text a touch target, one can create a transparent overlay over both the text and icon, which would be the touch target for that function. This makes the target bigger and makes it easier for a user to tap. Julian had also brought up a guide (link) that he created to improve the accessibility of one’s app which I found to be a useful reference and a good supplement to what was discussed during lectures.

Visual Design Considerations

During the design review session, they had gone through designs of those who had participated in the daily challenge. During which, there was a design that used emojis along a slider bar instead of having text to denote the degree. Julian found this idea to be smart and mentions that nowadays, people would sometimes understand emojis more than text. This links to the lesson on visual design considerations where one can sometimes use icons to replace text. However, I do not really agree with Julian as I think using emojis to describe different degrees would only be understood if users are savvy with such icons. Generally, if the app is to be catered for the older generation, they may not understand the context and meaning behind the emojis in which case it would be better to just have text. Thus, I find that if emojis or icons are to be used, it would be more suited if the app were catered to the younger generation.

Conclusion

This livestream event was useful, and I found the auto-animate function within XD very interesting, especially since Andrea has a background in animation, she can create many beautiful animations and effects within XD seamlessly. Both hosts provided really good tips and points throughout the livestream, and while I may not agree with all if them, I think they are rather valid points and reinforce what we have learnt in class.

Here are the notes that I have taken during this livestream :)

05/Week 6 Project Post

Our project aimed to improve the user journey for Sephora’s new and churned users. We introduced a user profile section to provide more detailed recommendations to users and a tutorial guide for the Virtual Artist function. We had also streamlined Sephora’s user flow such that users no longer had to toggle between the product page and the Virtual Artist function, they could simply test out all their products in the Virtual Artist without having to go to other product pages. However, there are still some limitations to our solutions.

User Profiling

Although our solution introduced the user profiling function to users, they have a choice to skip this step. After skipping this step, users are unlikely to remember to go back and fill in this profile page, which limits their experience when using the app as they would not have recommendations which would be tailored to their needs and wants. This can be resolved in two ways – firstly, a push notification within the Sephora app to prompt users to complete this profile page; and secondly, a reward for users who have completed this form. Sephora currently has something similar where they give Beauty Pass Points to users who have filled in their personal particulars. Thus, to encourage more users to fill in this user profile and to improve their user experience, this solution can be applied to the user profiling section as well.  

Small Touch Targets

Another limitation is that the touch targets within the Virtual Artist could be too small for some users. The area where users can select the product is only at the bottom of the screen, this was designed so that the user can see their faces while they select a different shade or product that they want to try. But the shades that are shown at that tab are packed closely together and if the user wants to test many products, it can also become cluttered. Users may have problems choosing the specific shade that they want and accidentally click on another product.

04/Week 5 Project Post

For this week, I focused on creating personas and doing the storyboarding for the project. I decided to do this part as I felt that it was an interesting challenge to take on and I have never done anything related to this before. For this project, I created two profiles, one for new baes and the other for churned baes. I  followed the lecture slides and first created a table to plan out my character, after that I did a scenario, trying to make it as relatable as possible before drawing a storyboard to propose a positive user experience for both my characters.

Creating the Persona

Creating a persona was difficult for me, since I need a clear idea of what user I am targeting and the problems that they would face. I found that it is a lot easier to create a persona that I can relate to. For example, when creating the new bae persona, I based it largely of my experience in wanting to try on makeup in university, since I finally had the freedom to dictate my appearance. Hence, I was able to create a believable persona and allow that persona to have a specific attitude and motivation. However, when it came to creating a persona for churned users, I had a bit more of a problem since I need to think about what would make a churned user come back to Sephora. In the end, I chose to use the end of a relationship to motivate a user to start buying from Sephora again as people who break up often want to have a clean start and upgrade themselves. Thus, it is likely that these users would want to return to Sephora and start purchasing products again. From this, I learnt that, at least for me, I need to be able to relate to the user, even if it is just a very small characteristic or to a small extent, before I am able to branch out and create a persona from there.

Storyboarding

The storyboarding part was pretty fun since I could draw out the characters and have an idealised version of the user experience that the group wants to create. I enjoyed drawing a cartoon-ish comic to show how each persona would experience the app and adding captions below to explain the process. However, one issue I had was that I was afraid that the comic would be unable to convey the idealised user journey and used quite a bit of text to supplement each comic.

Conclusion