Alignment

First, the BloomSky teams had to get on the same page.

To ensure the redesign project would run as efficiently and effectively as possible, we had to align the different teams. The BloomSky mobile app had previously been through four ground-up redesigns and our design team also saw an opportunity to focus future time and energy on other worthwhile causes. Through observation and discussion, we determined that the primary cause of this inefficiency was lack of product direction paired with lack of process. Without the directional momentum created through a product vision, the app took several unsuccessful turns as different teams and people focused on different, sometimes conflicting, ideas (e.g. promoting social sharing of weather data and images vs. providing historical data for weather station customers). Also, without discussing and agreeing upon a design and product development process, BloomSky ran into delays and inefficient time management that could have been prevented with planning and communication (e.g. arbitrary deadlines would create overly-pressured timelines, which in turn created oversights and mistakes that required more time to fix than it would have if the deadline had been placed further out to begin with).

So, we outlined our design process with the product manager, who then spoke with the CEO and team leads about process alignment and integration. In the meantime, the design team started by creating a knowledge foundation to rest the remainder of the project upon, including the product direction.

Design Process & Workflows

Every project's specific process and phase lengths varies based on its individual contexts and constraints. Three primary phases are usually beneficial for most projects: 1. Information gathering and research, 2. Ideation and strategy, and 3. Testing & iteration. With frequent communication, we plan to work closely with the other teams to stagger and integrate our workflows for maximum efficiency in the face of potential changes and blocks.

‍

‍

Heuristic Evaluation

It was best to start from scratch equipped with knowledge of the previous app.

Because the app's primary designer was no longer part of the team and after discovering that some of the app's navigational structure would be extremely difficult to change due to the code's structure, we decided starting the design from scratch would be the best approach due to the importance of restructuring the navigation and increase in project speed. To stagger and optimize workflows, we agreed that the design team would move towards the product vision and information architecture map while the engineering team would work on improving overall app performance including speed and reliability, since slow loading times and crashes were one of the top user grievances. The design team began by doing heuristic evaluation of what was & wasn't working in the app, and taking into account existing user feedback. 

We took note of the opportunities available to aid us towards accomplishing our priorities:

‍

Information architecture, interaction, and content & labels problems

The information architecture did not align with user expectations and usage. Example 1. (see 2.1) Users use the app to view their purchased weather station, current location, or other frequently visited locations, but the first screen that showed upon opening the app is Trending Stations; 2. Users have difficulty finding the list of their followed stations.

There was a general lack of app feedback and states for user actions, including errors, leading to user confusion and/or frustration during times of app unresponsiveness.

The content and labels sometimes did not provide useful or clear information, creating visual noise and confusion. Example 1. (see 1.1) The address in the header did not provide a strong association to locations in the mind of the user. The abbreviations were confusing to the user, especially when the addresses were outside the user's country of residence; 2. (see 1.2) The second line in the header was not recognizable as the weather station name; 3. (see 2.2) The distance data is not useful for the user and becomes visual noise and distraction; 4. (see 3.1) The multiple map icons did not provide valuable information quickly such as major temperature change within a small area, and instead made it difficult for the user to proceed with their next tap.

Weather photos and videos did not clearly correlate with date and time. Example (see 1.3) If a device is offline, there is no indicator that tells whether the temperature still current. If there is a video button, there is no indicator that tells what time the photo and temperature belongs to.

Feature and weather data problems

Certain features such as the Trending Stations screen did not provide value for the user.

Data that the BloomSky weather station records and displays such as humidity is not widely understood by many users, leading to visual noise and distraction.

Weather station customers were dissatisfied with the detail and history of data provided, despite the weather station's capability to measure the information.

Visual communication design problems

The overall visual hierarchy was poor, leading to confusion and overload. Example (see 1.4) It is ambiguous as to what the user would save and share when they tap the save and share buttons. Is it the weather station, image, or video? If it is the image or video, which date and time?

Typography and iconography was sometimes too small, thin, and light-colored to read easily on a mobile screen. Example (see 3.2) The search symbol is hard to recognize due to shape, size, and color.

Colors sometimes distracted rather than aided in visual hierarchy, grouping, and focus. Example (see 2.3) The tab navigation and corresponding header look unrelated although they function together.

Iconography sometimes did not consider existing iconography language and user understanding. Example 1 (see 1.5) It is unclear whether the follow button lets the user follow another user (as the icon means) or follow the weather station (as the icon does). 2. (see 2.4) The Search Map icon does not indicate search or a map.

Without a unified visual identity existing at the time, the app styling was inconsistent with other BloomSky products and services.

Other areas for improvement

The app had poor technical performance including a high crash rate and slow loading times.

The BloomSky weather stations were distributed in too wide of an area to provide meaningful local weather to the majority of users, sometimes even in the Bay Area where BloomSky started distribution.

Weather station customers had privacy concerns. Example (see 1.1) BloomSky weather stations were automatically public without user knowledge, and their address details (usually on their residences) showed to anyone who used the app. 

‍

‍

Personas

Personas John and Sarah were created to represent our two primary user groups.

I participated in a user interview with the user research team, in order to get a better understanding of why existing users use the app and what value it provides to them. With this understanding, we hoped to better surface the app's benefits through solving the existing problems of features, content & data, information architecture, and interface design with awareness of the users' needs and their contexts. After being briefed on the user demographic research and the rest of the interviews, we sat down with the user research team and created our two personas representing our two primary user groups:

‍

John is a BloomSky weather station customer, traveler, and technology enthusiast.

In his 30's, John lives and works in the city as a middle-class citizen. He loves tinkering with new technology, like when he set up a smart home system for his house. He also engages in many types of outdoor activities including biking, hiking, skiing, and surfing.

He checks current and historic weather patterns out of curiosity to pass time and to prepare for his occasional trips. He also finds the relationship between weather visuals and numeric data interesting.

He purchased a weather station for his house as well as his parents' in another state, which he occasionally checks out of curiosity for 'what it's like over there'. He likes to stay aware of any extreme weather and anomalies for himself and his loved ones.

‍

‍

Sarah is a BloomSky app-only user, busy mother, and corporate employee.

In her early 30's, Sarah is married, mother to two young kids in elementary school, and upper middle-class citizen in a Bay Area suburb. To Sarah, the health of her children and control over her busy day-to-day life is of utmost importance. In order to stay on top of her game, her routine, self-control, and resilience are high on her list of priorities.

Sarah checks the weather in order to prepare herself and her family for anything the weather may throw at them during the full day ahead. Because she is limited on time, she uses the weather photos and videos alongside the weather data to more quickly understand what the weather is and will be.

