Jullya's university projects

[jullya-ux-uni]

Networked devices (IoT)

Carrie has been living alone for a while. She and her friend Todd have always wanted to move in together. It made a lot of sense, as they have been inseparable for as long as Carrie can remember.

In fact, whenever she uses her iLenses to access her early life memories, Todd is always there. They often sync up the lenses to watch movies or play video games together. 

So when the day finally came, they were both very excited. They helped each other carry in their boxes and started to arrange the furniture. Carrie pushed the sofa to the corner, because that is how she had visualized it when she looked at the 3D floor plan with her iLenses, but Todd suggested having it by the window for better lighting. The two friends were having so much fun moving in, they had not noticed that it had already turned dark. Carrie accessed the home settings through her iLenses and turned on the lights above her in the living room. “It’s been a long day” she says “I am going to freshen up with a shower and then head to bed”. She started making her way to the bathroom and as she walked, the light bulbs would lighten her path and turn off as soon as she passed by.

The iLenses adjusted the water temperature in the shower according to her body temperature, so the water felt just right to her skin. As she is showering, she receives a call from her grandmother, but she pushes it away from her sight by moving her eyes to the side, similar to swiping. She thinks to herself “Grandma probably is just calling to ask how to make the Lenses work, for the millionth time. She’ll figure it out.” As she pushed the call away, her eyes focused on the towel rack. She forgot to take a towel with her. She turns off the shower and shouts for Todd to bring her a towel, but there is silence in the air. 

She gets out of the bathroom and makes her way to her room. The lights in the corridor strangely do not light up her way, and she has to do it manually. She never had to do this before, so she has no idea where the switch is or even how to work it. She tries calling grandma to ask about it, but the iLenses cannot get the call through. She screams out for Todd, but still hears no reply. The darkness in the house makes sleep get the best of her.

The next morning, she wakes up to a big red alert in her sight. “Reconnecting” says the large red letters. She looks around and the letters are over every electronic equipment in the house. The light bulbs, the shower, the toaster, the door lock...nothing seems to be working. No sight of Todd yet. Until...a video of a live news broadcast appears in her vision: “Network error causes major terror in the country, millions panic”. It is then she realizes. She’s still living alone. Todd was never real, but a figment of her imagination, projected by the iLenses.

Question: Will we get to a point in which humans depend so much on technology that we won’t know or will forget how to do simple tasks, or even lose track of reality?

[jullya-ux-uni]

Gestural interaction - UX & Technology

I personally have been on a never ending war with one particular service/product. Although I do see how it being contacless can be a lot more hygienic (specially during trying covid times), it just never seems to function when I want to. Ladies and gentlemen, I present to you: A complaint on sensored toilet flushes.

On paper, the idea behind the experience is pretty natural and straightforward. One feels the need to answer nature’s calls, finds a nice and clean stall, sits, does what they need to do, cleans up, and look at that! No need to touch the yucky flush because as soon as the pants are up, the sensors know that one is no longer sitting down so they must have finished. It then triggers the toilet to flush. Except, it does not always work that way. It actually rarely does. I lost count of how many times I encountered dirty bowls from the previous person because the flush sensors did not go off, or how many times I felt splashes of bowl water on me the second I went in the stall because the sensors thought I was leaving the stall, or how any slight movement caused the sensors to make it flush, regardless if I was done or not.

Just a quick search on automatic toilet flushes gives you several images of users trying to “hack the system” and stop the sensors from flushing before they are finished. It is quite unbelievable how far some people have gone just to prevent them from having such bad user experience when using a toilet!!

Image above - wet toilet paper is used to stick to the sensor and block it from flushing)

Other types of “different” toilets (different = not the normal hand flush type) that directly pop into my head are the infamous Japanese toilets. Japan is the country which has put a lot of thought and development into their toilets. Multiple buttons and attachments provide the users with all kinds of services for a pleasant experience. Some are even linked to an app, so that they can control all the features from the users’ phones, including the flush.

This gets me thinking, what will be the future of toilets like? It seems, from the awful sensor flushes, that people are trying to modernize it somehow. 

