Introduction
Flatform is a conceptual design for a collaborative flat management app. It is designed to provide workflows for tasks which we gathered from a representative sample of individuals who live in flats. This is a condensed version of the research project, please reach out if you would like to know more.
Flatform increases overall coordination of flat tasks and chores by consolidating all features into one easy to use app. It has been designed using TCSD design practices with the intention of creating an app that is aesthetically beautiful, intuitive, and straightforward. During our discussions and design meetings, we prioritized simplicity and consistency. Flatform is designed to be a functional app which convincingly solves users’ problems, where simplicity and consistency is key. We do not want to irritate users, especially since flat management is inherently mundane. Additionally, we considered ease of use and intuitiveness as high priorities
the design process for similar reasons.
Initial Research: Interviews
We initially gathered information using in person interviews, as we felt these would elicit the most information and avoid suggestions of predetermined answers. This also allowed greater flexibility during questioning, and facilitated follow-up questions in areas of interest to get the best possible insight into the tasks users accomplish during their flatting experiences. We ensured that we were reaching a broad user group by not asking multiple people in the same flat, contacting people in other countries, and talking to people of differing age groups and living situations for a rounded sample pool.
User Identification
We identified a number of key user groups from our interviews and built some representative user profiles.
Task Identification
The tasks that we received from our users were all very similar, and we were able to categorize them into 4 key categories that covered these. These were Expenses, Chores, Organisation, and Social. We then identified task subcategories, and fitted our user's tasks into these. We circulated these tasks around the users we interviewed for validations (omissions, corrections, and clarifications) and established these are truly representative tasks.
Established Support
We decided following the task categorization and analysis which user groups to support, and which were implicitly supported (sufficient overlap with the set of supported users, thus implicitly supported)
Designs
These are a small number of my initial designs. We had around 50 sketches total, spanning across every task scenario. Every scenario had multiple sketches from multiple people. These were quick and non-detailed sketches to spark discussion. As a group we evaluated each persons designs on a set criteria and pulled pros and cons.
Initial Proposal
For consistency, we decided on the following things:
• Material Design components and design philosophies are being followed. Given that Material Design originates from Google, and has been adopted by most Google products, it is familiar to users.
• Using Material Design’s floating action buttons (FAB) for adding events and documents to the app. FABs are used for primary and common actions on screens, thus preventing the user from hunting around the screen for functionality. These buttons are only used when pressing them takes the user to a separate screen, so are not used in the shopping list’s add item dialogue.
• Using a common shell, which contains a header. The header contains a hamburger menu on the left hand side, the page’s title in the center, and a common action in the right hand side. These common actions are not primary actions - depending on the context, they can include search or filtering. Whilst we did consider not using hamburger menus, due to the study “Hamburger Menus and Hidden Navigation Hurt UX Metrics” from
Nielsen Norman Group, we decided that we would include it as we anticipate that our users are digitally literate.
• Swiping behavior has been implemented for a variety of lists, taking inspiration from apps like Gmail, Outlook, and Microsoft To Do. Included with this swiping behavior is snackbar components (small notifications which appear at the bottom of the screen) for undoing accidental actions. This will improve recognition over recall.
• Material Design components and design philosophies are being followed. Given that Material Design originates from Google, and has been adopted by most Google products, it is familiar to users.
• Using Material Design’s floating action buttons (FAB) for adding events and documents to the app. FABs are used for primary and common actions on screens, thus preventing the user from hunting around the screen for functionality. These buttons are only used when pressing them takes the user to a separate screen, so are not used in the shopping list’s add item dialogue.
• Using a common shell, which contains a header. The header contains a hamburger menu on the left hand side, the page’s title in the center, and a common action in the right hand side. These common actions are not primary actions - depending on the context, they can include search or filtering. Whilst we did consider not using hamburger menus, due to the study “Hamburger Menus and Hidden Navigation Hurt UX Metrics” from
Nielsen Norman Group, we decided that we would include it as we anticipate that our users are digitally literate.
• Swiping behavior has been implemented for a variety of lists, taking inspiration from apps like Gmail, Outlook, and Microsoft To Do. Included with this swiping behavior is snackbar components (small notifications which appear at the bottom of the screen) for undoing accidental actions. This will improve recognition over recall.
Conclusion
In short, we believe we accomplished our key goals of simplifying the flat management experience, and offering flexibility and ease-of-use to users.
We worked with a number of assumptions: that bank feeds will be obtainable to fill out the routine payments page, and that there is a flat bank account to begin with. We have not included one off setup tasks in our design as they were low priority - this included things such as a login and logout, adding or creating a new user profile, changing or removing notification settings. These would be further designs we need to consider as the design process progresses.
We worked with a number of assumptions: that bank feeds will be obtainable to fill out the routine payments page, and that there is a flat bank account to begin with. We have not included one off setup tasks in our design as they were low priority - this included things such as a login and logout, adding or creating a new user profile, changing or removing notification settings. These would be further designs we need to consider as the design process progresses.
We overlooked a number of features of designs that are implicitly stated on drawings or not included, however we would consider them going forward. In a further concept, we would include the list of split payments in the expenses tab, and allow users to view what payments have been split and whether/who has been paid in a similar format to the current bill payment views. We did not consider a way to name split payments, and would be an important further change to make. There is an inconsistency within the app where on the routine roster page there is only a swipe to complete and no checkbox whereas shopping list has both these completion options.
Our final designs are a compilation of our favorite features from each designers perspective, these features were discussed and refined to further advance the designs and ensure that all cons have been removed.
Our final designs are a compilation of our favorite features from each designers perspective, these features were discussed and refined to further advance the designs and ensure that all cons have been removed.