Sometimes in the evening while spending time with her kids, she shares the timelapse video recording of the day to help them better understand technology, weather science, and nature appreciation. She also shares any unexpected weather patterns to help out her equally-busy friends.

‍

‍

Competitive Analysis & Field Research

BloomSky's competitive advantage was the nature of its photographic product.

We reviewed some of BloomSky's major competitors to understand their positions. This information supplemented our existing understanding of BloomSky's competitive advantage of its photographic smart weather station; and guided our brainstorming of where we could place ourselves in an unoccupied space in the minds of our users and customers. During this time, the research team also briefed us on perceptions of weather metrics, the science behind the metrics, and the technical details and limitations on creating weather data.

‍

Weather Underground provides detailed microclimate weather.

Weather Underground is BloomSky's primary competitor, working from a similar value proposition of providing weather through a community data network. It has a solid spread of stations as well as a detailed and accurate data over time, giving them the ability to more accurately make forecasts for microclimates. Weather Underground is an app that persona John would take great interest in for his weather needs (see 1).

The Weather Channel is trusted to provide reliable information.

The Weather Channel is another major BloomSky competitor and its strengths are its data reliability, its long-standing brand and reputation, and as a result, the trust it has from its users. It is an app that persona Sarah would rely upon for her getting her daily weather information (see 2).

Yahoo Weather provides weather information efficiently and beautifully.

Yahoo Weather's display of data and information is one of its major strengths. Its efficiency in communicating large quantities of data through visual simplicity and beauty would appeal to both John and Sarah (see 3).

‍

‍

Product Strategy

BloomSky had an opportunity make weather information more intuitive.

As a guide for now and into the future, the design team created the BloomSky app product vision. With its live weather photographs alongside the variety of data its stations could measure, BloomSky could span the gap between the complex and the intuitive. With its network of consumer weather stations, BloomSky could grow and evolve leveraging its product in the following ways:

Humanized Weather

BloomSky's weather photographs aid in the understanding of the weather numbers and we can take that one step further. BloomSky could bring weather closer to home by providing friendlier language, visuals, explanations & education, smart behavior-predictive suggestions, and up-front weather notices including alerts for safety and preparedness.

One example of this idea is that by understanding that weather is relative, BloomSky could use time and place comparisons to help users more accurately and quickly understand how the weather might feel. In addition, it could provide information and teach users the weather data metrics that the majority of people do not understand. With the extra context on the metrics, persona Sarah could gain a better understanding of the day's weather and better prepare for it.

This idea of humanized weather can also be extended to travel by providing users with important metrics based on location. For example, in Thailand, humidity is an important weather metric, but that would not be on the radars of first-time visitors if they live somewhere where humidity does not affect them often, such as the Bay Area. BloomSky could learn to predict this and offer that insight to help persona John while he is looking up the conditions for his next trip.

Visual Weather

This idea focuses and expands upon the live weather photographs that the BloomSky station records. BloomSky could further immerse the user in visual information by providing weather photographs across an area, in contrast to a pinpoint location as it currently provides.

This idea can be expanded to microclimate areas, providing a collage-view of the sky in a neighborhood, or to large areas such as a city. This information would provide Sarah with more visual information to reliably and quickly understand the weather from a glance.

Visual weather can also expand linearly to provide the conditions along roads for scenarios including commutes and long road trips. This would help John prepare for a wide variety of road conditions on his way to his next trip in Tahoe and see that snow had already begun falling on the road towards his destination.

Local Weather

BloomSky's network of weather stations allows it to accurately calculate and forecast weather for small areas such as neighborhoods, dependent upon the number of stations as well as the length of the area's data collection history. In the future, this could inform John that the seaside where he is planning a biking day trip is much colder than the city average, or it could help Sarah better choose her children's outerwear because the school they attend for most of the day is much warmer than the city average.

This idea can also be expanded into the social and business realms to provide outlets for community leaders and businesses to communicate with their audiences. For example, a park could provide its weather conditions via the app, a widget on its websites, and other touchpoints, so John or Sarah could see a view of the place and get a better idea of its weather conditions.

Backcast Weather

Because BloomSky creates and distributes its own weather stations, it has the potential to provide detailed and insightful historic weather data and gain data independence & trust over time since BloomSky still depended on third-party weather data providers for its forecasts.

This idea could be extended to certain features such as video scrubbing for historic weather photos and data, which would allow users to scan a set timeframe at their own pace (rewinding, fast-forwarding, slowing down, speeding up, pausing). This would help both John review his home station's daily weather data—rewinding and fast-forwarding when he sees something interesting—and Sarah review the day's weather with her children at all their paces.

Global Weather

On the other end of the spectrum of local, BloomSky has the opportunity to bring faraway places nearby. It could provide weather content browsing for interesting, beautiful, and landmark areas and events around the world. This could take the route of content curation or community content through tagging and appreciation. This would provide John with more to look at when he is taking a break from work, or Sarah with more to show her children during their times of sharing.

‍

‍

Product Design

Potential features were documented and organized into functionality groups and screens.

Guided by the personas and product vision, the design team brainstormed essential features for an MVP app (minimum viable product) to tackle the existing problem of superfluous, distracting functionality. Then we card sorted the features, from which we discovered the app's initial screens, and reviewed the plan with the product manager and engineering team for alignment and feasibility. With their product and technical feedback for what could be accomplished within the month, we prioritized the functionality necessary for the MVP app, which would contain basic weather functionality with time-relative weather (e.g. 6° colder than yesterday) and BloomSky weather station necessities such as initial product setup.

Here is a snippet of our card sort, digitized and shared with the rest of the teams for input:

‍

Location List Functionality

The location list screen will include relevant weather locations to the user (i.e. purchased stations and followed locations) alongside functionality to edit locations, rearrange locations, and add & set up BloomSky weather stations. This would give persona Sarah quick access to the locations she and her family frequents (e.g. school and work), and it would give persona John easy access to the status and data of his purchased weather stations.

Weather Information Content and Functionality

City: The city weather screens will include location information, current weather, and forecasted weather. Cities without the minimum number of BloomSky weather stations to provide an accurate city average will use third-party data and contain a call-to-action to purchase a station or share a coupon to address the problem of lack of BloomSky weather network coverage.

Weather Station: This screen includes station and location information, historic weather data, current weather, and forecasted weather.

Search and Map Functionality

The search interface will help users find specific locations and stations with functionality to sort and filter. The user can also browse via the map interface and view curated locations & content. This is necessary for Sarah to add her locations for the first time or view weather for a one-off location (e.g. for a family day trip), and for John to browse weather across different areas or add a new location (e.g. for an upcoming trip).