My question is: Is the goal to make the experience completely hands-free? It seems like the least touch or contact, the better. So is a mobile app the way to go? Or could the sensors simply be placed somewhere else, eg. weight sensors on the stool, and that would be enough to change the experience? It is something that requires more thought to be put on it, to idealize better ways of providing a good experience.

Sources:

https://web-japan.org/kidsweb/hitech/toilet/toilet04.html

https://www.reddit.com/r/lifehacks/comments/6yupyc/automatic_toilet_sensors_flushing_on_you/

https://en.wikipedia.org/wiki/Toilets_in_Japan

[jullya-ux-uni]

Final Reflection

Throughout the course, I have used several prototyping techniques, such as paper prototyping for a smartwatch and mobile fitness application, as well as non-visual prototypes, or sounds, for the same devices. For this I have used a program called Audacity. I have also used Figma for wireframing and creating high-fidelity prototypes. Figma also came in handy when creating the two tests for A/B testing. Lastly, to build the wizard of oz prototype, I used Processing, in which I coded the interaction for my users to try out. Also, due to the current restrictions, I had to use online calling programs such as skype and teams to test some of these prototypes.

Overall the experience of trying such different mediums to create and test the prototypes was afun experience. It is very motivating to leave the screen work for a little bit to do some hands-on work, especially if it is to test if it will work out and if I was on the right track, like in the paper prototyping, which made me realize that what is obvious to me as a designer, might not be so obvious to the users when using my products. 

For most prototyping techniques, I would use them around the middle towards the end of the design phase. This is because most of them are very evaluative and have distinctive purposes, providing ways to judge actions in various terms. The only technique I would possibly use at the beginning of the design phase would be the wizard of oz prototyping technique, since I see it as a way of trying out ideas and how the users would like it if it actually existed.

[jullya-ux-uni]

Experience Prototyping Assignment - Wizard of Oz Prototype

Describe your prototype, reflect on the making of your prototype and the prototyping technique (Wizard of Oz) in general

For this assignment I had to create and test a prototype for a new concept for a playful social distancing interface that uses projection mapping and (faked) camera and/or other sensory input.   The criteria for the prototype are as follows: - work with a video projector.   

- project interactive animations and/or images onto a floor, walls, objects, people or a combination. - use body movement/presence as (faked) ‘input”. What I decided to make was “Go Throw”, a target game in which users would throw a ball to a wall, attempting to hit a target that appears and disappears randomly. The target would be made with processing, so that I could control its movement from behind the screen. I used a beamer to project the running code onto the wall. The idea later developed into fetching a small dog stuffed animal/figurine onto the target (shaped like a ball) and was renamed to “Go Fetch” as a joke, since normally it’s the ball that is thrown to the dog and not the dog to the ball.

The initial idea sketched:

Materials used: - Laptop - Projector - HDMI chord (2 meters long) - Stuffed animal dog figurine Source Materials: - Processing Overall, the most difficult part of making the prototype was actually coding the target from scratch. It had been a while since I used processing, so I took the first couple of days to get reacquainted with it before I started attempts at coding of the prototype. Coding is something I struggle with a lot, and something I am not a big fan of, so to be able to make this form scratch, especially after a while of not using Processing, and managing to get it to do exactly what I wanted it to do, it made me really proud.

Setting up the Wizard of Oz prototype also required some thought. The choice of materials was a very important element that I had to take into consideration. Since “Go Fetch” required movement and throwing objects around, I did not want to harm anyone or break any objects. So in general, when making a Wizard of Oz prototype, it is not only important to think about what and how it will be built, but also where.

Another factor that impacted speciafically my prototype was the time of the day in which I tested it. Because I was using a projector and did not have the means of making a room dark enough for the projected images to be visible, I had to wait until it was night time and dark to test it out. This, of course, limited the number of people that could try out the game. Not something I had initially considered. 

I had also realized while carrying out the test that I had not written the instructions for the users anywhere. I had to verbally exaplain how the game worked. So clarity is another important thing when it come to prototyping in general, not only for Wizard of Oz prototyping.

