jarvjarvbinx

[jarvjarvbinx]

Live Event 1: Google's Design Sprint: Design Sprints for Impact

On 30 September 2021, I attended the live event Google’s Design Sprint: Design Sprints for Impact which helped introduced the weeklong design sprint which is a tool to help teams go through a mini design process under time constraints which help businesses quickly make decisions and prototype new ideas without much risk. Evan Dror was able introduce the concept quickly and expanded on the idea that design sprints can help to create an impact. Overall it helped shed greater insight on the design process that we have learnt in this module and showed how we can apply that under different circumstances such as under time constraints. Evan talks about how Human Language often is unable to describe a complex world that we live in and that as human beings, we easily fall into traps that make it difficult for us to come up with new ideas or generate solutions that could have an impact in conditions of uncertainty. We may succumb to areas that restrict our idea generation as we have confirmation biases, focus on short-term emotion, or follow groupthink. These all impact how we approach problems and how we come up with new ideas. As such, he states how Design sprints help to alleviate pressure by creating an environment that promotes idea generation with quick feedback and to iterate quickly without much risk. I think this particularly showed how it is important that in the design process, we do not restrict ourselves so that we can look at problems with a bigger picture. In the early lectures, we have learnt about design thinking and how we should expand on problem solving.

From the lecture, we saw how the design process had a few stages such an Empathize, Define, Ideate, Prototype, Test. It was interesting as we often think about the design process on a single problem that could span months or years as teams develop their solutions, akin to application development, but with design sprints, it takes participants through the process under a confined environment, and they are able to create new ideas and solutions through it. Its interesting because it shows how this process is scalable, and more importantly, it can show how we can go through multiple cycles of this process which helps build a bigger picture.

Evan then shares about the design sprint process and what is usually done during the week. Starting from thinking about design experts, to gathering preliminary data, quick idea generation, sketch, and prototype, and then gather feedback – all of which already happens within the first half of the sprint. There was an emphasis on the idea that we can explore new ideas and prototype quickly as there is not as much risk, and this helped us expand and not restrict us.

Some timed questions that helped us empathize and define problems that Evan went through included making us sit through an expert interview and generate questions by thinking of “How Might We’s?” and “Can we really?”. The expert interview helped reinforce some of the user research techniques learnt in this module. Particularly how an expert interview allowed us to find user problems as we empathise with the user or expert. It allowed us to find potential areas to improve on and as not the one conducting the interview, we could focus on the answers that the expert provided and the problems they faced and ask ourselves How Might we? Following, we went through thinking about a possible optimistic future following the problem areas we initially discovered. This helped us generate a long-term goal and think about its impact on the world. Some interesting impacts included “In 2 years, cities may be less crowded” and “In 2 years, People are comfortable with working remotely when everyone's given a choice”. The next task was then to think more pessimistically through questioning “Can we really?” This led to interesting questions which helps us to generate “what can we test with users” – ideally, the important features we need to focus on for user testing. An example used was “Can we convince users to pay for this brand-new thing?”

Overall, this really helped provide a new way to approach thinking about problems and focus on what needs to be done in the design process. We are defining what features should our solution have, think what areas that we can help solve and finally what is crucial to test. This defining step really provides a guide on what we need to do next in the design process. I will use this approach more in the future as it helps to breakdown bigger issues and generate a roadmap.

He also went through user testing and an interesting way he presented data included this colour coded table. I think it was a good way to get an idea of the effectiveness of our prototype and is a quick way to get an impression of the user testing. All of which is done during a design sprint!

As he went through more steps, I was able to learn more about the benefits of a design sprints and provided me with more tools I can use on my own too. He helped me be more confident in the process and piqued my interest in attending a design sprint in the future too. I think it’ll be a great learning opportunity!

[jarvjarvbinx]

Live Event 2: Designing Experiences around the User by Mobile UX London

On 28th October, Designing Experiences around the user by Mobile UX London featured 3 speakers who presented interesting topics on new developments in Interaction Design and thinking about the users’ journeys and needs. Each speaker offered new insights and emphasised the importance of the user and how they interact with interfaces. The first speaker talked about Design Systems, the second speaker talked about user acquisition through forms and chatbots, and the final speaker talked integrating different applications together and how the user journey can shape decisions.

The first speaker offered valuable insight towards the importance of a design system. He talked about how a design system involves not just the design, but code and documentation. In a team workflow, and when working with different people, a good design system helps to not only bring everyone together, but can help quicken timelines, and create a more cohesive and consistent interface. It was interesting as he talked about how a design system itself is never fully standardised and final. As teams and employees utilise the design system, it is always open to iteration and that is how these design systems grow. The usefulness is boundless as other employees and teammates can build upon each other and make components that are more streamlined and efficient. I think it is interesting that when we think about the design process, we can sometimes limit ourselves to iterating within projects, but in a team and business setting, the design process of iteration is always ongoing, and can even apply to design systems they themselves use. This helped me appreciate the idea that we are always working towards improving different ideas and systems that we use.