Support and Miscellaneous Functionality

Onboarding: The first app screens the user will see will explain the value and usage of the app before the user is presented with the signup and login prompt, after which they can continue to browse public locations or set up a purchased BloomSky weather station. The app introductions would help users like Sarah to better understand and confirm how they can benefit from using the app.

Weather Station Setup: The customer is guided through the setup of their BloomSky weather station including internet connection, account connection, privacy settings, and general settings (e.g. naming). This is necessary for John to set up his purchased weather station to a working status.

Settings: The user can view and change account, notification, weather, and station settings.

‍

With the engineering team, we also discussed and determined the prioritization of technical infrastructure setups for future functionality:

1. Dynamic search of locations (e.g. searching by station name, city name, zip code, address)
2. The visual weather map
3. Local weather calculations with high accuracy and reliability
4. Increased touchpoints (e.g. Android screen & pull-down widgets, iOS widget, notifications, and digest emails to account for the diverse platforms from which users may engage)
5. Independent backcast data with scrubbing
6. Forecast data independence
7. Potential customized animations for user spatial and navigational understanding
8. Easy to read and understand weather alerts
9. Content curation platform
10. User tagging functionality

‍

‍

Information Architecture

We diagrammed an information architecture to aid our mental map of the app structure.

From the card sort, we took the screens and visualized them & their connections into an information architecture diagram. For this part of the process, we aimed to create a clear structure with hierarchy determined by how users use the app, while ensuring that structure would work seamlessly for both personas  John, a weather station customer, and Sarah, an app-only user. With our ideas more solid and less abstract, we used the map to 1. communicate the underlying app structure with the engineering team so they can continue their workflow and with the product manager for alignment, 2. reassess and revise our timeline based on the updated workload, and 3. use as a visual aid as we head into wireframing the structure of the screens.

‍

Underlying App Structure

After the initial onboarding screens, the app funnels the user to where they want to go, whether they are a weather station customer needing to set up their device for the first time, a first-time app-only user seeking for weather information, or an existing user. With this setup, both personas John and Sarah can achieve their goals without going through unnecessary screens (see grey screen). 

The three primary screens and main navigation tabs are Browse and Search, My Locations, and Settings, based on the primary uses of finding a location and viewing its weather. The other screens fall under the three primary screens based on their logical relationships and relevance to each other (see red screens). 

The meat and bones of the app are the weather information screens, which are similar in content and functionality with a few distinctions. For example, weather station owners can make changes to their station settings from the weather information screen and city weather information screens with third-party data will not have BloomSky weather station data including photo collages (see teal screens). 

The weather station setup process can be initiated either after the onboarding screens or from the settings for the multitude of use cases around setting up a weather station, including first purchase and setup, following purchases and setups, relocation, replacement, repair, and resetting (see yellow screen).

‍

‍

Wireframing

Wireframes within a clickable prototype were created & used for testing & collaboration.

Using our information architecture, we flushed out the layouts of the primary screens. While designing the screens, we prioritized clear information and functionality hierarchy to aid in navigational ease and avoid previous problems of confusion and overload. Afterwards, they were connected into a clickable prototype for usability testing & validations, internal team discussions, and as references for the engineering team to start the framework and functionality of each screen.

‍

Onboarding

App Introduction: We aimed to make the app onboarding flow more meaningful, especially for first-time users, due to the previous problem of app-only users not understanding why they should use the app and what value it provides them. The first experience of the app will be a brief introduction that explains what BloomSky provides in order to increase awareness, set expectations, and confirm assumptions. (see screens 1–4). 

Login: Then, the user gets funneled to the appropriate flow based on whether they are a new or existing user. If the user has an account, they will be prompted to log in with an option to reset their password (see 5–7). 

Location Services and Notifications: Afterwards, they will also be prompted to turn on location services and notifications for an optimal app experience (see 8). These screens provide context as to why a user would want to enable these services and increase the likelihood they will accept when the OS prompts appear.

‍

‍

Walkthrough Tutorials

Tutorial Highlights: After the user lands on the weather information screen of the weather station closest to them (if they allowed location detection) or the BloomSky Office weather station (if they did not), highlights will prompt the user to tap and learn more about using the app—one of the ways we addressed the previous problems of unclear navigation, functionality, and "where to go" & "what to do" (see screens 1–8).

Location Reveal: The menu icon highlight will help users understand their context within the app and how to browse other relevant locations to them, which was difficult to find in the previous app (see 1–2).

Customization Prompt: The add icon highlight will help users understand the next steps to take to personalize their weather locations and make the app useful for them. A call-to-action will show below the intially-provided locations if the user has not added any additional locations to serve as a reminder to do so (see 3–4).

Timelapse Prompt: A second visit to a followed location will show the timelapse icon highlight, which will help users understand where to access historic information and how screens are positioned based on their timeframe (i.e. now versus past) (see 5–6). This addresses the previous problem of data correlation confusion of image and time by having a designated area for "now" and a designated area for each previous day.

Follow Prompt: A visit to a location from search will show the follow button highlight, which will help users understand the next action to take if the location is relevant to them. The call-to-action of "sign up & follow this location" sets user expectations, so they will know that they need an account for the app to keep track of their followed locations (see 7–8). The account creation request is placed within the app at a time when it is necessary, so first-time users can experience and confirm the app's value before commiting to an account.

‍

‍

Location List

Location List Functionality and Content: The location list screen displays a user's relevant locations in a primary location (first navigation tab) that not only addresses the previous problem of users' inability to locate their followed locations, but also reinforces the primary value of BloomSky—providing weather through followed locations or purchased BloomSky weather stations. It provides adding, editing, rearranging, and removing capabilities for users to customize their list. In addition, the screen allows the user to quickly scan weather information for their entire list including weather station status and location weather conditions. To address the label problems that previously confused users, we ensured that only relevant and significant information necessary to determine a location is provided on the list. Further information would be provided after tapping on a location. To address the information hierarchy problems, we ensured logical information grouping and visual division (see screens 1–2).

Editing a Purchased Weather Station: If a user decides to edit a purchased weather station, they can change the station's information including name, description, location, and search privacy. In addition, they can initiate station processes such repositioning the camera view, relocating a station or replacing a station while keeping continuation of data records, deactivating a station temporarily to e.g. change the wifi network, and linking a BloomSky indoor weather station if its placed at the same location. Information and functionality is ordered and grouped by frequency of change and relation to one another (see 3).