Include a video of your prototype test

LINK TO VIDEOS HERE

Include pictures of (the testing of) your prototype

Include prototypes source materials (code, files, images etc.)

Code for Processing: int x = 0; int y = x*1; int xPos = 1800 ; int yPos = y+800 ;

void setup(){  //size(2000,1000);  fullScreen();  background(255);  frameRate(9);

}

void draw() {  fill(255, 0, 0);

 //ellipse(500, 250, 200, 200);  //ellipse(random(0,1850), random(0,850), 200, 200);  if (keyPressed) {

   if (key == 'a' || key == 'A') {      background(255);      ellipse(random(xPos), random(yPos), 200, 200);    }

 } }

Screenshots of code when running:

Once key is pressed, the ball changes position

Once again, ball changes position

[jullya-ux-uni]

Building Engaging Prototypes Exploratory Prototyping Assignment

Topic: Picture Superiority Effect

Hypothesis: Would users remember food items that they have purchased if the options in the menu are presented by pictures rather than words? The Picture Superiority Effect tells us that the users presented with the images of the menu are more likely to remember what they ordered. However, I believe that a descriptive text can also help users remember their order, making them be just as good as remembering as the users with a picture menu.

Variable:

Some users will be presented with a “Thuisbezorgd” inspired menu setting with pictures, while some only with words.

Test plan:

Do A/B Testing

Split users into groups: Extensive Picture Menu and Extensive Word Menu, WITHOUT THEM KNOWING.

Present them with their respective prototype and ask them to pick 3 meals (main course + drink + optional dessert) as if they were ordering food for themselves and their friends or family.

Once they are done deciding what to eat, have a small chat with them and after a few seconds ask them to call out what they have ordered.

Time how long it takes for each user to remember their complete order.

Count and compare how many manage to remember everythign they have ordered.

Figma Prototype:

A Test

B Test

Test A = test with pictures

Test B = Test with just words 

Testing photos:

Conclusion:

First and foremost I would like to point out how due to the current corona situation, I had to collect my results online and therefore was only able to reach a small number of participants. My results are therefore not to be taken as true or false, since in order to answer the hypothesis more accurately I would have to gather a larger number of participants. Not to mention how fellow students and other people close to me are not the ideal users to test things with normally and would not normally count as valid. Having said this, I was able to tell a slight distinction between the users that placed the order through pictures compared to the users that only had words and descriptions. Users in the photo menu group were able to remember their complete order faster and with less struggle than the users with the text menu. Picture user 1 recall time: 17 seconds Picture user 2 recall time : 19 seconds Text user 1 recall time : 23 seconds Text user 2 recall time : 20 seconds Text user 3 recall time : 22 seconds

This pattern points towards the Picture Superiority Effect being true and correct. From observing the users attempt to recall, I also notice that memory started failing in between the middle and end of their order. This is a detail that happened on 100% of the users I tested on. 

[jullya-ux-uni]

Assignment 2.2: High-fidelity prototype

1) An introduction  This week’s task was to carry on from the previous assignment,  ASSIGNMENT 2.1: WIREFRAMES AND USABILITY TESTING. I had to use the wireframes that I created and develop an interactive prototype.  The requirements remain the same as in the previous assignment: 1. Welcome screen 

2. Gather the following personal information a. First and second name b. Email c. Password (be sure to inform yourself about certain conventions when designing for such critical security features) 

3. Waiting screen (at least 10 seconds) 

4. Feel free to add other elements depending on your chosen platform

Qualitative requirements 

1. Engaging 

2. Fun to use 

3. Detailed (looking into micro-interactions) 

4. Coherent design

You can check it out HERE

2) Your clickable prototype with descriptions and justifications   This is the first screen I had initially called the welcome screen. I decided to get not include the message “Welcome!” but have it say “Let’s get creative” instead, since I think Figma should motivate their users right from the start, before they even log in or sign up. At the first screen, users get the option of either putting in their details to log in straight away, or to sign up at the spot. 