The second speaker talked about user acquisition and how in the world today, it is has evolved over the years. He mentions that users are never willing to fill in a long form and it is important for designers to minimise the interaction to increase the chances of a user sticking to a company’s website or offer their particulars. The entire system of user acquisition has become more streamlined to reduce the number of clicks it takes before a user gives the company their information. It is an interesting development as he brings up the idea that users just giving their email addresses is often still a good thing over collecting as much data as possible, as it offers the company other ways of reaching out to the user. Building upon that, he brings upon the idea of chatbots and its increased relevance today. As more companies integrate chatbots onto their websites, he states that chatbots are really just ways for users to fill in a form. The only key difference is in the expectation and feel when the user interacts with a chatbot. A user is more willing to click on buttons and talk to a chatbot as they feel as if it is a more real connection and less of a clinical feeling of a form. The pauses that a chatbot takes before replying feel more natural and allow the user to feel a connection and as if it is a real conversation. This is particularly interesting as it shows how important it is for interactions to feel like human interactions themselves. Users are more willing to spend time with a system if they can connect with it. He then also states that down the road, as more companies take businesses online, that’s where the human touch and customer service can become more integrated. From this module, we learnt to think of a user’s needs and how can we make interactions more accessible and efficient. As we learn to put ourselves into the shoes of the user, we must not disregard the aspect of a human connection and what the user feels. The user is more willing to go along with a system that feels more natural and with a system that is less like a separate entity. In that way I think it I manage to learn that applying our user centred thinking could be thought of more widely.

The final speaker offered insight towards context switching and user journeys. His presentation was based of the idea that we often use applications that are isolated from one another and that there is much time wasted as we switch between applications and contexts. How we can waste on average 37 seconds per context switch and that often “Functionality is organised around applications rather than user journeys”. His last statement stuck with me the greatest as, as users, we often work within applications as their own systems without thinking about the greater eco-system. We may have different application for different needs, but we do indeed spend time when we need to switch between applications like banking apps to calendar apps and to email apps. The disjoint of passing information between applications cause a rift between user experiences. He talks about the different ways different eco-systems use to work around this: namely a monolithic approach versus a suite of apps approach. Where a monolithic approach is often a centralised system which houses all functionalities of the eco-system, a suite of apps allows for smaller applications with specialised functionalities. He then talks about the advantages and disadvantages of these approaches before coming back to the idea of context switching. He brings up ideas that monolithic systems often end up looking like monsters of lost functionalities and haphazard add-ons, while suite of apps can suffer from companies simply creating a multitude of applications with very specialised functionalities, which can create disjointed eco-systems and just, too many applications (like a Christmas tree). So, he states that the best way is still the suite of apps, but a nuanced approach. The importance of maintaining a design language and ensuring there is no unneeded application and minimising context switching. He states that that is why the user of user journey maps are important. It helps to minimise context switching by allowing designers to fully delineate functionalities of applications while knowing places that require passing of information. I think as a student, it is often hard to think about the purpose of a user journey map outside of brainstorming but seeing it in this context provides me with a greater appreciation of its usefulness.

[jarvjarvbinx]

Week 6 - In Conclusion!

For Week 6, we finished our first project 1 with a presentation and our final submission. This was a tough week as it involved creation of our low fidelity wireframes and cleaning up our final submission. As time was short, we had to focus on creating wireframes that could show how the overall experience of using Digibank could be improved. We had many ideas, but we had to pick a few that could best reflect our redesigned user flow and cohesive system.