Renaming a Followed Station: Users can rename a nickname for a followed location (see 4). The nickname provides the option to use a more relevant and memorable name to the user (e.g. office, work, school) rather that using a default of address or weather station name designated by the owner.

Mental Anchors: To address the previous problems of navigational and informational confusion (i.e. "where am I" and "what am I looking at"), simple functionality such as renaming, removing & adding were designed as modals and locations being edited were referenced in order to create a strong association with where the user was in the app and what was being edited. (see 4–6).

‍

‍

Weather Information

General Solutions: The weather information screen is the meat and bones of the app. It provides the values and promises that BloomSky holds for its customers and users.  A few methods were used to handle the previous problems of confusion, distraction, and unreadability found in the weather information screens. The information is sorted and grouped by importance and relationship to one another. Iconography was based on existing icon languages and used to support & bring focus to information. Clear labels and headings were used to designate and provide context for information. Past, current, and future weather data are clearly separated & labeled; and connected through animations and spatial context for stronger conceptual understanding. Visual noise of foreign data was decreased through grouping, sorting, visual treatment, and explanations that can be accessed by tapping on the data (see screens 1–4).

Data: All variations of the weather information screen contain current and forecasted weather. The current weather data contains location name or nickname if available, data time, camera image, station status, extreme weather alert if available, temperature, relative temperature via time, temperature high and low, condition, rain, wind, UV, humidity, pressure, and sunrise & sunset. The forcasted weather data contains hourly conditions & temperature for up to 24 hours (if the section is expanded) and daily conditions with high & low temperatures for up to 10 days (if the section is expanded). The low temperatures are staggered to show when the low temperature will occur (i.e. between the night of that day and the morning of the next day) (see 1–4).

Weather Station Screen Variations: The weather station variation also contains station profile and historic data. Businesses can display their address; long-holding the address will copy it with a copy confirmation appearing after 1 second, and tapping the address will prompt the user to confirm opening Google Maps if installed, Apple Maps if not, to navigate to the location (see 1–2). The weather station variation that would be accessed from the search will have a follow button for users to add to their personal list and will be missing the tab navigation at the bottom, which would force users to exit only via the back button and be a reminder that they are in search mode, ensuring wayfinding soundness (see 2).

City Screen Variations: The city variation contains a collage of weather photos versus the single one, so users will be able to gain a better understanding of the overall city view. The collage of photos can be shuffled to show different stations and tapped for further exploration of individual stations (see 3). The third-party-data city variation would not have enough BloomSky weather stations to provide accurate city weather averages through BloomSky data, so it would have no photo and contain a call-to-action to expand the BloomSky weather station network (see 4). With this alternative solution, we strived to begin tackling the product distribution problem that affected many users who could not get meaningful local weather due to too wide of an area of initial product distribution.

‍

‍

Location Options and Support

Location Nicknames: If the user taps to follow a location that is a weather station and not a city, they will be prompted to give the location an optional nickname, if they would like to (see screen 1). The nickname would provide a stronger location association to the user in comparison to the weather station name set by its owner or an address. A preview of the location is shown for reference and to help the user more easily find it once they go back to their location list.

User-Relevant Functionality: Users will have access to certain editing functionality based on their user type. If they are a weather station owner, they can see the options refresh data and edit device settings. If they are an app-only user, they can see the options refresh data and follow if they have not followed the location, or edit nickname and unfollow location if they have (see 2).

Location-Relevant Labels: Users will have access to certain sharing functionality based on the weather information screen type (i.e. personal or business weather station and city). The change in labelling will solve the previous problem of confusion surrounding sharing ambiguity. If it is a weather station location, users will be able to save photo, share photo, and share device page. If the weather station belongs to a business, users will be able to share location page instead of share device page. If it is a city location, users will be able to save photo collage, share photo collage, and share city page (see 3).

Options via Gestures: Based on existing user affordances, tapping and holding a photo will also give the user options to save or share the photo in addition to finding these options in the top right hand more icon. Dragging the screen down will also give the user the ability to refresh the data (see 4–5). This makes frequently used options easier to access via gestures instead of tapping multiple times through menus and options.

Weather Station Help: Weather station status icons can be tapped to learn more about the weather station statuses and quickly take action if necessary (see 6–7). This accounts for the previous problem of lack of app states and feedback for errors, which lead to user confusion and frustration. Common states with customized screens are error, low battery, offline, and sleeping. At the bottom of each of the help texts are a call-to-action to contact BloomSky support.

Friendly Weather Alerts: In the direction of our vision of humanized weather and in an effort to make weather alerts more user-friendly (not in a giant paragraph of all caps text), an idea was created to divide weather alerts into scannable sections with clear headers in sentence-case text (see 8).

‍

‍

Timelapses

Spatial Placement via Z-Axis and Navigation: Due to previously confusing relationships between data and time due to the app's information architecture and screen layout, we designed the new historic data screens to be in a completely different, yet related space within the app—using the screen's z-dimension through scrolling up and down in order to visualize past, current, and future time. Pulling down on the weather information screen pushes the user into a timeline where they can pick through past days. Two variations were created for what was technically feasible within our project timeline (see screen 1) and what can be created later (see 2). Users can also pan from day to previous day and vice versa using the arrows found near the top of the timelapse data screen or swiping left and right, giving users an quick way to change dates without returning to the timelapse list each time (see 3).

Historic Data Detail: To address the dissatisfaction customers had with the detail of historic data provided (i.e. previously only temperature and time), despite the station's capability to measure and capture the information, we designed a timelapse design that shows the video (created by all the snapshots taken within the day) alongside all the data that a BloomSky weather station can capture (see 3).

Video Scrubbing and Time Context: The user would be able to scrub the video and data at their own pace or play it automatically and forward or rewind by 2 hours to keep the video's time increments aligned with the video's weather time data (see 3). The fowarding and rewinding were labeled with hours to correspond with hour of the day instead of seconds and minutes to correspond with video length because, previously, when the videos had used video length, users were unsure how much to pan to get to a specific time since the videos did not start and end at consistent times due to sunlight changes throughout the year. By aligning with user expectations, we aimed help decrease frustration from needing the video to load multiple times at multiple points of panning.

Summary Data: Below the video area, the users can view average and summary data information from that day including high and low temperatures, condition, pollen, temperature, temperature context and difference, wind, rain, UV, humidity, and pressure. This gives weather station owners access to more captured data and users in general a broader view of the day, which could be used to see overarching weather trends (see 3).

Optional Timelapse Notifications: On the user's first visit to the timelapse data screen, the user will be prompted to turn on notifications for daily timelapse availability for their locations. This was designed to create awareness of the existence of this option as well as avoid notification noise if the user would not find the notifications useful (see 4).

