Design Event 2: CX/UX Mixer: Achieving Product-Market Fit

I attended an event hosted by General Assembly Singapore and invited speakers to share about how product-market fit is one of the most important goals for a startup and how it is one of the least understood concepts. Adrian Pica, a principal product Manager from Grab shared with us his experiences and focused mainly on the minimum viable product.

A minimum viable product (MVP) is defined as the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. The first step is to figure out the problem that needs to be solved and then start developing the MVP. The idea of the MVP is that you do not actually need to have the final product. You just need to have a method of proving that your product is highly demanded by the public. MVP is very crucial because it products do not work if creators just jump into a solution without getting users or demand for it.

MVP development is linked to the business model canvas, specifically the customer segments and value proposition. The product to be created has to have a proven value which different customer segments showing interest in the product.

Adrian shared about how Dropbox managed to capture investments through MVP. Initially Dropbox went through many pitching but were unable to get much attention from investors. However, the CEO realised that continuous pitching did not work if they could not show that people wanted their product. He did a demonstration video online about a version of the product that was not released to the public yet (Not fully working). The product proved to be useful as it gathered many viewers, and it gave him and investors confidence that the product is valued by customers.

Another way of proving product value without having the actual product itself is by using a landing page to test the value proposition. When a product is not available, it can still be “Faked” to be working. Imagine having a website that offer some services, the website gathers information and tracks the number of users entering their website. When users click sign up, and try to log in. They meet a “Sorry the product is not up yet, however, when it is up, you may use this discount code to enjoy some benefits as an early supporter!” message. It is a very smart way to test a product’s value and to check if its worth the effort to follow through and to build up the final product, at the same time, retaining possible future customers.

I feel that this is related to prototyping. A UI designer can create a prototype to prove that people need their application, without having to code up the final product. If the product is proven to not work, the company can just think of another solution without suffering much losses from hiring coders or technical people to build the product. Therefore MVP is very important in product designing and should be carried out to test if a product is worth making.

(Pictures of the event)

Design Event 1: UX and Bagels 7, User Personas

I attended a UX talk regarding user personas on the 27th of September. It was an eye opening experience for me as I learnt the importance of personas and how it helps with the design process tremendously. Personas are very controversial, where there are debates saying that they are not real or coherent (characteristics or needs of 5 people are summed up together). However, usually in the user research phase, there will be so many reasons and frustrations each user face that it seems very difficult to piece together a solution that fits all problems, therefore having a persona makes it much easier and guides you in answering the right problems.

The important parts of a persona are the needs/goals and behaviours. A persona helps designers in objectivising decisions, so instead of “What I think works”, personas will help to ask “What might work for Bob?”. The solutions that designers come up with will thus be unbiased and without influence from their own thoughts.

We had a short practice session about going to the supermarket to purchase groceries. The attendants were all split into groups and we all chipped in. We wrote our reasons for going to the supermarket, what groceries we bought, how frequently do we go to the supermarket, our behaviours while at the supermarket, what we disliked and many more. We realised that we had very similar reasons and we can group all these ideas together into specific categories, such as by convenience, preference of physical store rather than online, what we wanted to buy and by visiting frequency. We spotted that all the points we gave falls under the big categorisation of prioritisation. Some of us go because of convenience, while others go because they wanted to physically see the quality of the food before making a purchase. From the short session, I learnt that it is very productive to use sticky notes to conduct research as you can group them together easily and see where the main issues we need to address are at.

At the end of the talk, there was a networking session. I talked to a UX consultant and shared with him the problems I faced in conducting user research for assignment 2, and was curious about how they actually conducted research for their clients. He offered very helpful advice and shared that it is actually better to physically interview someone rather than doing survey as many people dread survey and may fill in falsified data just to get through the survey quickly.

A proper interview is way better in achieving quality data, however the interview must be made to be casual and comfortable for the interviewee, to allow a natural process of probing to occur. Sometimes when the interviewee is very comfortable, he or she may share things which you did not account for and might help in the design of the solution. Another thing the UX consultant advised is to have someone with you while you carry out the interview. Focus on asking the right questions while the other person should be helping you take down the important information.

He also strongly emphasised that I should prepare a list of questions which are suited for different scenarios. For example, “Have you used this functionality of the application before?” If the interviewee has never used even the application before, there should be countermeasure questions like “Why did you not use the application, tell me more. But have you heard of it? Will you consider using it now that I tell you it exist?”.

Overall the event has given me a clearer view of how the user research phase should look like and I hope to practice them in the near future.

(Some photos from the event)
 

NM3221: Blog Post (Week 6)

This week, the aim is to combine our designs together to come up with a Lo-Fi design that consisted of all the solutions to the frustrations that our personas have.