If they decide to log in directly, they are taken to the loading page (the very last image in this post). However, if they wish to sign up, they are take to the next screen: 

The sign up screen is still kept simple but clear in directions. From the wireframe, I made the choice of going back to the initial design of having the return icon up on the top left corner, so that the intructions at the bottom are isolated and clear.

As a waiting screen, I made two versions. One I made it myself, where the Figma logo is taken apart and it “falls” down to the center of the screen as the page loads:

The other loading screen is once the “Welcome!” screen from above is gone and the user’s projects or canvas is are loading. For this loading page, I found a gif which had somewhat the same colors that I had been using, and also the spinning concept that I wanted to include from my initial wireframe:

3) An explanation of how you tested the prototype and an overview of results  As I did with the wireframes, I had this prototype tested by having a few of my peers press around it. However, to make things easier, I assigned them “goals”. One goal was to simply sign in, and the other goal was to create an account. That way I could analyze if their thought process to achieve these goals were the same as mine, and if yes, then they would not have any issues with the design. For the ones that had the goal to log in, it was pretty straight forward for them. One friend did point out, however, that my choice of words could have been more clear. They said that, instead of the button saying “Continue”, it should say something like “Log in”, that way they know exaclty what the button does. I very much agree with this, and, to be fair, I do not know why I wrote “continue” instead of “log in” since in my initial wireframes I had the words “log in”. I figure it was just a simple mistake due to lack of attention. As for the ones that had to sign up, the feedback I received said that the instructions for the sign up process were clear and well organized, especially how the color palette helps to distinguish the boxes in which the information should be put into.  When it came to the loading pages, the one I created was a little bit confusing since for it to work properly, the users needed to tap on to the next screen over and over (Figma took away one of their tools which allowed the screens to switch after a delay, which would come in handy for this prototype). But other than that, they liked the idea behind it. For the gif, the feedback was also almost all positive, but it would be appreciated if the colors would match more with my design.

4) Reflective discussion on making and testing high-fi prototypes I enjoyed meaking and testing the hi-fi prototypes. It is nice to make the wireframes come to life as it provides a sense of accomplishment. It certainly gives a lot more feedback than the wireframes, since the interactions and transitions are properly placed in the hi-fi compared to the lo-fi. Not to mention that there is the chance to test if the color palette chosen works with the design or not. Overall another great experience.

[jullya-ux-uni]

Assignment 2.1: Wireframes and usability testing

1) An introduction 

For this assignment, I had to create a wireframe for a sign up form of an existing sign-up process and improve it. I decided to use the sign up form for Figma. I did this because in my opinion, for a creative tool that Figma is, their sign-up screens are extremely dry and boring. They lack color, animation, and life. So I decided to add a little bit of that to it as my task. The tool I used for this is Figma itself!

There were a few requirements that I had to follow, and they were:

1. Welcome screen

2. Gather the following personal information

a. First and second name

b. Email

c. Password (be sure to inform yourself about certain conventions when designing for such critical security features)

3. Waiting screen (at least 10 seconds)

4. Feel free to add other elements depending on your chosen platform

Qualitative requirements:

1. Engaging

2. Fun to use

3. Detailed (looking into micro-interactions)

4. Coherent design

You can check it out  HERE

2) Your wireframes (original and improved), with descriptions and justifications 

The original wireframe was sketched out on a paper, in an attempt to follow most of the quidelines and requirements:

The improved wireframe was done in figma, following the simple design initially sketched. The main changes were made in the Sign up screen, where instead of just simple lines indicating where the users must type their information, I now have designated spaces like boxes for it. I thought that this would make it more clear for the users to know what and where they are typing, as well as giving it a sense of organization. I also opted to change the return from an icon to a button at the bottom of the page, next to the sign up button, so that the users know that they have the option of returning to the home screen to sign-in in case they made a mistake and already had an account.

3) An explanation of how you tested the wireframes and an overview of results 