Options Access: The user can access video options by tapping on the more icon to reveal a menu for saving and sharing or by tapping and holding on the video for access via the common and expected gesture (see 5).

‍

‍

Animations

Custom Scroll Animations: To aid in the recognition of the app's spatial structure, we created custom scroll animations that supported the screen placements (see screens 1–13). This was aimed at solving the problem of a lack of correlation between data and time of capture by creating visual grouping via the app's z-axis. The animations were quickly mocked up using moment-by-moment snapshots to communicate with the engineering team for technical feasibility of future production.

Scrolling Down = Forward in Time: For the weather information screen, the scrolling of stacked "cards" created the visual illusion that they did not exist in the same space on the z-axis (see 1–7). First, the current weather data would scroll "under" the weather photo so the image is always viewable and related to the numeric data via grouping (see 3–4). Second, the forecasted weather will scroll "over" the current weather data, creating the correlation between time and app space (i.e. moving forwards is going into the future and moving backwards is going into the past) (see 5–6). Third, the location information card will scroll over the forecasted data, to visually and spatially create grouping and separation of information (see 7). In addition, when scrolling down, the top and bottom navigation bars will pan out, to provide additional screen space for information consumption. Scrolling up at anytime will bring them back into view (see 1–2).

Scrolling Up = Backward in Time: Scrolling up from the weather information screen will show the refresh module; if they let go at this point, the screen will refresh the weather data (see 8–9). If the user pulls down further, they will see a prompt to continue pulling, and if they pull down more, they will see the "yesterday" module; if they let go at this point, the yesterday timelapse data screen will "fall down" from the top of the screen (see 10–11). If the user pulls down even further, they will see a snippet of a list of past days; if they let go at this point, the timelapse list will fall down from the top (see 12–13). The visual illusion that the timelapse screens are from the top and/or from behind the current weather data emphasizes that the timelapses are from the past.

‍

‍

Weather Station Setup

Setup Process and Error Avoidance: BloomSky weather station owners must set up their new station by connecting it to a wifi network and a BloomSky user account before it can capture and display weather data. A device can be set up from the app onboarding (if the user is opening the app for the first time) or from the location list and settings (from within the app). The starting screen of the setup flow provides information to ensure the user does not run into common errors during the setup process (see screen 1).

Navigation: Once the setup process begins, at the top of the screen is a navigation bar that allows a user to go back, see what step they are on within the entire setup, and exit the setup. This helps the user from getting stuck during the setup and sets expectations for how long it will take & where they are (see 2–4).

Setup Instructions: Throughout the setup, the app does the job of an instruction manual and informs the user what to do, what to look for, and where, at an appropriate time to avoid information overload (e.g. the power button is located on the bottom of the station; a red wifi light blinking means the weather station is on and ready to set up) (see 2).

Photo Testing: The photo test gives the user an easy way to see what their camera sees during the setup. With the photo preview, they can readjust and test as necessary (see 3). Otherwise, the alternative was to complete the station setup and wait for the 5-minute photo refresh rate of the station for each reposition, which would make a quick and simple process much more time-consuming.

Profile and Privacy: Afterwards, the user can change their station profile including name, description, and search privacy. Privacy had been an issue with customers previously because search results would show the address details of weather stations placed on customers' residences. To address the issue, search privacy was introduced as well as location approximations, in which the station's location pin would show on a randomized point within a circle around its location and the station's location would show as "Private address within neighborhood or city name" (see 4). After the setup, the user is once again confirmed of their privacy in the context of a location pin on a map to explain visual address privacy (see 6).

Setting Expectations: The next screen confirms setup completion and gives the user expectations on what to do next and what to keep in mind to reduce confusion and errors. Previously, the app had sent the customer to their weather station information screen with a blank image, leaving some customers confused as to whether their station was working because it takes the camera five minutes to take the first photo (see 5).

Search Introduction and Tutorial: Upon exiting the setup, the user will see their new weather station located on a map, to give them context of their weather station within the app and amongst all others in the BloomSky network, anchoring the different screens within the app to each other and communicating to the user that they are part of a community network (see 6). After they tap Okay, they will be introduced to the search screen and given next steps via highlights. The prompt to explore the app gives the user a chance to experience the rest of the app while their camera loads and takes its first photo (see 7–8).

‍

‍

Search and Explore

Dynamic Search Flow: We aimed to design a search and explore tab whose flow was dynamic, smooth, and easy to understand. Between the different ways to find, evaluate, and decide upon locations, we had to create a solution that seamlessly integrates the map and location information previews. The relationship between the two were varied, with use cases where one would take precedence over the other, such as when a user is more familar with a location's map context, but they still need the location information to confirm the match. When a user first enters the search tab, they will be presented with three options (i.e. search, map, and discover). From there, they can choose depending on their specific needs (see screen 1).

Discover Content: The discover preview can be tapped on or slid up to show the entire list. Discover is curated location content for when e.g. persona John wants to pass time during this break at work (see 1–2). The idea was in its beginning stages, as implementation would happen in the future, rather than for the MVP app. The mockup was created to give our marketing team a better idea of where the content would be accessed and began our exploration into the global weather product direction. We helped the marketing team brainstorm ideas for this area including a weather blog, weather articles, featured locations, current weather events around the world, and current BloomSky events.

Map Exploration: The user can pan on the map without searching, in the case that e.g. the user wants to broadly see the weather conditions for a nearby custom area. Doing so will cause the discover preview to slide down to minimize itself and maximize the map viewing area. On the map, each location pin designates a weather station or city center. These pins contains a temperature reading and, in the future, a small snapshot of the area there. Tapping on a location pin will slide up a location preview to help the user confirm their choice or continue exploring (see 3–4). Tapping on the list icon in the top-right hand corner will pull up a list of the locations currently shown on the map, in the case that the user would like to compare multiple locations in the area quickly (see 7–8). The user can also pull up from a location preview to see the list.

Search Suggestions: Tapping on the search bar will bring up a keyboard as well as predefined locations of Current Location and the user's recent searches. As the user types, they will get recommendations based on their previous searches, frequent searches, high-volume searches, distance from their current location, and text matching ratio (see 5–6). The search suggestions will include station name, city—and in the future, business name, neighborhood, street, zip code, county, state, country, and continent. Providing predefined locations and search suggestions would aid the user in finding their location as quickly, easily, accurately, and with as few errors as possible to address the previous problem of frequently returning a search with no results.

