uxdidentitycrisis

[uxdidentitycrisis]

Landing page

This is the BTP portfolio blog for student 22084258 of UXD. Each prototype has its own post, and the blog is concluded by a reflection.

[uxdidentitycrisis]

Assignment 1.1

paper prototype

Introduction

The assignment was to design and paper-prototype a runner's app for a wearable device. I chose to design an app for a smartwatch, and even though I have never used a smartwatch or a runner's app, I was able to find a lot of inspiration by searching online. I was able to include all the required features, but was I wasn't very confident about the navigation within the app because they were made with only my intuition.

The Design

The final design of the prototype came together quite quickly. The color scheme I chose was yellow and green, with red highlights for important buttons.

The three main features are the visibility of speed, calories and distance. When one of these measurements is selected, the app takes you to a screen where the selected one is focused. The three dots signify the ability to swipe to the other measurements. When the block is tapped again, it takes you to recorded measurements over a period of a day, week and month which can be chosen at the top of the screen.

I made it like this so the app is quite compact, and it seems intuitive to me. It does not have a lot of different types of interactions, which could otherwise make the app more complicated to navigate. I also used only rectangular shapes in order to keep the design consistent.

Testing

For the user testing, I decided to have the user navigate to some main features of the application.

Task 1: from the starting screen, start a run

Task 2: from the home (running) screen, navigate to your weekly speed statistics.

Running the tests went quite smoothly, if not for the flimsiness of my prototype. With a paper prototype, moving through screens wears the paper out after each user, and not every transition was very smooth. Thankfully, the testers were all very patient with the prototype and were able to complete the tasks and give feedback.

Feedback and iterations

The users liked the layout and clear, big display screens. Most of them also found the navigation to be intuitive and uncomplicated. The dots that indicate the ability to swipe also did their job.

4 out of 5 users wondered what my design would look like with more vibrant colors. I incorporated this change in the revised screens.

3 users wished there would be a back button, to make the navigation even smoother. I added a physical button, so the user can return to the previous screen at any point.

3 users also wished that the start / stop recording button had some more clarity. In order to make this happen, I changed the button to “stop run” and set it to that state. Once the run has been stopped, it would change to “start run”.

1 user was confused at the starting screen, not knowing that the screen should be tapped to enter the app. While only one user made this remark and the other 4 were able to enter the app easily, I do want to implement a change because this confusion may occur in more users. This is why I decided to chance the screen to a loading screen, and the little running images would blink until the app is done loading.

[uxdidentitycrisis]

Assignment 1.2

Audio prototype

Introduction

For this assignment, we were to create 6 different audio prototypes that fit with the previous paper prototype. The sounds indicate things like starting and ending a run, the halfway point and the completion of the exercise. The sounds can not be made with words or existing audio clips.

The design

I chose to create all my audio prototypes with just my voice, as I have very little experience with audio and music software.

For the ‘start a run’ sound, I wanted to add some familiarity by creating a sound that resembles a countdown, like in racing games. This would clearly indicate the start of an exercise without resembling the other sounds too much.

The ‘stop running’ sound kind of resembles a shut-down sound. I wanted it to have a slower pitch so it would not sound like an accomplishment or final sound, but just as a neutral ending to something. Because that is what the sound indicates. It occurs when the user presses the stop button at any point, so there does not need to be an extravagant sound connected to it.

The ‘go faster’ and ‘go slower’ sounds are very related to each other, as both contain some repetition. I did this because I can imagine that while running, the user may miss the audio feedback if it was only a short ‘beep’. The slower sound has a few beeps that go down in pitch, signifying to the user to go down in speed. The faster sound does the exact opposite, the pitch is heightened as a sign to the user to speed up.

‘halfway there’ is a shorter version of the ‘exercise complete’ sound. I wanted it to be a bit similar as both of these sounds indicate an accomplishment. And because the halfway mark is only halfway, the sound that accompanies this moment is also a little bit more low-key than the final celebration.

The sound that indicates the exercise is complete was the easiest to come up with. I created a celebratory sound that should induce a feeling of accomplishment in the user, and because this is the final accomplishment, the sound is slightly longer than previous ones.

Test protocol

Research question: do these audio clips enhance the use of the paper prototype?

Characteristics:

Able to run

Hearing

Materials:

Laptop, for taking nots

Phone, for the audio clips and pictures

Paper prototype

Tasks:

Start a run                                     start run sound

Check your speed                        go slower sound

(user is now halfway) Halfway mark sound

Stop / pause the run                   stop run sound

Continue until the finish             go faster + finish sound

Questions:

Did you understand what all the audio clips indicated?

Did they sound intuitive to you?

Did the audio make you understand the product better?

Feedback and iterations

Most of the feedback from users was quite positive. Most of the sounds were correctly interpreted and the users understood what they meant. The starting sound was met with enthusiasm as it resembles the starting tunes of racing games, as intended. The sounds for ‘go faster’ and ‘go slower’ were also intuitive enough for the users to understand, as well as the ‘stop’ and ‘finish’ sounds.

There was one audio clip that was not always fully understood, which was the sound that indicated the halfway point. Once the audio clip that indicates the end of the workout was played, they did understand what the halfway sound meant. This does show that the sounds may be too similar, and even though the final one is very clearly a little victory tune, the halfway point sounds too cheery to not be confused with it.

I attempted to create a sound that was a little less cheery, but still indicative of progress. This was a very long process, as I went through many versions that I did not feel gave the right signal for the halfway point. Instead of the "paa" sound, I decided to lean more towards the "pam" sound, to make it sound less like a celebratory trumpet.

[uxdidentitycrisis]

Assignment 2.1

Lofi-prototyping

Introduction

For this assignment, we create a lo-fi wireframe for a traveling app for the public transport company Randstad Rail, who are rebranding as Tripp3r. They have provided us with a set of requirements for the app, and their priority. The final wireframe should be functional and show the layout and navigation of the eventual final product.

The design

To create the lo-fi prototype, I drew inspiration from some transport apps with functionalities that I like, and made sure to steer clear from applications that I absolutely hate. This really helped me in mapping out the navigation between different screens, such as the main menu which contains the most important functions.

I wanted to use similar shapes and layouts on every page to prevent the design from overwhelming the user. This is also why I chose to put the main functionalities on the homepage, because the user should be able to reach these the quickest.

Test protocol lo-fi wireframes.

I chose to have the main components of the wireframe tested by all users by giving them small tasks surrounding the navigation and functionality of the wireframe. This way, they will be led through the entire app, and will hopefully be able to come up with some

Characteristics:

Familiar with phone apps and how they usually function

Uses public transport

Materials:

Laptop for Adobe XD prototype

Phone for images and note taking

Introduction:

Thank you for agreeing to test my lo-fi wireframe. I will give you a few tasks to complete, and it would be nice if you could think aloud while you carry these out. This will greatly increase my understanding of the users’ thought process, and evaluate the usability of the application.

Any data recorded from this process will solely be used for this assignment, and solely shared with the relevant teachers.

Tasks:

Task 1: find a trip and save it.

Task 2: download a trip.

Task 3: find the place where one can view the maps of specific lines.

Task 4: check the weather.

Task 5: find the place where one can read about a landmark.

Feedback and iterations

The feedback to the prototype was generally positive. The testers found the app easy to navigate and logical. 2 people mentioned that they liked how the homepage contained the key components of the travel application, without having to look for them. I did receive a few pointers that I used in the iteration to make the wireframe even better.

Out of the 5 testers, 4 people mentioned that they expected there to be a link to the maps in the menu as well as on the homepage. This has been added in the iteration.

2 people mentioned that they expected the map that is shown when a route has been selected to be clickable, so I have made this change as well.

The logo in the top right corner should function as a home button as well, according to all of my testers. This was an oversight on my part as I was planning on implementing it, but forgot to make it functional before the testing.

Another pointer that I received from one tester was to maybe add a download button to the route pages right away. I chose not to do this in order not to make the page too cluttered, as there are already a lot of components that should not be removed from that page.

In conclusion, the iterations that have been made are:

The logo in the navigation bar now directs to the home page.

There is now a link to the maps in the dropdown menu.

Route maps are now clickable (to zoom in) when on the page of a selected trip.

[uxdidentitycrisis]

Assignment 2.2

Hi-fi prototyping

Introduction

For this assignment, we were to use the lo-fi wireframe and its functionalities as the foundation to the final hi-fi prototype for the Tripp3r application. In this version, color, images and other non-functional details should be added to make it look like a finished product.

The design

For the hi-fi design, I copied the lo-fi design and added colors, images, and some extra screens to make it completer and more functional as a public transport application. I added a map to the landmarks page, so users would know how to get to certain landmarks. I also changed the 2 download pages from the “saved trips” section to full screens, one as a loading screen when the app is downloading a trip as PDF, and one for when this process is completed.

The company wanted their values to be reflected by a set of colors they have chosen to represent them: green for the environment, blue for customer satisfaction and orange for courage and progressiveness. These colors are the main design component in my hi-fi prototype. In the logo they have delivered, the orange has more of a yellow hue, so this is the exact shade that I used in the final prototype.

In the loading page, I wanted to incorporate all colors, but distinguish it from the rest of the application a bit. This is why I chose to make it a faded gradient as opposed to the solid colors on the other screens.

All top navigation bars including the menu button and the menu look and function the same on every page. The most important functionality in the app is the planning of trips, so I chose to make all backgrounds related to this blue (plan a trip and saved trips). In order to distinguish the other functionalities, I gave the different background colors. So the maps and weather pages are yellow, and the landmarks pages are green. 

The first two images below are of the full prototype, and the focused screens are the ones that received direct feedback during the testing.

Testing protocol

Materials:

computer

wifi (as these tests will probably conducted online)

Introduction:

Thank you for agreeing to test this hi-fi prototype. All data related to this test will only be used for this BTP assignment, and only shared with the relevant teachers. This test consists of looking at a few screenshots of the prototype, and then giving your opinion on them.

Tasks:

For each screen, please choose one or two of the following words that you think fit with the screen, and give a short explanation for why you chose these words. Words can be repeated as many times as you need them, and feel free to use negative ones in combination with positive ones if needed.

Appealing Boring Busy Comprehensive Efficient Incomprehensible Inconsistent Intuitive Satisfying Confusing Consistent Frustrating Organized Overwhelming Unattractive Understandable Usable

Feedback and iterations

Most of the negative words (5 out of 8 words) were connected to the home screen, the most frequent one being ‘inconsistent’. In the explanations, users were dissatisfied about the borders, as they were not around every component, which made the screen less satisfying to look at. This has been altered in the iteration.

There were also comments about the bulkiness of the white input spaces, which I have also changed a bit to look cleaner.

Another screen with some negative feedback (3 out of 6 words) was the ‘weather’ screen. According to testers, even though it is organized and understandable, the text was a bit repetitive. One tester also said they missed some information, such as the temperature. This is why I removed the repetitive text, and replaced it with a few icons with more information about the weather; the temperature and wind direction and strength.

[uxdidentitycrisis]

Assignment 3.1

A/B Testing

The testing was conducted over a few days with different people. I first conducted the test with the images and told my friends to tell me when they were done looking at the menu. I then asked them if they recalled the dishes they saw, and if they could name all the visible ingredients of the dishes.

I then altered the testing program I was using to show the menu with the text first, and continued to test with 5 more friends and classmates, following the same questions I asked the first group.

To sum up my findings, I calculated the average dishes and ingredients remembered by each group. To keep it organized, the averages are rounded up or down to the closest full number.

Text menu

dishes remembered:

average 3           total 13 (out of 15)

ingredients remembered:

average 6           total 32 (out of 60)

Image menu

dishes remembered:

average 3           total 15 (out of 15)

ingredients remembered:

average 11         total 54 (out of 60)

These results clearly confirm the hypothesis I stated at the beginning of this chapter. Out of my 10 test subjects consisting of classmates and other friends, the users who got to see the image menu remembered the dishes and ingredients way better than the users who saw the text menu. Although this may not be a large group of testers, the results differ so much between the two versions that it is hard to suggest the hypothesis to be incorrect.