I tested my wireframe by having a few peers review it and navigate through it. The main feedback that I received was that it was really straight forward, but it made sense and felt right. I guess that this shows how my wireframes did not focus much on the qualitative requirements, but I think I can make it up for those when I make a more HI-FI prototype. 

4) Reflective discussion on making and testing wireframes

I believe that making and testing wireframes are two very important steps before one should start to design and prototype any device. It serves as the basis or the skeleton that will help shape everything that comes after it. If the testing of the wireframe goes wrong, the designers can already know what will and what will not work out and can quickly and easily make changes, whereas if they did not have wireframes and went directly into making high fidelity prototypes only to realize some parts of it do not work, it would be a lot more complicated to make design decisions and changes.

[jullya-ux-uni]

Assignment 1.2 Non-visual prototyping

1) A brief introduction (what was the assignment).

The task for this assignment was to create a couple of non-visual prototypes to complement the assignment from the previous week, "Assignment 1.1: Low-Fidelity Prototyping". The task was to add on sound for the following features:

- slowing down - speeding up - reminder to drink water - notification for when an exercise has been complete/milestone has been achieved

The sounds for each of these functionalities had to match their functions properly and in an original way.

2) Your prototypes (audio files and descriptions) before and after evaluation. Please explain for each function what the sound is, how it was made and why you think it matches well this particular function.

- speeding up For this sound, I made sure that it would match together with the next one. I thought that an escalating and ascending sound would suit best. I made the sounds by shaking a bag of m&m's. (SOUND)

- slowing down For this sound, I made sure that it would match together with the previous one. I thought that a decreasing and descending sound would suit best. I made the sounds by shaking a bag of m&m's. (SOUND)

- reminder to drink water For this sound, I thought that the best way to represent water would be attempting to make constant water droplet sounds as if it were dripping. The idea behind this was that the droplets become more and more frequent (the time between each drop is shorter) if the user chooses to ignore and not drink. I made the sounds vocally. (SOUND)

- exercise complete/milestone achieved For this sound, I wanted to associate and incite celebration onto the user. I thought of many ways of trying to produce this, and this was the sound I made most previous "research" about. I found all sorts of celebratory sounds, going from several voices saying "yay" to fireworks to what seemed to be trumpets being played. I wanted to shift a be a little different for this, so I decided to go for a high-pitched sound. I remembered when I was younger I would be out running around playing games with my friends and the only thing that would stop up would be the sound of the ice-cream man swinging his bell. I attempted to remake this sound by repetitively hitting a glass with a pen. (SOUND)

3) Explanation of how the prototypes were evaluated. Also, discuss if there were any problems in conducting the test.

I evaluated the prototypes by asking a few of my peers to put on headphones and listen to the sounds while having all 4 paper prototype functions in front of them, so that they had to match each sound to a feature. 

4) The findings from the evaluation by a fellow student and how you could use them to refine the prototypes.

The only sounds in which there appeared to be some confusion at first was the celebratory sound, but as soon as they heard the other 3 sounds, they were able to put each sounds to the correct function. I could use this feedback to pinpoint possible confusion that users would have if they were using my device. It is a sign that I should either improve the sound or come up with a different idea for it.

5) Short reflective conclusion on this assignment and sound prototyping. What worked for you? What was challenging?

This was a fun assignment to complete. It made me reflect on how, usually, sounds are not something that we think about as users, but this is because designers have put a lot of thought into creating them, in a way that each sound matches perfectly to its function and we do not even question it. It was chanllenging finding the perfect sounds for something so specific and even more challenging to describe these sounds with words.

[jullya-ux-uni]

Visit Original Link

Milestone reached/End of exercise

[jullya-ux-uni]

Visit Original Link

Drink water reminder

[jullya-ux-uni]

Visit Original Link

Going slower

[jullya-ux-uni]

Visit Original Link

Going faster

[jullya-ux-uni]

Assignment 1.1: Low-fidelity prototyping

1) Introduction (1-3 sentences explaining what the assignment was).  The assingmnet was to build a lo-fi prototype of both a smartwatch and a mobile app for a fitness tracker. The application had to include a few key features, such as start and stop tracking in response to user’s input, track the burned calories, traveled distance and current speed, display this information in real time to the user, as well as display tracked data per day / week / month. I decided to call my application “Activ”.