Map and List Results: After, the user will be presented with a map preview as well as a list of results ordered by relevance to their search, so the user can 1. quickly compare different locations based on their search criteria, 2. see alternative locations and avoid searching dead ends if no exact match was found in the database, and 3. relate map location to textual information and increase the accuracy & speed of finding a location. Scrolling the list will highlight the corresponding marker on the map, to indicate its map location to the user (see 7–8). In addition to viewing the map and list, the user can tap on the full-screen icon in the top-right hand corner to maximize the map, allowing them to fine-tune the area of search based on the map (see 4). 

Search Result Logic and Labeling Strategy: Search results will be ordered by 1. city, if a city name was searched, 2. the user's locations (i.e. followed locations and purchased stations), if relevant to the search, and 3. locations in the order of distance from search location center and popularity. Location previews show relevant information to help the user determine whether or not they want to view more about the location. Information had been focused and rearranged from the previous design solution, as content and labels did not provide relevant or clear information, adding to visual noise and user confusion (e.g. distance from user's location was irrelevant). Each type of location has a varied, yet uniform information arrangement to provide the most relevant information (see 7–8). All weather stations will have their station name, most recent photo, followings, and short description, if provided. Business weather stations will also have their full addresses. Personal weather stations will show its neighborhood and city only. Cities will show their city name and a preview collage of four photos. Third-party data cities will have an icon instead of a photo collage, which third-party data cannot provide. A user's purchased stations and followed locations will show an icon to communicate its special status, as well as its nickname, if provided. 

‍

‍

Settings

Settings Functionality: Settings will be the place to review and take action on BloomSky announcements such as promotions; view and change account, weather station, and app settings; and send feedback, rate the app, and share the app (see screen 1). Settings also acts as a knowledge base with help articles, terms & privacy, and weather science explanations, such as how the BloomSky weather station works, that are also accessible through the weather information screens (see 6–8).

Account: On the account settings, users can add account information (if they signed up with Facebook), or connect to their Facebook account for quicker logins (if they used a BloomSky sign up form) (see 2).

Purchased Weather Stations: Users can also view their purchased weather stations, edit its settings, and add additional stations through the settings tab, which will be for existing users who are used to this functionality location from the previous app design (see 3).

Measurement Units: Users can set their units of measurement for the entire app. They can scroll to select through the many options without changing the screen they are on (see 4).

Notifications: For notifications, users can select which notifications they would like to receive and for which locations. They can also turn on and off weekly email reports for their purchased stations, which would provide the user with detailed summary weather information (see 5).

‍

‍

Sharing and Notifications

Image and Video Sharing: We designed the shared images and videos with time and place context and labels, so viewers unfamiliar with BloomSky can understand what they are looking at. Below the video is BloomSky recorded weather information that will change according to the video's time of day (see screen 1).

Notifications: We aimed to make notifications useful for out-of-app situations. We drafted the copy for BloomSky's potential notifications including rain, pollen, and extreme weather warnings, the next-day forecast, timelapse-ready alert, purchased weather station battery low alert, purchased weather station offline alert, and first-time photo & timelapse notifications (see 2). 

‍

‍

Visual Identity

With no existing visual identity, we created a framework, from which to later expand.

Because at the time, BloomSky had no unified visual identity and the app needed to be released before a full visual identity project could be pursued, we set out to start the style guide to ensure the new app would be unified with any other new BloomSky assets, as well as work with existing products and designs. We aimed to set up a foundation that will maximize efficiency and alignment within this current project and for future projects as well as tackle the problem of inconsistency amongst the different BloomSky products. To do so, we first started by creating keywords based on branding conversations with the CEO and on our app vision to begin our brainstorming. We solified our ideas with a mood board, and then created a look and feel that defined colors and typography, which were then used to communicate our visual ideas with the BloomSky team before diving into the visual design.

‍

Keyword Card Sort

Based off our app product vision, weather station product, and BloomSky company name, we individually created visual keywords and concepts. We then collected the ideas in one space, sorted them based on relevance, and then created overarching keywords to move forward with.

Resulting Keywords (sorted by importance): Refreshing & Bright, Peaceful & Safe, Intellectual, Exciting

‍

Mood Board

The resulting mood board based off the visual keyboards resulted in bright, yet calm natural colors, repetitive simple and round shapes, a minimal and focused image style, human and modern typography, and an equal emphasis in negative and positive space.

‍

Style Guide

Typography: The look and feel was composed of the typeface Montserrat for text and Gotham, which have both proportional and tabular figures necessary for the inline and table weather data display, for numbers.

Iconography: The FontAwesome and Weather Icons icon libraries were used for efficiency due to our fast-paced timeline. Weather Icons would be used for the wide variety of weather icons needed to communicate the different types of weather conditions e.g. in forecasts. FontAwesome would be used for any other icons needed.

Color Palette: BloomSky's color palette contain eight colors. We aimed for a balance between saturated and neutral colors, cool and warm colors, as well as light and dark colors that could be used to communicate focused and deemphasized elements, hot and cold tempratures, and elements on light and dark backgrounds.

‍

‍

Visual Design

With style guide in hand, we mocked the primary (and most data-intensive) screen.

We used the weather information screen wireframes alongside the mood board and style guide to mock different visual design drafts and variations. Mocking this screen would kill many birds with one stone, allowing us to test visual, informational, and data styling and hierarchy on the core screen of the app as well as one of its most complicated. The visual design mock combined with the wireframe clickable prototype was used by the user research team to test with new and existing users to validate our assumptions and unearth any pain points before continuing to flush out the remainder of the app. The research team reported that the product value focus, hierarchy and flow, screen structures, information & terminology, and visual elements such as icons were widely understood by the testees and a significant improvement over the previous app. General reception had improved as well.

‍

Visual Design Elements

Broad and General: We ensured the visual design would avoid and improve upon the previous visual design problems of typography and iconography being unreadable, colors being distracting, and iconography being difficult to understand. We optimized the final visual design for quick scrolling and scanning for the variety and amount of data presented. Some elements were changed in position from the wireframes to optimize its effectiveness with added the styling.

Menu Icon: Based on the user feedback, the star icon with the number within was difficult to understand (e.g. was it number of followers?). We changed it to the widely understood menu icon that communicates a place where the user would find navigational or additional screens related to this screen. It is unimportant at this moment and place within the app for the user to know how many locations they have followed (which was the intention of the number within the star).

Location: The location information from the bottom of the screen in the wireframes was moved to another screen to consolidate all location information and functionality such as following, renaming, and editing into one area. That would also simplify the weather information screen to only weather data, making it simpler and easier to read and understand.

Time: From user feedback, "5 min ago" in the top header bar was not a reliable time reference because the OS time bar had been removed. We changed the data time to hour and minutes intead.