We went back to creating a proposed user flow to better understand how our ideas could simplify the user interactions. As such, we recognised the mental model mismatches that came right from the start screen and that also caused convoluted user flows in the process. Our analysis of the current user flow reflected that though the user had many options for them to use and explore, the overall system was too messy and often led to a feeling of the interface being cluttered. It was an interesting learning point as often we think that by giving the user many shortcuts or options for them to choose and tap on, as an effort to give them quick access and to customise their interaction with the software, it often can lead to more confusion if the user flow does not make sense or fit what the user thinks is right. As such, our group wanted to create a more streamlined user flow that resulted in a PayNow section that was more functional and comprised of parts of the transfer system that users need while using PayNow or Scan & Pay. We combined features that made sense to be together in the user’s mental model and gave simplified the user flow into a more directed one. In addition, we gave increased functionality so that users are compelled to use POSB Digibank over competing mobile payment options. This came from the realisation that Digibank often lags other payment options, and we aimed to increase functionality. Despite Digibanks efforts to create a focused user interaction with a feature, in this case the PayNow section which had only a singular focus of creating PayNow transactions, this caused the overall experience to feel rather bare bones in comparison to other mobile payment options. This led to my discovery that often, though the intention to create an easy to use and understand feature, we may also need to acknowledge other needs of our users. What benefited competing mobile payment options included features such as easily checking of your payment transactions, or easily accessing recent transactions so you can make an additional payment. Features beyond just transferring adds to the overall user experience on top of being seamless. Therefore, our group intended to create a more cohesive PayNow system that could stand on its own. For me, I believe that it is important to recognise an intended interaction in its context. Often when making a PayNow payment, outside of just making a quick transaction, if we were to understand the context, we can often create a better overall interaction system: we can see that we may want to check what our latest transaction was, to who and how much, when we are out with a group of friends for the day, we may need to make repeated PayNow transactions to the same people as they pay for the outings meals or activities. As such, if we add features that could benefit the user while thinking about the contexts they are in, we can create a richer experience. As such, we included features where it makes it easier for users to add each other as recipients, a PayNow history sections, and a recent recipient section.

Finally, as our project came to an end, we had to package our entire project neatly and I was able to see how our efforts over the weeks came to fruition. An interesting project which was not entirely easy, I was able to explore the idea of building on and analysing designs. It gave me a greater appreciation for a lot of unexpected interaction and design decisions that were already made, and I had to learn how to think more broadly when it came to design. As we concluded, I continue to wonder if our solution proposed was enough in terms of simplifying and enhancing the user interaction. In fact, we recognised that we had to make the compromise of increasing the number of taps to make a payment, but we made this conscious decision now as we felt it gave users a clear path. Only with testing and further analysis down the road can we see if this was a smart decision. For now, though, I am proud of what our group has come up with and we all recognised the importance of iterating on ideas and continuously taking in new information and improving.

[jarvjarvbinx]

Week 5 - A Struggle to Create

For week 5, our group aimed to complete our brainstorming and wireframes for our project with Digibank. Our group faced a major hurdle as we struggled to generate new ideas and create a solution that could benefit users. We learnt many things about redesigning an interface and the importance of discovering new ideas.

Our first major hurdle came as we gathered this week to brainstorm possible solutions for the pain points we uncovered previously. This mainly stemmed from a realisation that the Digibank application is, in all fairness, a relative streamlined and intuitive application already. Launched in 2016, POSB and DBS has been iterating and continuously improving the interface of its application. They listened to user feedback as they respond to some user reviews, and we can see that they constantly update their application with security and interface updates. The result is a robust application that can already stand on its own.

This left us with a much harder job as we realised that building and improving their interface is much more difficult as there was no one clear solution outside of simple UI changes. This project not only stretched our group’s skills as we tried to propose to each other solutions beyond the basics. For me, it helped emphasise the importance of continuous iteration and that it is important to listen to feedback. As a case study, Digibank showed how they could build a mobile application over the years and each update built upon each other to create a good application already. We all agreed that Digibank is good on its own.

However, as part of our project, we decided that there is still stuff that can be improved upon. Otherwise, why are there still these pain points felt by users? We took a step back to analyse the problem more broadly we felt we may be too focused on the simple issue of using the PayNow and Scan & Pay function. We fell back and revisited our User Profiles and Personas to understand from their perspective the pain points that we previously came up with. This is where we saw a starting point for improving the payment system as a whole. We first analysed the current user flow and found the common frustrations from using the payment features, and we looked at other mobile payment options and asked ourselves: “why do people choose these applications over the built in PayNow function?” This act of widening our scope and discovery allowed us to firstly identify areas in the user flow that could be improved upon, and to possibly create a more streamlined application. This is where I realised that these User Profiles are indeed useful in helping us generate new ideas. We were able to look at the problem from an increased number of angles and we had some progress in creating a better solution. Not only did it help us empathise with the user, but it helped us broaden our brainstorming session. In the design process where discovery is important, I believe that we were initially too tunnel visioned on the simple answers in front of us. As such, it was quite beneficial to utilise these tools while generating new ideas.

Afterwards, we were able to finally create some low fidelity wireframes that showed our vision for a more user friendly PayNow section. A hard week as we were stumped for a large part of it, relying on tools and taking a step back definitely helped our team, and I think it shows how important it is for us to continuously learn from all sources!

[jarvjarvbinx]

Week 4 Reflection - Starting our Data Collection

For week 4, the main topics we covered were on data gathering and analysis. For our team project, we decided on the approach our team would take on gathering data for analysis of our application. We determined that we could use of both online reviews and interviews to gather data on Digibank.

