Overview
Every minute of everyday there are millions of posts made about what people are experiencing. These posts create a live eyewitness of disaster and incidents that are happening everywhere, in real-time.
Incident Stream is a live and shipped mobile app that leverages this real-time data, and delivers a single cohesive feed. The goal of this app is to help increase response time for disasters and incidents across the country. It is a live feed of local disaster and weather damage incidents. The app continuously combs through thousands of posts, 24/7, searching for fire, smoke and water damage response opportunities.
Incident Stream is a live and shipped mobile app that leverages this real-time data, and delivers a single cohesive feed. The goal of this app is to help increase response time for disasters and incidents across the country. It is a live feed of local disaster and weather damage incidents. The app continuously combs through thousands of posts, 24/7, searching for fire, smoke and water damage response opportunities.
The Problem / Design Objective
Disaster events are sporadic in nature, historically it was hard to efficiently predict when and where occurrences we’re going you take place. Leveraging societal data, social media posting, and citizen reporting — aggregation of real-time data being scrapped across internet to consolidate into one clean feed.
Thus, the design objective was Full-Stack UX design for a mobile app that showcases a real-time feed of local disasters. Due to the need for building this design from abstract concept, through user research, and low-med-hi-fi design, it is one of the true blue Full-Stack UX Projects I've had the honor to lead/craft.
The app technology combs through live-post data and present the user with a feed of disasters and incidents in the user's local city. The app was to be designed to have multiple cities, various categories of events, contextual cards, and the ability for the user to reach the native source of information. Incident Stream captures each incident, categorizes it and then delivers it to a user's device based on a city / metro area. Users can sort by different areas, link to the source information, save an incident or forward it to a peer.
The design vision for this app was to be clean/simple, easy for a non-technical audience to use, and have various levels of data presentation (e.g. the user should be able to tap on the feed to gather further information about a specific event).
Thus, the design objective was Full-Stack UX design for a mobile app that showcases a real-time feed of local disasters. Due to the need for building this design from abstract concept, through user research, and low-med-hi-fi design, it is one of the true blue Full-Stack UX Projects I've had the honor to lead/craft.
The app technology combs through live-post data and present the user with a feed of disasters and incidents in the user's local city. The app was to be designed to have multiple cities, various categories of events, contextual cards, and the ability for the user to reach the native source of information. Incident Stream captures each incident, categorizes it and then delivers it to a user's device based on a city / metro area. Users can sort by different areas, link to the source information, save an incident or forward it to a peer.
The design vision for this app was to be clean/simple, easy for a non-technical audience to use, and have various levels of data presentation (e.g. the user should be able to tap on the feed to gather further information about a specific event).
My Role / Key Responsibilities
The nature of working with funded startups, when in the founding stages means that a designer cannot be one-dimensional. This application allowed me to flex my Full-Stack UX Design skills in the truest form, as the project was taken from abstract concept all the way through to demoing the designs for developer implementation.
My role for this project included but was not limited to the following:
- Primary Designer - Full-stack UX Design (I was passed this project from a previous designer)
- User Research, Industry Research (disaster relief, construction/renovation), Business Research
- Feature Specification Strategy and Documentation
- Information Architecture, User Flow mapping
- Wireframes: Low Fidelity (invision freehand), Medium Fidelity (sketch and invision)
- App visual design (various constraints administered by the founder)
- Shippable Design Protoyping and Demo to Developers
User/Business Objectives
This app target users are local disaster relief parties and construction companies. It showcases a real-time feed of local disasters to the users so the users are presented with a feed of incidents in their local city.
Users care about the speed in which they receive the information of disaster incidents as they typically are life/death related and translate to large insurance and construction projects.
Key Challenges:
Users care about the speed in which they receive the information of disaster incidents as they typically are life/death related and translate to large insurance and construction projects.
Key Challenges:
- Organizing data to become categorical, and designing for diverse events (Hail, Fire, Flash Floods, Hurricanes, etc.)
- Creating enough value for the end user to pay for aggregated/consolidated data that would otherwise be "Free"
- Scalable design for multiple cities
- Competetive advantage over others in this space through seamless UX and allowance for users to take action within the app
- Clean cohesive feed that allows the user to open the app and see what's most relevant asap
- Allowance for this app to work for the user passively, notifying user and floating the "most important" information
- Scaling design to present real-time event data in a clean, easily consumed architecture
Design Process
Incident Stream is an app by a funded startup who came into the project with the notion / abstract concept. The founders did not have a design background so we worked through the design process in the truest form. First understanding the key objectives of the application, the target users, and their goals.
As with all projects, the research and strategy phase is one of the most critical steps to successful UX and product design as it lays a foundation for everything that follows. In this application, I was given this project part way through the research/strategy phase, so there was a large emphasis on working from that stage forward with regular research and feedback sessions throughout.
As with all projects, the research and strategy phase is one of the most critical steps to successful UX and product design as it lays a foundation for everything that follows. In this application, I was given this project part way through the research/strategy phase, so there was a large emphasis on working from that stage forward with regular research and feedback sessions throughout.
User Research + Strategy
For this application, the founders fortunately had a decent understanding of the target user and their needs. The target users for Incident Stream were:
Research and Design Methods
Target Users
Research and Design Methods
- Online research, Forums, and Public Data
- User Interviews to extract pain points and needs
- Needs documentation and analysis
- User Journey Mapping (Early)
- User Flow Diagram (Post journey map)
- Whiteboarding + stakeholder validation
- Medfi-wireframes (custom blueprints made in sketch)
- Invision demos + stakeholder and user feedback sessions
- Explorations via Invision moodboarding + feedback sessions
Target Users
- Restoration Teams - Fire, Smoke And Water Damage Response Opportunities
- Media Companies - Breaking News Before It Breaks
- Insurance Companies - Commercial and Residential Property & Casualty Claims
Observations + Insights
With the Target Users being a tri-fold, an initial assumption was that there would be more diversity in the design needed, per type of user than actually ended up being the case.
User needs/Goals:
Some of the key insights that I took away from the research and strategy phase were that the design would have categorical event data across core diverse events (Hail, Fire, Flash Floods, Hurricanes, etc.), the app needs to be designed such that there's enough value for the end user to pay for aggregated/consolidated data that would otherwise be "Free." The design needed to be scalable for multiple cities, starting with the major metropolitan areas.Competetive advantage of this application over others in this space through seamless UX and allowance for users to take action within the app. There is a major need for a clean cohesive feed that allows the user to open the app and see what's most relevant asap. This app needed to work for the user passively, notifying user and floating the "most important" information. and lastly, considerations so the app design was scalable to present multiple kinds of real-time event data in a clean, easily consumed architecture.
Key User Needs Assessment
User needs/Goals:
- Restoration Teams - Restoration teams look for opportunities to be the first respondents to opportunities that exist in the space of fire, smoke, and water damage.
- Media Companies - Need for breaking news first. Media Companies goal is to be the very first party to report on accurate events.
- Insurance Companies - Insurance companies, for both commercial and residential property & casualty claims have the goal of being informed about events before their competitors, as their industry exists because of these events.
Some of the key insights that I took away from the research and strategy phase were that the design would have categorical event data across core diverse events (Hail, Fire, Flash Floods, Hurricanes, etc.), the app needs to be designed such that there's enough value for the end user to pay for aggregated/consolidated data that would otherwise be "Free." The design needed to be scalable for multiple cities, starting with the major metropolitan areas.Competetive advantage of this application over others in this space through seamless UX and allowance for users to take action within the app. There is a major need for a clean cohesive feed that allows the user to open the app and see what's most relevant asap. This app needed to work for the user passively, notifying user and floating the "most important" information. and lastly, considerations so the app design was scalable to present multiple kinds of real-time event data in a clean, easily consumed architecture.
Key User Needs Assessment
- Real-time event feed - to showcase the latest events, automatically showing local data
- Ability for user to tap into an event and go to the original source
- Passive notifications so users don't have to manually audit, and can save time
- City and metro-toggle to they can subscribe to multiple areas
Core UI Design Variants / Explorations
Based on user research, I knew that I needed to design an application that got the users to their main goal as fast as humanly possible. The landing UI of the application needed to be a feed of the latest relevant occurrences and events. Thus, rather than designing a typical application that might have something of more of a passive discovery UI, the UI needed to be designed in a linear format communicating timeliness.
How I chose to go with B: More than stakeholder input, it was important to understand the user's behavior and needs when deciding which core UI feed design would be best for the user. It was important to display just enough event information to give the user a high-level of what is going on, without the need to tap into the card unless action was to be taken. From design "B," I determined this architecture was scalable enough to add in key interactions such as a "save" affordance as well as category icon type.
How I chose to go with B: More than stakeholder input, it was important to understand the user's behavior and needs when deciding which core UI feed design would be best for the user. It was important to display just enough event information to give the user a high-level of what is going on, without the need to tap into the card unless action was to be taken. From design "B," I determined this architecture was scalable enough to add in key interactions such as a "save" affordance as well as category icon type.
Key User Actions
After thorough research, I understood that the user's primary goal was to get insight to the latest disaster events as possible. Thus, the focus of key experiences was firstly, the real-time event feed, showcasing the latest disaster events to the user. The next key action was Search, for the users who had a specific granularity of detail in mind, when leveraging the app's aggregate event data. The search function was determined a key user action based on the insight gathered from user feedback sessions, and the need for being specific in what it was they were looking for (be it type of event, date, location, etc.).
Finally, having a global key action (i.e. accessible from the global app navigation) be a "Saved Leads" tab was of great importance, because w found that users oftentimes leave the app, and need to come back to what it was they were doing. Also, when the user is in a passive discovery mode, such as the private insurance companies -- they don't always know, in the moment if an event will or will not be useful in their work. Thus, the ability to bookmark and save events is key, so they can return to a list of curated occurrences.
Key Features and Navigation
Finally, having a global key action (i.e. accessible from the global app navigation) be a "Saved Leads" tab was of great importance, because w found that users oftentimes leave the app, and need to come back to what it was they were doing. Also, when the user is in a passive discovery mode, such as the private insurance companies -- they don't always know, in the moment if an event will or will not be useful in their work. Thus, the ability to bookmark and save events is key, so they can return to a list of curated occurrences.
Key Features and Navigation
- Discover - Allows users to get to their main goal first: seeing the latest events and occurrences
- Search - Allows users to specify a type of event based on any number of tags or granularity
- Save/Saved - Allows users to save and return to events that are deemed as key and important
- User Profile/Settings - Configuration for type of account, location, and preferences for types of cities and events
Shipped, Live Product 🎉
While I'll continue to expand upon the story of designing Incident Stream as an application, I went ahead and included a couple shots of the key screens that ended up being implemented into the final product.
In reality, there is design time spent tying up the necessary corners of an application. These corners aren't included in the key flows, nor do they require the same level of user research, but there are certainly design choices and psychological elements that needed to be considered. For example, one of the necessary but not core screens were Forgot Password UI, Confirmation UI's for things such as user-password resets, and Terms and Conditions UI.
As with any project, there are constraints that I faced as a designer, such as certain branding/color elements, selected pathways for micro product copy decisions, and the marketing website. However, designing the user's experience from the very entry point of the application through to their goal of taking action on an incident has been extremely rewarding.
In reality, there is design time spent tying up the necessary corners of an application. These corners aren't included in the key flows, nor do they require the same level of user research, but there are certainly design choices and psychological elements that needed to be considered. For example, one of the necessary but not core screens were Forgot Password UI, Confirmation UI's for things such as user-password resets, and Terms and Conditions UI.
As with any project, there are constraints that I faced as a designer, such as certain branding/color elements, selected pathways for micro product copy decisions, and the marketing website. However, designing the user's experience from the very entry point of the application through to their goal of taking action on an incident has been extremely rewarding.