Sharing: The share functionality was placed directly on the image for user convenience.

Information Contexts: From user feedback, we learned that "↓ 6° fr mon" was difficult to understand, and the sunrise and sunset icons being the same makes the information difficult to differentiate. To address the feedback, we added more context to the weather temperature time reference, as well as changed the icons. In addition, we added unit references to UV and air pressure data so users can better understand what those numbers mean.

Black Header for Spatial Recognition: The black background for the top header adds to the spatial concept of layers being related to time. The "blank" background is darker, visually-receding, empty space that allows for the timelapse screen to appear when the user scrolls up, which is "in back" of the other cards and also backwards in time.

Colors for Focus: From user feedback, colors did not help focus information (e.g. why do low temperatures in weekly forecast have more focus?). To address the feedback, we used the careful placement of blue and red to not only aid in temperature recognition, but to also define highs & lows and bring focus to information (e.g. using blue to highlight the current screen on the tab navigation at the bottom). In addition, users noticed the forecast section is not strongly separated from other data, making it hard to find during a quick scan, so we used a different background color for the forecast section.

Card Motif: Each data group is placed on a separate card to create clear visual organization for quickly scrolling and scanning dense information. Present weather data is grouped together on the white card and further separated by using rectanglar background sections. Forecasted future weather data is grouped together on the black card and further separated as well. A slight gradient on the forecasted information shows the user that they can scroll horizontally to view more data.

‍

‍

‍

Adaptation

While the app design was underway, we received an emergency company announcement.

The CEO announced that BloomSky was in a dire financial situation with only three months of funding remaining, while future funding would only be provided by investors if our app met certain metrics within the three months (from less than 1,000 daily active users to 10,000 DAU). Because our in-progress app would take two to three months to develop and launch from the date of announcement, that would not leave us with enough time to reach the metrics using the new app design or allow us to effectively align with the marketing team whose job would be to reach and attract new audiences during the three months. Our goal of improving the app and beginning the improvement of reception had changed to increasing our app use rate by over ten times.

So, with that situation at hand, we halted flushing out the visual design & app development and replanned for the emergency situation. We needed to improve the current app with its existing problems as quickly as possible to align with the marketing team's efforts. To do so, we worked with the product manager and engineering team to create a transition plan from the current app to the MVP design we had been working on by prioritizing app changes by level of effort, time, and impact. We then planned two rounds of app updates before the three month deadline.

Month One: We would release large, broad, and wide-reaching changes that would take the least time and effort, and create the largest impact. The release date would align with the marketing team completing their marketing strategy tests for messaging, audiences, platforms, and timing.

Month Two: We would create release fewer, less impactful, and more specific features that were more time-consuming to execute, but central to transitioning to our MVP app and critical to increasing user privacy & security in existing functionality including usernames, location nicknames, rearranging functionality, and changing the search flow. During this time, the marketing team would be continuing and refining their outreach campaign.

‍

‍

App Update Round 1

For the first month of the emergency period, we worked on quick changes with big impact.

To make the largest impact within this short amount of time for design and implementation, we decided to make sweeping changes to the information architecture, features, visual design, and technical performance that had previously created major pain points for our users. We optimized our workflow by working on a visual update for the primary screens and repeated elements (tackling hierarchy, readability, colors, and iconography), updating app store marketing images in preparation for the first round of app updates, and documenting and prioritizing bugs found from the test builds from the engineering team; while the engineering team optimized technical performance, reordered the primary flows of the app, removed unnecessary functionality that did not provide value & support our app vision, applied updated colors and typography to secondary screens for coherence, and smashed bugs.

‍

Transition Changes

Technical Optimization: The engineering team was to optimize the app to load and show the Favorites screen from app start under five seconds. The current app loading time was at least fifteen seconds and could take over one minute, frustrating users due to the slowness or the perception that the app had frozen. We also prioritized removing critical bugs that would freeze and crash the app.

Favorites Tab Location and Screen Layout: The favorites screen was to be moved from within the Settings tab out to replace the Trendings tab, removing a feature that did not add values for user and making the primary value of the app more prominent (see screens 1–2). In lieu of this change, we also added a blank state for the Favorites screen so new users would be directed with an actionable next step (see 1), separated purchased stations from favorited stations with headers for clarity and efficiency, and removed saved moments from the Settings screen, another feature that did not add value.

Search Results: We defaulted the search results to the map view (see 4) instead of the list view (see 5) because location context is one of the primary decision factors for users. Third-party data city locations, represented by an weather condition icon, were added to account for the wide product distribution problem (see 4). Quick favorite buttons in the search result list were removed to improve focus during scanning; it was also unnecessary to show the button outside the weather information screen due to an estimated user need to favorite a location and the quantities of favorited locations per user (see 5). Showing results in separate tabs by location and by weather station name in the search results list view was condensed into showing results with no separation ordered by relevance and text-matching to search input, due to users not knowing the difference between the two categories, to increase efficiency in finding the intended location by presenting less decisions to users, to increase consistency between the two states of search results (map and list), and to set up the app to allow search by more variables in the future (see 5).

Visual Redesign: The visual design of the primary screens were updated to have consistent color, typography, and styling. The tab navigation & headers were separated through coloring and grouped through placement; and headers were added to all primary screens. We ensured appropriate visual hierarchy, grouping, spacing, and layout. Type and icons were updated to be consistent, legible, and understandable. Overall, we updated the visual design to not get in the way of and aid in presenting the app's value (see 1–6). Due to time constraints, the secondary screens (e.g. screens within the settings tab) were updated with the new colors and typefaces to improve consistency without taking the time necessary to redesign each screen.

Weather Information Screen Optimization: We moved the followers information that was currently on the weather information screen and moved it to a separate screen in order to focus what was presented for easier scanning and understanding.

Animation Optimization: Many of the animations did not help and even confused users. Instead of bringing context to the locations and connections of screens, many animations were superfluous decoration and negated the actual relationships between screens. We removed some of the animations (e.g. horizontal sliding animations when changing between the three primary screens in the tab navigation, which indicate users can also swipe left and right to move between the primary screens when they could not; sliding down animation for the header of the weather information screen, which brings unnecessary attention to the header and indicates some other spatial separation when there was none; zoom in animation on the search map screen, which slowed loading times for the map and provided no other value; universal animation that would hide the header during scroll making it difficult to determine app location and navigate from screen to screen, while the animation to optimize screen real-estate was not necessary for all screens). We added some animations as well (e.g. tapping on a location from search would prompt the weather information screen to slide in from the right, because sliding from the bottom already indicates scrolling the results list from the search screen, and uses the existing affordance of reading text from left to right, where forward is right and backwards is left).