2) Your prototypes (photos and descriptions) before and after the evaluation. Describe the functionalities in the prototype. Remember to justify the choices you made in the design.  The shape of the application was inspired by the Apple Watch and iPhone. As for the design itself, I opted for a simplified cleaner version compared to a few of the fitness tracker applications I found when searching for inspiration, and this is the biggest difference in my design. An example of this is how most of the fitness tracker applications show a graph or several graphs to showcase the user’s progress. I thought that this design looked a lot like the graphs of the stock market, so I opted to instead show a summary of the weekly and monthly workout by giving the users an average of the results (calories burned, distance traveled, and average speed).  As for other features I have differently compared to other designs, the Start tracking button on the watch is the first thing the users see once the app is opened. I chose this to not overwhelm the user with choices.

As soon as the users press the start button, a screen will show their progress in real time. As the exercise continues, progress circles will be filled in with the specific color (pink = calories, purple = distance, blue = speed).  

The option to stop the tracking is always available. However, to prevent users from accidentally stopping it before they are done exercising, I thought a “drag up and press” feature would be ideal.

Once the stop button is pressed, the application starts syncing automatically to the mobile application, sending the newly collected workout data and adding it to the user’s set of collected exercises. Here, they are able to briefly view a summary of the exercise they have just done (so that they do not need to immediately open their phones to be able to see the summary), and then the start button appears again to record a new set of workout.

I decided to make the applications be able to sync in a way that the watch tracks the workout in real time and the mobile app presents the results. One is not able to see the results through the watch and neither track in real time through the mobile app. I made this decision because I believe that otherwise there would be too many features on both applications and the users would get lost. 

As for the mobile app, the first thing the users see on their screen once the app has loaded are the options “Today”, “Week”, and “Month” presented as buttons. This is pretty straight forward: the “today” button will show the summary of the workout tracked today. “Week” shows the weekly average summary, and “Month” shows the average summary during the month. Of course, users are able to move back and from between dates, such as from “Today” to “Yesterday” or  “This Week” to “Last Week” or “May” to “June” by simply tapping the arrows. It is also possible to go back to the  “Today”, “Week”, and “Month” start menu by tapping the button at the bottom of the screen.

3) Explanation of how the prototypes were evaluated. Also, discuss if there were any problems in conducting the test. 

The evaluation of the prototype was done by having a friend “test it” by tapping around and seeing how both watch and mobile applications worked. An important element to point out is that there was no initial explanation of the buttons and features of the app. The only guidelines given were that it is a fitness tracking application and that they are free to explore it. Initially, this was a bit of an issue since the person testing it was left a little confused. However, once they saw that if they tapped a button I would change the papers and “the screen would change/react”, they understood that they were able to interact with the paper prototype as if it was an actual application.

4) The findings from the evaluation by a fellow student and how you could use the feedback to refine the prototypes.  There were moments in the testing that the user was a bit stuck and did not understand what the buttons actually meant unless they pressed it. An example are the buttons at the bottom of the screen of the mobile application, especially the one that says “Day”, since that is not an option in the initial menu. 

VS

Another confusion was that the user is used to an android phone which has “return” buttons, while, as I mentioned, my prototype is based on an iPhone, and to return to a previous screen one needs to swipe the left corner of the screen. I would have to take this into consideration when designing.

5) Short reflective conclusion on this assignment and lo-fi paper prototyping. What worked for you? What was challenging?

Building a paper prototype and having it tested by someone else worked a lot for me and helped me visualize features of the applications that needed to change or to be made clearer. The most challenging part of this was the handwork/manual labor that needed to be put into making all the pages/screens.

[jullya-ux-uni]

A-Frame Assignment 02 - Shape

I attempted to make a 3D version of the flag of Brazil.  Link to GitHub: https://jsalern0.github.io/ARVRworkshop/02Shape/

Check out the outcome in the images below: