For the mark 1 prototype I built a version that was concentrating more on visuals and structure rather than interactions or animations. I really wanted to get a sense of what the app would feel and look like in it’s final form as I’d already been exploring how to interact with it through the experience prototype. I used the sketch I made earlier as a reference for the visuals.
I built the prototype using a frame work that later when starting with implementing interactions provided to be all wrong for it, not allowing me to implement all necessary aspects.
Screenshot from mark 1 prototype
Unfortunatelly for personal reasons I wasn’t able to attend the feedback session for the mark 1 prototype.
For quite few days now I’ve been concentrating on the more visual side of things exploring different avenues for the look of the app. As a starting point I used the design inspirations I gathered for the PeDeTe hand-in as I felt that they were still very much relevant for the project.
My two options for the Design sheets were geometric shapes with playful colours and geometric shapes used in combination with images. I wanted to test out both as I felt either could be applied to the project. The playful colours would really well accentuate the tone of voice that I’m going for but on the other hand images could possibly be used to make a deeper connection with the people through the app.
I also really enjoy the idea of using circles as they would be kind of inherited from the world of emoticons. After testing this idea out, I decided that it was definitely the way to go. Besides the form I also like the idea of using the colour traditionally used on emoticons: yellow. Especially the idea of combining it with quite neutral colours and then using the yellow to highlight interactions really appeals to me.
We’ve had an introduction to information architectures today. It is a technique in which you map out all the different screens of a digital design and how they relate to each other. It’s about visualising the structure of the design and testing out the consistency, navigation and flow of it.
Before working on our own interaction architecture we practiced making one for an existing app
This was actually an immensely helpful exercise to do as it allowed me to visually map out my thoughts about navigation and flow as well as quickly realise what aspects needed more work and pointed few screens/areas I hadn’t even thought about.
By visually mapping out the ideas I had I was able to work through several issues I had previously encountered. For example what would be presented on the first screen (so essentially what is the main aspect of my app), how would the two modes of viewing others moods and entering your own work together and how could you access the archive of moods. Also trying to understand if there is a need to represent you on the main screen or not and how would the interactions between you and other be visually represented.
Clearly there is a lot to think about and many aspects that yet need to be resolved but this was a great way of getting me to think about those.
Over the past few days I’ve come to a hard conclusion: I will need to let the alarm aspect go.
Through the prototypes that I’ve done of my app and the attempt of trying to visualise the app flow I’ve come to realise that even if the alarm aspect would still be a great addition to the app, due to the time limitations I will need to let it go for now. While prototyping I’ve found it very difficult to fit together the alarm with the other aspects of the app. For some reason I’ve had a hard time keeping the focus on the main functionality, the recording and sharing of the moods. I’ve got stuck with the alarm, trying to figure out the specifics of it and it’s become much more about that instead of being able to craft the other functionalities. In the interested of the limited time and on the face of this change of focus in my work I’ve then come to let the alarm go. It was a hard decision and I’m bit worried that I will regret it at some point, but it is the decision that makes most sense right now.
So with this I hope I’ll be able to get back to working on the main beef of the project.
One of the big aspects of my project will be how the actual smilies look like. This will determine a lot what the app feels like. To understand this better I started by looking at the emoticons used in existing applications.
Nike Running app emoticons
After this I gave sketching my own emoticons a go. After having gone through few different iterations I still wasn’t exactly happy at how these were turning out. I went back to the inspiration material and realised that the more abstract the emoticons were the more I liked them. Like the gtalk emoticons that use the abstract keyboard symbols. This allows me to read more into the actual emoticons allowing them to actually convey more emotion. Inspired by this I tested few versions and in the end ended up realising that I was using only the mouth to convey emotion. It was a a line but by curving it in different shapes it could convey different emotions.
Testing out drawing the “emotion lines”
I then joined this with the feedback I got from the experience prototype of not having big enough range to actual express all the emotions. By allowing the user to actually create their own emoticon, or in my case draw a line, they would be allowed to express a whole lot more than by just choosing from a predetermined range offered by the app. This would also add a new layer of personality to the interaction as it would actually be the “handiwork” of the user instead of a pixel perfect rendition. This might even result in different people developing distinguishable styles.
Also while looking at the existing emoticons I looked at the colour schemes used and made a swatch of the colours used as a reference. It would be great to use some of these colours in the final interface as a reference to these more traditional emoticons.
As I’ve previously mentioned one of the big aspect of the project will be an alarm to which all the other features are attached. Given the importance of this I decided to spend some time researching what is currently available.
Several of the apps on the market were strikingly similar. Not only by concept but using the same UI elements as well. To input the time most used the iOS scrolls.
Screenshots from Sleep Cycle, Clock, Clock Pro and Alarm Tunes
The main screen of the apps varied between a list of previous alarms and showing a clock. Only three of the ones tested, Rise, Sleep Time and Sleep Cycle allowed me to actually set the alarm in the main screen. Others had hid this function, sometimes even quite deep. Most allowed me to change few settings while setting up the alarm, like the alarm sound, snooze option, volume level and repeat. Most of the test applications were very similar and kept with the standard format. Only two had a slightly different approach. Sleep Time uses a representation of a clock which is encased in a circle that has a handle that can be dragged around thus changing the alarm time. Rise allowed me to select the time by dragging my finger up and down the screen while changing the background colour to suit the time of the day.
So far I have been between two different focal points for my project: one that concentrates on the personal and reflective side of it and one that concentrates on the connecting side. We had a discussion in the class this week and one of the tutors gave us a good piece of advice that relates to my situation: one view wins. What this means is that one aspect or functionality will naturally become more dominant over the others so it is smart to make it a conscious decision that steers the project in a wanted direction. This reassured me that my aim to resolve the focal point at this stage is something I should be doing.
After giving this some thought and through the feedback and experience gained from conducting the prototype earlier this week I really feel that the connection side triumphs over the personal one. Whilst it can definitely be used for personal reflection I believe that the main pull and attraction of this app is in its ability to connect people over this very simple interaction and in allowing people to keep in touch without altering their routines.
Inspired by my evening reading, Storytelling for User Experience, I decided to write up two different contexts, or background stories if you like, that highlight who might be benefitting from my project and what are the problems it aims to resolve related to the connecting side.
Marion and Lucas
Marion and Lucas have been friends since childhood but even though they live in the same city their lives have taken them in very different directions. They are struggling to find time to meet up or even keep in contact. Every now and then they try to really keep up with how the other one is doing and try to at least call on a frequent basis. They have tried several ways to keep in contact but more often than not these attempts fall short. Not from the lack of wanting to but from the sheer lack of time and energy to keep it up amongst their other routines.
Elena, like many of her friends, has moved to a nearby big city to study in university. She loves it here and really can’t see herself going back to the, well village might even be bit too generous description, where she grew up. Still every now and then she misses her parents and especially her sister who is still living home and one of her good friends who had to stay back to repeat a year of school. At the beginning Elena contacts her parents weekly and chats with her friend and sister online almost daily but as she gets busier with university as well as starts settling in and making new friends she starts falling out of this habit. She would still love to be in contact and sometimes even feels a bit guilty about not contacting them more but struggles to find the time to do so.
As I mentioned before I’ve carried out an experience prototype over the past week. I wanted to test how the actual act of reflecting on the day, visualising it as an emoticon and then sharing that with someone else felt. So over 6 days I have engaged with an participant using an already existing messaging platform for mobile devices, WhatsApp. The way I organised this was that in the evening time at an agreed time we exchanged smileys that we both felt represented how that day had been.
The participant was unaware of the specifics of my project and was at the end of this experiment interviewed on how the experience was for her. As a great reassurance on the direction I have taken she suggested many features that I had already thought to add as well as found the experience to be quite a pleasant one overall.
Utilising the opportunity to flex my video making muscles I put together a short clip of the interview and the main points raised by the participant.
Another aspect here was that by orchestrating this experience prototype I was also able to test the idea myself. I might be slightly biased here but I really did enjoy the experience. Due to the agreed time having fitted around the participants schedule the time that I was entering my daily mood was bit earlier than I would have normally done. This might be one reason why especially at the beginning I struggled a bit with reflecting on the day and transforming that reflection into an emoticon. This however got a bit easier after a few days of using the service.
I definitely felt as well that the interaction and the short moment in time where you get this small window into how someones day had gone was quite heartwarming and pleasant. It also surprised me how strongly I was affected by getting a sad smiley back and had a strong need to reach out to that person. This might be something to think about if this will be facilitated through the app or not.
From conducting this prototype I learned:
It can be quite an cleansing experience to get out how the day went as you are getting ready to go to bed.
The speed aspect is paramount. Though there might need to be an option to add more information on the days that you feel that a single emoticon just doesn’t cover it. This could also help in avoiding the data to become too abstract over time. It could be just a single word that would work almost as an memory tool.
Fun and lighthearted are good adjectives to aim for. The experience itself should not become a chore.
Some sort of archive / aggregation of the moods entered will need to be implemented.
It will be important to get right the balance between ease of use, speed and allowing the user versatile enough tool to express how they feel. Especially allowing them the opportunity to express slight nuances, not just big emotions.
The interaction is a big aspect of it. In the prototype it was very much reciprocal which might be an interesting element to experiment with even in the app itself.
When the other person has had a bad day the need to reach out to them is quite strong so this might need to be facilitated through the app in some format.
As a way to start getting more specific with my project I’ve started drawing up some storyboard-paper prototype hybrids. I am faced with trying to understand which aspect of the app will become the most prominent and essentially the selling point/main functionality. At the moment I am between making it more for personal recording and reflection and making it more about the social aspect of tracking how others are doing. This decision will then in turn effect the way the information and options are presented within the app. I will go over my first attempt of trying to visualize the app flow and to identify some of the problems and decisions ahead of me.
By thinking about the alarm clock I identified few things:
Should the app allow for an alarm to be set at any time or just in 5 min increments?
Can the order of tasks affect the mood input? (Having to wake up early dampening your mood?)
Should the mood be allowed to be entered without setting an alarm?
Should multiple alarms be possible?
Should there be snooze option? If yes would it be adjustable in settings?
About the main menu:
Are all options equally important?
What is the thing that users need to see first?
Should the alarm be allowed to be set straight from there?
What information is most relevant to the user?
Is there actually a need for a menu screen? Alternatively menu bar?
Pointers for entering the mood:
Using emoticons to represent the mood? This decision will be crucial.
Having an emoticon that can be interacted with to represent the way the day went? How abstract could it or should it be?
Should there be additional elements that could be added in like tear drops, eyebrows etc?
How intricate should the input be?
Should there be possibility for adding more info like tags?
The input method needs to be fast and easy. Preferably no or very little text input.
Few remarks on connecting to other via the app:
How much information should be visible for other people? All entered moods? An over-all one? Daily one?
Should the amount of people the user can connect to be limited?
Try to nudge towards making few intimate connections instead of a variety of ones the user would not be so interested in.
Reciprocity. You need to enter your mood to see the input of others?
Notes on accessing the archive of the users inputs:
Does all input data have to be accessible?
Does the data become too abstract over time?
How long back should it be viewable and how specific should it be?
Here is also an initial (and very rough) test that explains the interaction of manipulating the emoticon to create a representation of how that day went. This was also about exploring video as a communication tool.
At the beginning of this week we had a talk from our external examiner Rory Hamilton. During his talk he walked us through couple of student projects he had been involved with that had utilised experience prototyping. He made some excellent points about conducting experience prototypes and made me realise that it is definitely something I should be doing, even if at a small scale.
Some of the main point I gathered from his talk were:
When conducting experience prototypes earlier in the project they can be quite abstract and removed from the final intended context.
Make the content and experience relevant and personal to the user testing it. Try to find out a bit about them and their interests before hand and incorporate that to the experience to make it more engaging.
Video can be an excellent tool in communicating not only the final result but also parts of the process.
One of the example experience prototypes given by Rory (this is from an CIID student project called Thought Drop):
Fuelled by these insights I have lined up two preliminary experience prototypes. One which is just a very simple test of the general idea of swopping emoticons using existing messaging platforms and another that is a physical representation of the main functionality of the app. More info on these to follow as they progress. I also want to use rough videos as a means to explain some of the aspects of the project and am currently preparing a short video prototype using just paper sketches that would explore the main flow of the app.