‍

‍

‍

App Update Round 2

After the first round of updates, we focused on creating and revising core functionality.

After completing the most impactful changes for the time we were given, we then worked on more time-consuming changes. With a strategy of continuously spending time on the most impactful app changes, the next focus was placed on the aspects central to increasing user privacy & security in existing features and transitioning the current app to the MVP app. This included creating username functionality, creating station nicknaming functionality, creating rearranging functionality, and rearranging the search flow. At this point in time, the engineering team was out of the country for the next two months, so, as they continued to smash surfacing bugs, we worked on documenting & prioritizing bugs, determining the flow of a completely new feature not introduced in the MVP app (i.e. usernames), creating & updating visual designs, and diagramming the logic, flows, transitions, and states of each feature into interactive documents to communicate accurately with the engineering team, aiming to prevent long wait-times of unnecessary communication due to an eight hour timezone difference and ensure screen states were comprehensive to avoid the previous problem of user confusion & frustration due to a lack of user action and input feedback.

‍

Usernames Feature

Feature Details: Usernames were created to protect the privacy of users because at that time, emails were used for display names to the public. Usernames were created to by unique per user.

Feature Flows: The usernames feature were account for three user flows: 1. New users opening the app after the update, 2. Existing users opening the app after the update, 3. Users changing their nickname after the first open from settings. New and existing users have the same flow for opening the app after the update, with one exception for existing users. They are presented with a modal notification letting them know why they will be required to create usernames and what they will see next, since existing users will have expectations of what they will see upon opening the app and their expectations will not be confirmed. Afterwards, the user will see a screen with a profile image populated if they had previously uploaded one or a blank profile image placeholder that states that this field is optional, alongside an autopopulated username based on their email address (without @domain.com) (see diagram 1). If they decide to change either fields, they will be directed into the photo and username flows as appropriate (see 2–3).

Success Metric Results

During the third month of the emergency period, our metrics climbed.

During this time, we continued smashing bugs, monitored user activity, assessed the progress towards meeting the emergency success metrics of 10,000 daily active users, planned the remainder of the transition to our MVP app, and began working on the next changes to close the gap.

With a solidified app product vision and with implementation towards the MVP app started, BloomSky's mobile app was on the road towards a brighter future, and even if challenges arise in its quickly-changing startup landscape, like it did, the framework was there to support new changes.

‍

At the beginning of the third month, our original goal of higher reviews & ratings and lower user drop-off rates from download to second usage were met.

App Ratings: There was an average 30% increase in app rating quality across Android and iOS devices over the last two months, even while the updated app had major bugs that had not been solved. App ratings increased from a low average of 2.5 stars to 4.3 stars.

App Reviews: Average reviews from before the update said the app presented a promising idea, but it had lots of room for improvement, was hard to use, and at times, nonfunctional with its bugs and crashes. Average reviews after the two updates said the app was an interesting and fun way to check the weather instead of just looking at numbers, but it did not provide BloomSky-captured weather in many areas, further confirming our product distribution problem that we started tackling by providing third-party data weather information and call-to-actions to purchase weather stations for the area. The reviews suggested that our app updates allowed the app to better communicate and provide its value, which was our primary qualitative goal.

Drop-Off Rates: User drop-off decreased by an average of 26% between the first and third sessions. Daily app uninstalls dropped from an average of 1,250 to 250, decreasing by 80%. 

‍

Our new goal of reaching 10,000 daily active users within three months was on its way and our user engagement increased along with quantity of returning users.

Daily Active Users: In contrast to gaining around 600 daily active users over the past twenty-four months of BloomSky's existance, we gained around an additional 2,400 daily active users in two months, increasing acquisition speed by 48 times. With continued marketing efforts, bug smashing, and the workings of time, we hoped to close the gap at a higher velocity during the last month. The company was able to secure its funding for the next year.

Increased Engagement: The average time spent in the app over the course of a week raised to an average of twenty minutes, by 500% from five to twenty-five minutes; and screens viewed per session tripled, increasing from an average of two to six. Both metrics had an upward pattern into the future.

‍

‍

Lessons Learned

In a fast-paced environment, transparent, thorough, and accurate communication is key.

Over the course of the project, the lessons I learned centered around communication and how important it is to every aspect of a project. Successful design includes successful communication throughout.

Understanding the Ask: One example is the lesson on the importance of understanding the goals, stakeholders, and financial aspects of a business at a higher level of detail. Onwards, it is necessary that I understand the details of an ask, including understanding whether the proposed goals are the best solutions for the certain problem at hand. For example, in this project, it would have been helpful to ask how improving the app and starting the improvement of user reception would gain the company the funding it needed. What metrics and values were the investor using to approve the funding? What did they think of the product, where it had been, where it is, and where it was going? What was the financial health of BloomSky at the moment? What were our plans for the future? If I had known the answers to those and similar questions, I would have planned and executed the design of the app with a focus on immediate survival and long-term survivial & scalability. Doing so would have given us more time to acquire the daily active users we needed and it would have been less straining on the entire BloomSky team.

Providing Context: Similar to how it is important for the designer to understand the why's to effectively do their job, it is also important for any other team or person to understand the why's for their own effectiveness & motivation and for accuracy in communication. Communicating the purpose of a meeting, a process, a feature, or any other aspect of a project; and how each connect back to our shared goals would have increased the effectiveness of any related communications and decreased the time spent per communication. For example, during a wireframe review meeting, not all parties involved understood the purpose of the wireframes or meeting, which led to frustration and apathy from the parties. Another example was when an engineer, while overseas during round two of the app updates, did not understand why a feature was being implemented and delayed the implementation. Moving forward, I will invest the time necessary to add context to each communication to ensure all parties are informed and invested.

Listening Skills: Different people will understand a certain matter differently. It is necessary to understand the priorities of the person with whom I am communicating in order to communicate effectively. I made this mistake during the times I was trying to convince the CEO of certain design decisions, which was mostly ineffective and time-consuming. Rather, it would have been more effective to listen to his feedback, concerns, and/or confusion, understand the why's, understand his language, and then make a decision based off of that information. That would have saved time & energy and created better informed decisions with unwavering support. Moving forward, I will practice these important listening skills—a large part of communication skills.

Time Management: During the first round of app updates, our plan did not leave sufficient time for fixing bugs and communicating with the engineering team to ensure the app plan was translated accurately to development. This led to releasing the first app update with many bugs that had yet to be addressed. Moving forward, I will plan in buffers for when things will inevitably go wrong.