A project completed as a part of the UX Tools & Exploration course at Maryland Institute College of Arts | September — October 2021 |
By: Alexis Leitner-Cohen, Avy Umphlet, Cassy Padilla, Rachael Laffoon
II. Planning & User Research
III. Initial Concepts, Content Strategy & Branding
As our Block Party team began to come together, we knew one thing: we needed to create a way for renters and homeowners in urban city environments to easily meet one another and nurture neighborhood relationships. Upon the guidance of our instructor, we were able to explore many UX tools throughout the 8 weeks of this project, some we loved and will definitely use again, others we might steer clear of.
Join us as we bring you along the journey we have been on for the past 8 weeks, and the tools that we used to guide us along the way.
Planning & User Research
I. Map out the different parts of the project & identify potential problem areas and areas of collaboration
II. Turn our design brief into an actionable plan, step by step
III. Recruit, screen, and survey 5–12 volunteers within a determined user-base
IV. Extrapolate data from the responses to build a behavioral profile of the potential audience.
First things first, we needed a plan. We came together as a group and made a Design Brief using a simple Google Doc. The brief included all of the important assets we wanted to incorporate in our app and the goals we wanted to keep in mind while planning and designing it. We formed a problem statement and discussed background, objectives, audience, tone, competitive positioning, strategy, and scope.
Once our Design Brief was complete, we started to move the information into our first tool, Trello.
Trello is a Kanban boarding tool, a project management tool used to help visualize work and keep everyone on the same page.
Trello came in handy to lay out the tasks that we would need to accomplish to complete the app. Our goals for this week were to lay out the groundwork we would need to accomplish for the design of the app and to divide up the tasks between our teammates. To do this, we essentially transferred the items from our Design Brief into cards on the Trello board.
What was most helpful about Trello was that our team could work in the program simultaneously, a must when it comes to working remotely. Trello has been designed to make complex projects easy to break down into visual categories, subcategories, and tasks.
Our group found a lot of success with the function that allows tasks or categories to be assigned to a specific person. We were able to utilize this to break down each objective of the Block Party step by step and have a visual representation of who was responsible for each section.
As with any new tool, there was a bit of a learning curve to overcome before it was mastered. One of the issues our group initially ran into with Trello was how to break down the information. With such a big project and so many components it felt a bit overwhelming, however we were able to find a template for project management and things started rolling from there. We tweaked the main cards to fit our objectives instead of starting from scratch, and this was key to us finding success with the tool.
Overall, our team appreciated the easy learnability that Trello offered, as well as the multiple ways a team can organize themselves within the site depending on the needs of the team and project.
Moving from the planning to the research phase of the study, we used Google Forms as a platform to screen and survey volunteers to gain insights directly from people that fit into our tentative user types. All of the members of our group were relatively familiar with Google Forms going into this week, but we did learn a great function of the tool that none of us were formerly familiar with.
Google Forms’ cloud-based service was especially handy due to all of us being in different time zones and having differing work schedules, as it allowed all of us to contribute to and edit the survey remotely, within our respective time availability.
One great feature Google Forms includes is the ability to make certain questions required, but our favorite was the ability to make questions conditional, jumping participants to different sections of the survey dependent upon their answers. We were able to use this one survey as a virtual screener option while also saving participants (and ourselves) time if a question didn’t apply.
Volunteers were recruited by all members of the group through various methods, such as posting to facebook or by contacting known viable potential research candidates directly. Due to the short time frame, recruiting volunteers was somewhat difficult, but not impossible. Once the necessary amount of responses were collected, we took advantage of Google Forms’ “export responses” function to populate responses to a Google Sheet where we could easily see all of the answers in one screen rather than scrolling through each participant’s survey individually. We used this Google Sheet to help develop behavioral audience segments in an organized manner.
To create Block Party’s behavioral audience segments, we needed to separate each respondent into a category by behavior (a theme in their answer). For this, we used Figjam, the collaborative whiteboard service by figma.com.
Our team is relatively familiar with Figma, Figjam’s mother service, as we use it frequently in the program that we are enrolled in through MICA. None of us had used (or even heard of) Figjam until we started this course. Our professor uses Figjam in every class we attend, so we have seen that it has many capabilities and can be used in a multitude of ways.
Figjam allows for collaborative remote work in real-time with access to whiteboard features such as post-its, markers, dot voting, etc. Figjam also includes the ability to import the results from a Google Form results spreadsheet directly into a board, placing each response onto its own post-it note. This is a massive timesaver, and an awesome integration of two tools that we will be keeping in mind for future use.
Once our survey results were imported into our Figjam, we decided as a group that two questions out of our survey were key to understanding our user-base:
“How did you meet your neighbors?” And “Describe a positive interaction with your neighbors.” (Shown top left in the two yellow circles). With that knowledge, we decided respondents fell into two categories, (shown as the long purple rectangles above the blue post-its) that we named the “Small Talkers” and the “Bestie Vibes”. We then moved our participants’ responses (blue post-its) into the category that they fit into based off of their responses to the two main questions.
Our main finding from this exercise was that both user types wanted to interact with their neighbors, but our Small Talkers were generally not as socially outgoing nor sure of how to approach their neighbors. Our Bestie Vibers, on the other hand, are more comfortable going out of their way to interact with their neighbors and secure future social interactions with them. Once respondents were separated by behavior type, we gave each respondent’s answers a nickname based off of something significant from their response to help remember them in later discussions for the project.
Initial Concepts, Content Strategy & Branding
I. Create an outlined flow to set up the basis for our first design sprint
III. Content strategy: what are the essentials?
IV. Create a cohesive mood board with a color palette, the right fonts to use, and the key branding aspects of our app
III. Google Suite
Our class during week 3 was all about Design Sprints. Our professor explained to us the 5 typical steps of a design sprint and how they are beneficial. We then jumped into an abridged version of a design sprint that started during class and was finished throughout the week by our group.
We continued to use Figjam for the entire design sprint, seeing even more capabilities that the tool possesses. As seen below, we started by placing our overall goal of Block Party, and then looking critically at our idea, deciding what could essentially make it fail and creating “how might we” statements based off of these potential downfalls.
Next, we created a map (below) of the steps our users typically take to achieve their goal (connecting with neighbors). Using Figjam for this process was completely painless, the post-its and shapes are so easy to just pop into the board, and the ability to color code them was beneficial for us to show where they connected to each other. Figjam also includes an arrow tool that we took advantage of during both of these exercises. The arrows are easy to manipulate and only enhance the color coding method.
Next, each team member picked a potential fail/HMW statement and we did a timed exercise where we spent a few minutes jotting notes, ideas, and solution sketches for our respective issues. We uploaded our sketches to the Figjam and used the dot-voting tool to vote on the ideas that we felt held the most weight.
Using our heaviest ideas, we created a user test flow to flesh out the steps that our users needed to have access to so that they could achieve the goals.
Using the test flow, we created a quick storyboard to get the feel of how the actual screens will be set up in the app. Using Figjam for this step was interesting to our group because before this we had always used a prototyping tool for wireframes.
Using Figjam forces you to really keep it simple, and helps you to not get bogged down by the little details. Utilizing post-its to add interaction notes, and arrows is a nice touch for this process, but we are not sure that we would use Figjam for wireframing in the future.
Branding came after the initial design exploration. Our tasks included nailing down our branding guidelines as well as creating a content strategy for the app. We streamlined our process by creating separate mood boards on InVision, an app for aggregating images, words, and notes. Color, imagery, and style guidelines were on the forefront of our minds and we each took a couple of days to drop in images and thoughts that described how each of us envisioned Block Party. We then collaborated afterwards to combine the boards into a cohesive whole.
To solidify our content strategy, we met together on a Zoom call to work out the details in a Google doc. The Google Suite has been the bread and butter of our online work due to it’s incredible collaborative capabilities. We were able to easily create a content strategy map in the doc and as a team, we felt better working together in real time so that essential decisions could be made, changed, and edited together. We didn’t have any trouble with our content strategy page, however we did run into issues during our time with InVision.
InVision was a difficult app to work with. Although the ability to create separate boards on the same page was efficient and useful, the way the site has you move images around can get chaotic, and we found that some of our content would disappear and we would have to frequently replace it. An image was only guaranteed to stay if you uploaded it from your computer instead of using drag and drop. Working collaboratively is also difficult because new content doesn’t appear in real time, we would have to refresh the page each time we wanted to see the new content. As a website InVision still has a lot of bugs to work out and we wouldn’t recommend using it for any serious project work.
I. Follow the storyboard to make the start of a prototype.
II. Implement the decided design features to the prototype and create interaction elements.
II. Figurative (Mobile Version of Figma)
III. Zoom (for virtual meetings)
IV. Blush Plug-in for Figma
V. Content Reel Plug-in for Figma
VI. Google Docs
Weeks 5 & 6 brought along with them design time. Each group was given the choice of using Sketch, Adobe XD, or Figma. As mentioned earlier, we all feel pretty at home in Figma, as we have used it the most throughout our program at MICA. Some members of our team wanted to try out another app to get some practice with the other tools out there, but we ended up using Figma due to cloud capabilities and the service being web-based.
After finalizing our mood board, we added our color palette, fonts, and other design artifacts to our Block Party Team Figma.
Rachael created a screen guide with safety margins and a navigation bar as seen to the left; this was used as the screen basis for all of the screens created.
Each group member returned to their portion of the storyboard to create the corresponding prototype screens on their own page within the Figma file. We each designed our sections of the prototype with our own design ideas and later critiqued the screens to make the designs more cohesive between parts.
Once that was done, all screens were put together into the main prototype page and further design edits were made, including updating the navigation bar, adding characters/illustrations, and other features to each segment of the app. Cassy found a great plug-in for Figma called “Blush” which provides customizable illustrations in the style we wanted. The “Blush” plug-in was used to revamp our navigation bar, and all of the other imagery seen in our screens from this point forward. Avy also noted that our prototype looked fairly plain with blank backgrounds, and suggested adding background colors. As a group we decided to use muted versions of our color palette for background colors in order to keep the look cohesive.
At this point, we started to patch in prototyping interactions to allow user movement between screens and items. Another great feature of Figma is that different features can be made into components, which are copyable from the main component to each page. These components can be edited into “variants” of the component, allowing for button hover states, radio buttons, and other highly customizable interaction design.
When these components and variants are copied and pasted to a screen (an instance), if the main component is edited, so are all other linked instances of that component or variant. We also really like that if a prototype interaction is built off the component or variant, each instance of those features will also contain that interaction. Each instance can be detached from the main component or variant as well. This function is also a massive timesaver, and in this field, timesavers are imperative.
After the group critique, Rachael was assigned to be in charge of art direction for the app in order to make the design and content even more cohesive and consistent.
Following this directional update, a new color palette was introduced with brighter key colors. Those colors were implemented across all screens, including the welcome/landing screen, in order to make the app more inviting and reach a higher accessibility standard for inclusivity.
The low contrast of colors from our original design lead to low readability, which could have alienated vision impaired and reading challenged users. Lower amounts of text per placement (I.e. information blocks, buttons, etc.) also aid in helping users with reading and vision issues have an easier time using the app.
Aside from the visual design updates, Alexis oversaw the user interaction (UI) design flow updates and micro-interaction state updates. This was to include details within the interactions that lead to a more seamless experience. This included button hover states, a collapsible and expandable nav bar, and inter-screen animations. Updating these screens with the new design constraints lead to us focusing as a group on flushing out four main features of the app, including for the map, the profile page, the building page, and the bulletin board. Below is a visual walkthrough of the final design.
With more time, next steps would most likely include integrating contact lists and a map (from Google Maps or some other mapping service), adding a user verification pathway, adding a bulletin board event management screen for users (including a calendar view), and developing a pathway to ‘friend your neighbor’. Each of these features would have to be fully flushed out with UI and match the visual design and branding guidelines of the rest of the app.
I. Package up finalized elements of design
II. Submit our prototype alongside our case study for review
II. Google Docs
Week 7 of our study included the finalization of any design updates and text recounting our work presently. We began by solidifying our prototype in Figma to create a walkthrough of the completed Block Party app and all of its included features.
Once all of our design elements were finalized and exported, we received comments on our case study rough draft, which led to our final rounds of edits. Our team worked collaboratively using Google Docs and completed the assigned sections of our weekly additions and edits to our project, with Rachael acting as the editor and making sure our writing was cohesive and explained the story we were trying to convey.
Moving into our final task, uploading our case study into Medium for submission, we needed to finalize our text within Google Docs and transport it over to Medium to be published. Moving forward, we would hope to build out our prototype to include more of the features that Block Party offers, and show the currently mapped out ones in more depth. Our prototype could be used for user testing through sites such as Maze. Figma allows those who have the file shared with them to view it in a mode where they can make comments but not have to see every single design detail, so we chose to use Figma as a handoff tool — with stakeholders ideally being able to directly communicate their thoughts with us in our file.
Thank you for following along with our journey as we explored new tools and laid a solid groundwork for an app that our Block Party team became very invested in over the last eight weeks. We learned so much about so many of the tools that are out there and the different ways that they can be utilized, and most importantly, we had a great time while doing it.
— Block Party