However, we had to consider the benefits of either form of data gathering. For instance, we saw that online reviews tend to trend more negatively. We attributed that to users mostly only leaving reviews if they are ever frustrated. Happening less so when users are content with the app. For Interviews, we recognised that with the short amount of time, we would only be able to gather data from a small sample size of about 4, so we would not have a very diverse or conclusive data on the general population. Yet, there was much benefit from still gathering data. I believe that when we can be objective and recognise biases in our data collection, we can afford to still pick out valuable information on issues users face. For instance, online reviews, though negative biases, still represent many user frustrations. By taking apart emotional aspects from reviews, we might be able to see the root cause of their frustrations. For interviews, we can still gain an insight on real user data and see first-hand how other users may interact with the application. This is how my interview helped widen my mindset on Digibank and data collection.

I conducted a Retrospective Think-aloud Protocol for my interview. My interviewee was a 53-year-old working female from the hospitality industry. She was familiar with Digibank as it was her main source of banking but also used Citibank for her credit needs. Going through the interview, I realised a few things, notably that, as a “user”, what we may find difficult with the application may be different for other users. For instance, we had the initial presumption that users may face issues with the PayNow function, yet my interviewee felt no such frustration. What I encountered was the opposite of what I originally anticipated. The interviewee was in fact quite satisfied with the application and was able to use the Digibank quite intuitively. As I gave her tasks to complete, she breezed through them. I was shocked that a user was able to navigate without any frustrations and that differed from my presumptions. As such, instead of asking for issues from the Digibank app, I shifted my scope and widened it for the interview. I began asking in comparison to other applications, what differed and were there any problems faced. This is where I was able to gather much more data. I saw first-hand that as designers, we must keep an open mind. It is important for our interview questions and directions be broad enough to allow for us to gather data without any bias. In this instance, I had to modify my questions in real time as I asked more about what makes Digibank good versus what frustrates her when using the Citibank app.

On top of that, it showed that our users are not one dimensional and that as designers, we should not assume what user’s may think about when using a UI. If I stayed on, probing only on the interface of Digibank, I would close myself to opportunities to gather valuable data. There is a vast amount of information to be gathered from outside sources as well. By learning from the pitfalls and strengths of others, I could distil what is important for a mobile banking application. In fact, I believe that by encountering a user that challenged my own preconceived notions and opinions on Digibank, I was able to gather much richer data in that we now know how to focus more on the areas that could improve Digibank’s Interactions.

[jarvjarvbinx]

Week 3 Reflection! A Promising Start!

For Assignment 2, we are tasked with completing a case-study on an existing mobile application or website. This is to help introduce us to the design process and allow us to practice analytical thinking on design. As this was our first tutorial and our first time meeting our groupmates, it did take a while for us to get a groove and work as a team. In tutorial, we were able to brainstorm ideas based around our experiences as a student in university. As we shared one by one, we realised there were some ideas that were similar to each other and some that were very different. As a group, we faced some issues in trying to distil the experiences we all faced into a core problem and while at the same time trying to tie in other ideas that initially seemed completely different. In our case, as many brought up the experience of not being able to socially interact like we used to before the pandemic, we used that as our main problem to be solved. However, we were not able to see that this problem could tie in other experiences mentioned by other members. We needed to think more broadly about the problem so that we could generate more ideas and solve more issues. In fact, a lot of problems could be tied together or linked purposefully, all of which could help us explore more.

Following the tutorial, we met again on another day to work on the group project together. Here, we started by sharing possible applications that we could use as case studies and create redesigns for them. As we discussed the possibilities, I think what helped us narrow down our choices was by defining what we should look out for. We then decided that we should not pick applications that were too obscure as this would make it difficult to collect data. Another example of our defining search was that there is a possibility for redesigns. We should not pick an application where there could only be one good solution, but rather pick an application where we could truly explore new ideas. This helped us narrow our focus. One thing that also helped our group meeting was to think from a user’s perspective. We thought of the impact the application has on different kinds of people, be it the young or the old, the literate or those with disabilities, so that we could understand more the common problems these people could face. As we started to look at these applications with the viewpoint of the elderly, for example, we better understood that they may have issues with learning how to use the application and may be too intimidated by the information overload presented by the application. This allowed us to get a better sense of need to redevelop the application as it could help a greater audience. I believe that by trying to empathise with users outside of ourselves, we saw more potential areas of improvement. As designers, it is important to be able to think broadly of the implications of your designs. What may fit one demographic, may not be useful for another.

As such, our team was able to decide on the application that we wanted to focus on for this project: the POSB Digibank Application

[jarvjarvbinx]

First Blog Post!

Okay so for this semester and this module, I’m starting this blog so to document my journey in NM3221 and as part of the module requirement. I’ll be sharing some insights every week on projects and anything interesting I’ve learnt!

Hopefully there will be at least some interesting content here over this semester and I hope I provide an insight to my journey with NM3221!