However, once we were done and placed our drawings together, we were astonished to see that even though we were all solving the same set of specific problems, the sketches we drew out were very different from one another. It was difficult to combine our solutions together into one final prototype. We did not know that we had very different ideas for our solutions.

For me, I wanted the Lo-Fi to be very simple so that users know what button to press next, then the users can filter the venue by region since there was a long list of venue, I thought that it was wise to split the list into 4 sections so they did not have to scroll through a long list of words.

However for Yun Ling and Kymberley, they preferred to have a map shown on the screen so that users can click into each area of the map for where they are interested to book a facility in.

Then there was the choosing of date, where Kymberley and I would like to be displayed in Calendar form, but Yun Ling would like to stick to the current application’s design.

To solve the disparity across our designs, we decided to take the good points out of each of our Lo-Fi and combine them together. After our discussion, based on voting and demonstrating how a certain part of our designs are logical to one another, we decided to use the map method for filtering venue, and used the calendar method for booking the date since these provided the users with the most ease when using the application.

Marcus Lo-Fi

Kymberley's Lo-Fi

Yun Ling's Lo-Fi

NM3221: Blog Post (Week 5)

From last week’s survey, we chose to work on the facility booking pain point. We started to come up with ideas for our Lo-Fi designs. It started off with everyone drawing out their own solutions. It was very difficult, as there were numerous problems in the facility booking feature and it is not easy to address all of them at once. We found ourselves stuck after drawing for a little while. Then we realised that we were drawing the Lo-Fi designs even before thinking about solutions to the problems.

In an attempt to deal with this, we revisited our survey forms. However, constantly scrolling through all the problems of the facility booking from the survey results did not help us either as there were quite a bit of data and they were not organised. We sorted the data out, and grouped them accordingly to each problem for the facility booking feature. (Example: all filtering problems are related to when choosing a sport or venue. Available slots problems should be grouped under choosing of date). Still, we were missing out on fully understanding how someone books a facility with the application.

In order to help us further streamline and understand the main problems users faced, we interviewed one of the user on how he used the application to book a facility as we realised that there was more information we wanted and we did not attain from the survey.

From the interview, we came up with a persona to help us understand the navigation flow in booking a facility. After understanding the navigation flow, it was way easier for us to sketch out the Lo-Fi designs than before.

         (Navigation Flow)                                           (Persona from one of our surveyors)

 

NM3221: Blog Post (Week 4)

The aim for this week is to choose a pain point from the ActiveSG application to work on. We know that the application is not perfect and to validate our point, we implemented the Empathy part of the design thinking process to gather data. It is important in helping us to discern how and why the users use the application. To learn more about our users, we created an online survey with a list of questions to analyse and understand the different aspects of the application that they like and dislike.

The difficulty we faced was coming up with the survey questions. The questions has to be short and easy to comprehend so as to not discourage the users from completing the survey. We included screenshots of the application to make sure that the surveyors are on the same page as us. We also kept in mind to set the questions in an unbiased way, so that the users’ choices are not influenced by the way we set them. This ensures that we receive a set of accurate data.

To aid us in creating the questions, we first listed out some broad questions that filtered the surveyors into two different groups. The ones who has used the application before, and those who did not. This broke down our problem significantly and provided us with more ease in setting up questions related to specifically the user experience of the application. With that, we then proceeded by linking one question to another depending on their previous choices, to get specific details of what they thought of each functionality. To end off the survey, we chose to collect demographic data to identify the community we are targeting which is essential in our future design improvements.

Some screenshots of how our survey looks like:

NM3221: Blog Post (Week 3)

Deciding on which mobile/web asset to evaluate is not easy. The approach my group took was to list out all the mobile applications we commonly used and then try to find specific details we did not like on the applications. It was difficult for us as we use them everyday to the point that we are so used to their designs and interfaces, everything seemed so flawless to us. Another problem was that a design flaw for one of us, did not seem to bother the others. All of us had different opinions on our user experiences on the different applications which made it difficult for everyone to arrive at an agreement.

It took awhile, but we finally decided to evaluate on HackerNews application. The application is very popular among people in tech. The purpose of it is to share content that is interesting enough for people curious of anything tech related. We decided on the application as we found it hard to follow the specific tech news we would like to read about. News are not categorised, and depending on how many upvotes an article has, it will be pushed to the top of the screen. What if we are interested in something, but it got lost somewhere at the bottom of the screen? The application is similar to Reddit, but even Reddit has different subreddits which groups a certain topic and makes it easier to browse news of a specific type a user is interested in.

I realised that it is much easier to study an application’s design by finding out why the application was created in the first place, then experiencing the navigation and layout of it like how a normal user would do, to perform a certain task.