Reflections on Mobile Interaction Design

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. 

This week was our group’s very first meeting and our very first time even finding out who each other were. I’m not sure if having an even mixture of students from different faculties within NUS was deliberate, but knowing that Qing Ru is a CNM major and Jessica studies computer science definitely soothed my nerves a little bit and made me excited to work with students from varied academic backgrounds. Being an Industrial Design major can often feel a little self-insulating, and having the opportunity to work and collaborate with people I traditionally would have never met excites me for the next few months in this module and the next couple of years in completing my IMD minor as a whole. 

Through a short initial interaction after our tutorial on Tuesday, we were able to plan a set time for weekly meetings, complete some empathy mapping (which served as a good ice breaker), and get to know each other a little bit. Since the Industrial Design cohort is so small, I have still had face to face classes for the past year. With some of my classes being face to face and others still being held online on Zoom, I have definitely realised the impact that online meetings can have on, not just learning, but group work. Although it wasn’t awkward working with Qing Ru and Jessica over Zoom, I find that it is a lot easier to gauge people’s emotions and better understand other people’s ideas when meeting face to face, as there is less room for a social misstep. Our meetings on both Tuesday and Wednesday were productive and fruitful, however, in the future, if I feel as though meeting online is a hindrance to our progress (and there isn’t a resurgence in locally transmitted COVID cases), I would like to recommend to my group mates at least one in-person meeting as I feel like it will help us in creating a more cohesive group dynamic. 

As this week was our first ever meeting and next week’s presentation workload wasn’t one which was very taxing, we were able to complete the required work within a one and a half hour session on Wednesday morning. Wednesday morning was the only time all three of us were free to meet, and we had an efficient discussion in terms of deciding which mobile / web asset to explore further. By using our Miro board, we were able to take stock of the ideas we had and easily create and sort an assortment of potential pain points. This visual representation of ideas aided in our final choice of mobile / web asset to discuss further (LumiNUS), as we were able to see which idea we had created more pain points for and easily take stock of the direction our discussions were taking us. The Miro board was such a helpful tool, and I think we will continue to use it throughout this project, especially as one of us would naturally take minutes / condense other people’s ideas while they were presenting. This was efficient and helped all of us to stay engaged in the discussion in ensuring we were understanding one another’s ideas. 

This week was a positive and productive one, although it did take us a while to figure out a time slot in which we were all available for another meeting. There was quite a bit of verbal back and forth where someone would suggest a time, and someone else would say they were busy, which made the initial call feel counterproductive and as though there was no timing in which we were all mutually available. After a few minutes of this, Jessica stepped up by sending a https://www.when2meet.com/ link to our group chat. I had never heard of this website and, within a minute or two, we had a clear visual indicator of potential timings for meetings. I’m happy that (1) I now know that this website exists and can use it for other projects in the future and (2) I am able to learn from group mates who are more experienced (in terms of time spent in university) than me. Jessica providing an efficient and effective method of reducing confusion, even to solve a simple issue, was a learning point for me and I look forward to learning more from my peers and enriching myself as a valuable team member. 

We also discussed how perhaps our Wednesday morning meeting time is not ideal (as our tutorial is on Tuesday afternoons), and there may not be enough time for us to adequately prepare for discussions after receiving the next steps to take in our assignment only a day prior. Hence, we were able to agree that Wednesday mornings would be our tentative time slot for meeting each week and, if need be, another weekend meeting could be thrown into the mix to allow for further discussion and added preparation time.