Our design choices

Reflections and design choices in wireframing and mockup

In this segment we will aim to walk you through the design process of our wireframe and mockup, and the rationale behind the decisions. 

There were a lot of groundwork put down during the steps before we came to this stage (i.e. the storyboards and personas), there was a clear picture as to the functionalities of the product. In short, the main purpose of the product would have to be the scheduling and communication between the User (person with certain functional impairments) and the other intended parties (in this case assistant and relative). Therefor the actual event that was closest is prioritized. This took the shape in the way that for the User and the Relative it would be the first thing seen. The Assistants screen is where it diverges, considering the assistant might need a more eagle-eyed view of activities. The reasoning behind this was that the assistant might very well have more than one subject, therefore it would be more helpful to have a more traditional scheduling view over all the events. 

It was in fact at this stage where we started asking ourselves more in- depth questions regarding the division of the functionalities. As previously mentioned, the core tenants of this application is the increased autonomy of the User. The User needs to be involved in the decision process, to increase the clarity and efficiency in the communication between User, Assistant and Relative. Here we started to identify what the essential functions would have to be for each intended subject. Naturally the discussion started at the Users end.
The User would have to be able to see their scheduled events. Also, they should have the ability to create new events if they so choose. The nature of these events, after much discussion, were identified as events that could involve other people connected through the app if they so choose (in which case a notification would be sent to the relevant parties) and events that don’t.
The User would also need to be able to see an overview of events to come, so that some sort of schedule would need to exist as well. Since the application is supposed to simplify theses matters there was concern that an overload of information would be detrimental to the intended purpose of the app. For this reason, the application on the Users side only displays a weekly schedule instead of a monthly, but would be prioritized as a secondary page because with the simplicity in mind and the avoidance of over-information, the decision to prioritize the closest event as the first screen was reaffirmed. Wanting the User to always have the final say in their involvement in events, the User would need to have the ability to accept or reject events made by the subject Relative.
These would appear as notification on the application, and if accepted, would be added to both schedules. If rejected, it would simply disappear. Same would apply if the User sent a request of an event to the Relative subject. Upon the acceptance of an event it would be added to the schedule of all parties. 

When discussing the relevant functionalities of the Relative subject, two things came to mind, the ability to see events they themselves were involved in and seeing in-coming events sent by the User. The right to privacy of the User would make the schedule of the User be inaccessible to the Relative subject other than the ability to see if the User is free at the time the Relative tries to create an event. This functionality was added with the purpose of minimizing notifications of event requests that could otherwise simply be avoided. 

Of course, this left us with a few crucial functionalities of the app that were left over, such as account creation, adding and linking of User-Relative-Assistant. If one would consider the Assistant subject as a type of hub in regards to the application and the fact that there might be reasons that they be in the loop of any events involving their subjects, it would not be unreasonable to add these key functionalities in their version of the application. In day-to-day operations of the Assistant, the priority would have to be the ability to have an overview of what is going on. There for the first screen would be a schedule with the Assistants affiliated Users activities. Thinking there might be a need to plan ahead on a grander scale, the decision was made that the Assistants schedule would display the full workweek with small notations in each day for every event. The Assistant subject can add events of their own in that interface as well. Next priority would be to see a list of affiliated Users and their contact information. Upon accessing a User in this menu, the affiliated Relatives of the User and their contact info would be made available.  Seeing as the Assistant subject would have the most information in their interface, we simply reasoned that when a new User would come into the purview of the Assistant, they would through the user-slide of their interface add a new User subject. Within that User subject they would then add any Relatives that the User might want to link. Upon finishing the creation of the User, there would then be a confirmation of sorts sent to the User/Relative that was created so they may add any additional information and potentially add any passwords, thus passing the control of the created subject back to the intended users. 

After mapping out the functionalities, the distribution of them between the subjects and prioritized them within each interface, we were faced with the challenge of design.
Having identified the need to keep it simple and minimize the amount of information, we decided to try to be as concise as possible with the text. Using a direct and simple vocabulary it would help keep it minimal and yet retain maximum usability by not alienating people with minimal tech-savviness and/or ability. Clarity became a priority, so the buttons were made large and distinct.
As we were prioritizing simplicity and minimalism, we decided to draw inspiration from something familiar to all of us here at Watermelon, Scandinavian design (as we, Watermelon are students in Sweden). A very simplified interpretation of the core concepts in Scandinavian design are functionality and minimalism. This felt very much in line with our vision for how we wanted the application to look. Starting with our chosen color pallet, it is very simple, black text on a white background with a header in a toned-down pastels. This was a choice that lined up well for us as we had wanted the design to not be color coordinated in anyway as to decrease usability for potentially colorblind Users. The more we tried applying the principles of Scandinavian design we saw more and more overlap between what our needs were and the aesthetics of our design choices. Scandinavian design tends to aim for a decluttered space, we wanted the application to be as straightforward and avoid displaying to much information. The use of clear, simple lines and subtle accents can be seen throughout the application. Keeping in mind this school of thought as we worked on our mockup, we happily noted a sense of cohesion in the overall aesthetics of the application without many (if any) concession in functionality or vision.

 “Less is more”, a not too uncommon turn of phrase in Scandinavian design, rings true in many ways for what Watermelon security tries to achieve with this application. It is after all our hope that this application will help and enrich the lives of its users through minimal effort and complications. 

The theoretical groundwork for our design process was based on:

Don Norman’s Design Principles (The Sourcebook for teaching science, 2007, Summary of Don Norman’s Design Principles, CSUN, viewed 27 December 2019, https://www.csun.edu/science/courses/671/bibliography/preece.html?fbclid=IwAR32GNqUa-rMK3Fvnfyughg6rNJSE-6aDBETtbkasHov7E0-wa11Bkqd8FY )

Usability Heuristics (Jakob Nielsen, 2005, 10 Usability Heuristics for User Interface Design, Nielsen Norman Group, viewed 27 December 2019, https://www.nngroup.com/articles/ten-usability-heuristics/ )

And a lecture by Susanne Frennert (Frennert. S, 2019, Lecture 5: Usability and UX evaluation, PowerPoint, Introduction to Interactiondesign DA157A-98090, Malmö University, delivered 12 December 2019.)