It’s safe to say that the hypothesis has solid proof. The general hypothesis of people remembering pictures better than words have been proven countless times in studies, but the explanation as to why the human brain works this way is still being debated.

[uxdidentitycrisis]

Assignment 4.1

Wizard of Oz prototyping

Introduction

Coming up with an idea was probably the hardest part of this assignment. The final prototype had to be interactive, functional, and controllable from behind the scenes. The process of making this prototype was very different from the other assignments, so it was a little difficult to get used to this complete freedom for imagination.

We went through a few ideas, such as a social distancing simulator, but we found no way to make this concept actually interesting in any way. Another idea we had was almost a Tarzan game. The user would have to grab ropes on the left, then right, then left side of the screen in order to swing forward and progress. This was a very engaging idea, but unfortunately we were unable to make it functional and appealing with the time and skills we currently had.

The design

Eventually, we settled for the puzzle idea that was accompanied by a quiz. If the user answered a question right, they got to reveal one of the pieces of the puzzle until it was complete. In order to make sure the puzzle was a bit engaging, we chose the theme of Disney, as it is unlikely that someone has never seen a Disney movie before.

In hindsight, I’m sure we could have come up with a more creative or engaging prototype, but with the time limit for the assignment, and the pressure I felt because I fell behind due to catching covid, this was the best we could do in that situation.

It had been a while since I had worked with Adobe XD, so the process of actually creating the prototype was not the smoothest. On top of that, after finishing the entire thing after hours of work, I found out that it could have been done in probably 10 minutes. However, it was completely functional so I decided not to change anything as not to waste any more time while being this far behind.

The final prototype came out like this. The first 2 images are the starting screen and the final finished puzzle.

These are some possible screens that the testers could run into during the process, depending on the route they choose to take.

These screens are the final product of the Adobe XD file with connections so evrry route is possible.

Testing

As the final prototype we came up with was not very complicated, the ‘testing’ also went quite smoothly. As you can see in the video, the format of the quiz and the puzzle together seem to work alright. The user answers the question right, selects a puzzle piece on the projected screen, and the wizard quickly activates that piece by clicking it on the computer.

[uxdidentitycrisis]

Reflection

I think the lo-fi prototyping provided me with a surprising personal insight, being that I really like the process of this kind of design. I’m very unexperienced with actual designing, like the hi-fi prototype, but wireframing was a good experience for me. I was able to use my own personal experience with (travel) apps to create something that felt natural to navigate through, and the feedback on it from testers really solidified my satisfaction with the wireframe.

I’m not sure in which phase the method could fit well, as it is quite time-consuming. Perhaps it could be used in the ideation phase, as a method of sketching. This can actually be very handy for someone like me, who cannot draw to save her life. It’s also a useful method to create organized sketches for wireframes in this phase without working out the details that will be added in the prototyping phase.

I was pleasantly surprised by the A/B testing technique. The biggest insight I gained is that this method can be set up in quite a short time, and yield very useful results. In this instance, I had to design the whole menu as well, and not just change a variable to an existing design, which means that when applied to an existing project, the method will be even less time consuming. That’s why I think this method can also produce valuable results in the researching. In that phase, important observations are being made about the users. Using A/B testing to observe and understand the user can result for the defining and ideating processes.

This course has a good arrangement, and assignments build upon previous ones well. This means that we can learn in chunks very well, which gives the course a nice flow. However, this is only the case if there are no outside factors disturbing the student. I fell sick for 2 weeks, only a little while before the deadline, which meant that my progress was instantly ruined. Because I had not finished previous assignments, I had a hard time doing current ones, as I missed theoretical lectures and the classes where prototypes were built and tips were given.

If we had been given a little bit more leeway, these kinds of unavoidable circumstances would not hinder a student’s progress as much. This is definitely not the only course with this kind of arrangement, so catching back up to everything caused an extreme amount of stress. That is why I am only now handing this in for the resit.