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.