Internetbrain copy.png

Lighten

Startup Founding, Project Management, UX Design & Research, Information Architecture, Open Source Development

lighten pitch deck_Page_01.png

The Lighten project is an effort to solve a longstanding, endemic and complex set of problems in the government and non-profit social services space. Right now, most social service organizations lack coherent content management systems. In other words, there is no consistent practice for organizations to store, update, and otherwise manage their own information about social services. This seemingly unimportant lack of infrastructure has wide-ranging consequences that profoundly affect community members seeking help, the social service providers who work with them, sponsors and taxpayers who fund these services, and the larger structures of government that they operate within.

Lighten’s answer to this problem is a flexible, transparent, yet standardized web-based system that is low cost, easily maintained and scalable. This platform allows social service organizations to create an interconnected directory system where information can be managed, shared, and tracked through a set of living, common standards. Founded on civic tech and open source values, Lighten seeks to improve government (and public perception of it) by leveraging modern technology to create an easy-to-use, more useful and intuitive software solution that works for everyone.

 

Methods and Software:

  • Competitive analysis and field research
  • Process documentation to demonstrate decision-making and document progress/project history
  • Collaborative brainstorming by whiteboard and pencil-and-paper
  • Omnigraffle, Visio, Photoshop for wireframing and prototyping
  • Live user testing of the prototype
 

Deliverables:

  • Interactive web prototype
  • Wireframes and front-end mockups
  • Personas and user flows
  • Pitch decks to present ideas to stakeholders/get funding
  • Backend database hosted on Heroku

Contents


The Problem and it's Costs

Current landscape.

The Lighten landscape.

More context and a detailed breakdown of the landscape can be found here.

Return to Contents


The Solution and it's Impact

mycelium.png

Our solution is a web-based platform where information can be automatically shared, updated, and tracked through a set of living common standards.  What sets us apart is that through these standards, we can guarantee the accuracy of data on our platform, something no other entity in the space can claim. In addition, our solution is user-friendly, customizable, requires minimal maintenance, and is very low cost to the user. 

Return to Contents


Our Guiding Philosophies

bees1.png

The Lighten ethos is driven by open source and civic tech community values, and a strong belief in forward-thinking innovation through human-centered design. We believe that government should be built for the people by the people, and we strive to set an example on how to implement these values on an impactful scale.

Return to Contents


User Experience Design

Research

The nature and scale of the problem required a great deal of research not only to effectively serve our clients but also to set realistic and achievable milestones.  Although the process is explained in a linear fashion, actual work on the project was much more fluid and agile. We were always incorporating new info and findings into our builds. Over the course of the project, we conducted interviews with government and nonprofit employees, help seekers in the community, consultants working in civic tech, and volunteers working in parallel efforts. We also researched similar projects in other cities, the existing state of infrastructure, operations procedures in multiple city and county government agencies and nonprofits.

Key Takeaways

Through this research we discovered major hurdles to adoption as well as key info to shape our design specifications:

  • Whatever we built had to be especially intuitive and user-friendly. For a number of reasons people seeking social services often have low levels of computer literacy and even basic literacy. Service providers generally have higher literacy levels than their clientele, but as they often come from the communities they are serving it might not be by much. 
  • No matter how seasoned workers in this area may be, no one knows the full extent of the problem. Therefore our data model had to be flexible enough to incorporate changes without breaking as we discovered new data points. Our system had to be able to easily adapt to new information as we discovered it and moved into additional social service areas. 
  • Ease of scaleability was important as a selling point and a strategy. Government agencies often have complicated chains of command and any project over a certain cost threshold has to go through a lengthy approval process. By keeping our builds lightweight we were able to operate below these limits, a major plus for our clients. Focusing on simplicity at scale kept the team on track and prepared for an easy rapid deployment if larger agencies were to adopt our platform.
  • There are multiple factors that disincentivize collaboration between service providers. Some organizations, such as domestic violence shelters, gang rehabilitation programs or services for immigrant and refugee communities cannot make their information public because it puts the lives of their clients and employees at risk. They would need separate privacy controls or a separate system entirely. 
  • It’s common for organizations to compete with each other for funding, which is difficult to obtain and becomes more so over time. This causes organizations to cling to the funding streams they already receive, and for various reasons even fudge their justification for receiving certain funds they don’t need, which artificially limits their availability. (This is part of a larger bureaucratic issue too involved to further discuss here.)
  • Finally, the biggest hurdle is arguably government workplace culture, which tends to be slow-moving, disengaged, resistant to change, tech averse, and opaquely bureaucratic even to it’s own employees. As in for-profit companies, internal politics may be what drives day-to-day operations. This is especially prevalent in the non-profit sector. For government, this results in a maze of silos within silos; difficult to see in or out of. 
 

Storyboards

Personas

Through my research I identified four main user groups. Based on the size and nature of the organization, some of these roles may be combined or absent entirely.

The Unhappy Path. This storyboard illustrates the way it is now for help-seekers and service providers.

The Happy Path. How Lighten will improve this experience.

 

Identifying Software User Roles

 
The most effective starting point for us is the relationship between a Service Provider and the Sys Admin or IT person who manages the database. In smaller organizations these two roles can be the same person, which can often mean there is no CMS in place and the Service Provider uses their own personal methods, often a handwritten notebook.

The most effective starting point for us is the relationship between a Service Provider and the Sys Admin or IT person who manages the database. In smaller organizations these two roles can be the same person, which can often mean there is no CMS in place and the Service Provider uses their own personal methods, often a handwritten notebook.

 

Collaboratively working out the three main flows necessary for MVP.

Maps of more detailed administrative user roles to design for after MVP.

 

Improving Help Seeker and Service Provider Interactions

Although they are not our target user in this phase, if our product is not useful to help seekers then service providers will never adopt it. Additionally, a key deliverable for our clients is the ability to produce coherent printed directory entries. Help seekers don't necessarily have access to the internet or a phone, so printed packets and guidebooks are often part of their first encounter with the social services system. Thus how our information is laid out in print format is actually really important.  

Help seeker mental model and interaction mapping.

Help seeker mental model and interaction mapping.

Defining MVP for our prototype, and identifying ROI factors for service providers.

Defining MVP for our prototype, and identifying ROI factors for service providers.

A page from a resource guide as is. This was one of the more organized examples.

A page from a resource guide as is. This was one of the more organized examples.

The same organization with our taxonomy applied. Information is organized intuitively into clusters, make the page easier and faster to read. 

The same organization with our taxonomy applied. Information is organized intuitively into clusters, make the page easier and faster to read. 

Interface layout in our prototype organized in a similar way to a printed page. Our clients wanted to be able to print out single pages, and we wanted a unified look that was familiar and comfortable to our tech-averse clients.

Interface layout in our prototype organized in a similar way to a printed page. Our clients wanted to be able to print out single pages, and we wanted a unified look that was familiar and comfortable to our tech-averse clients.

As previously mentioned help seekers may have low literacy levels, so being presented with a guide the size of a small phonebook full of walls of text can be an overwhelming experience. Following our taxonomy, information is broken into small useful clusters with the addition of icons and graphics. Instead of needing to sift through the text this layout is designed to be skimmed, an additional significant plus for service providers who work with these texts all day long. 

Return to Contents


Information Architecture (Data Modeling)

The Lighten Data Specification

The Lighten data spec is the crux of our platform. In the graphic above, the same organization is listed across three different, publicly available resource guides, but the information provided varies considerably, even the name of the organization! By adhering to a universal spec (ours) we can guarantee that data will be accurate.

The Lighten data spec is the crux of our platform. In the graphic above, the same organization is listed across three different, publicly available resource guides, but the information provided varies considerably, even the name of the organization! By adhering to a universal spec (ours) we can guarantee that data will be accurate.

About the Data Spec

Lighten’s data specification, based on the Health and Human Services Data Specification (HHSDS) is designed to be a flexible, scalable data structure that can be adapted to fit a number of applications within the context of organizing and exchanging social service information. It is designed to be a living, evolving system that will change over time to adapt to changing technology and human needs. For Lighten’s specific use case, the model will be discussed in terms of being used to structure records in a database shared across multiple organizations.

Rather than being built as a strict top-down hierarchy, the conceptual model is organized based on the idea of clustering together relevant information under umbrella categories, with smaller, flatter hierarchies to organize information under sub-categories. In this format, a record can be easily sorted and reorganized by its categories to suit different use cases, such as a printed guide book organized by services, a web app that sorts and displays organizations by when they are open, or an administrative index of all the organizations in a specific geographic area, all without affecting the fundamental structure of a shared record. In this way, the context determines the hierarchy.

Return to Contents


Leadership & Management

In addition to my UX work this project gave me opportunity to serve in a leadership capacity, both as a founder and project manager. My responsibilities can be summarized in the following areas:

Leadership

  • Set the tone for and be an example of positive company culture
  • Acquired agency partners, pitched to investors, and worked with a legal team to incorporate
  • Acted as a key contact for stakeholders, agency partners, sister initiatives and volunteers
  • Developed processes and best practices for the team of an emerging company in an untapped market
 

Project Management

  • Managed project timelines, client expectations, milestones, and deliverables
  • Wrote job descriptions and interviewed applicants
  • Coordinated, tracked, and documented assignments for product and engineering teams
  • Kept teammates motivated, on task, and on time to make sure we hit our deadlines
  • Attended seemingly endless meetings

Evangelizing

  • Responsible for the vision and getting others excited about that vision 
  • Networked at every possible opportunity 
  • Worked together with and alongside similar volunteer efforts for mutual benefit
 

Documentation

  • Created project plans and requirements, documentation, and scope statements for different project phases
  • Tracked changes to inform future design and development choices
  • Wrote public facing promotional copy

In addition to these responsibilities I also still served as the team’s UX lead. Although I had two other designers working with me, I was still primarily responsible for defining our UX approach and keeping them moving in the right direction. 

 

Leadership in Action

 
 
 

Various methods I used to keep track of different project threads and their progress.

Excerpt from a scope statement I wrote for one of our government organization partners.


Prototype & User Testing

We were able to live test our prototype with one of our clients. The major overarching theme was we are on the right track as far as reorganizing the information, but we still need to go farther. The main categories need refining, and it’s unclear whether said client wants to keep any of the secondary categories. I think this is something we need to do research on. It might be of limited usefulness for said client, but we also need to consider the implications for the Lighten Project as a whole. 

I’d been thinking a lot about tagging and whether that would be a useful UI feature. These should be predefined with autocomplete, but also have the option to add a custom tag since we are still proving the spec. There should also be a way of tagging custom tags so that they are organization-specific. This way, they won’t disrupt the taxonomy and we can keep track of similarities and patterns when multiple organizations enter custom tags, thus informing us of when we need to update the spec.

A major potential problem is getting outside organizations to update their own data. Granted, the old update form we had was 19 pages long, but even if we shorten the form there still needs to be some way of addressing this debt. The dev team is planning to work on a reminder auto-send email feature, but I think we’re going to need to do more than that. I think at least a small way to address this would be providing visual rewards when a user completes a form field. It should be immediately obvious without having to read any text what needs to be updated and what is already complete. 

Our user was confused about the sidebar navigation, there was a lot of thinking aloud on various solutions. The design team will need to work together to come up with something more user-friendly. 

Because the UI is based largely on the layout of the printed guide (and behind the guide in development), the UI is missing a lot of info that is already laid out in the print guide mocks. A more finished UI would be the next step. 

 
Click here to view the prototype in action.

Click here to view the prototype in action.

 

Next Steps

Second Iteration Mockups

Search results mockup revised based on our user feedback.

Directory page view.

Administrator multiple profile management screen.

The scope of Lighten is too large and complex to meaningfully tackle without dedicated funding to pay a small full-time team. However, when I was pitching to potential partner organizations I found it difficult to strike a chord with them as it was very challenging to fully communicate the impact of such a project and the scale of the problem. To aid in clearer communication by serving as a reference (as well as increase our credibility and community presence) we would need to set aside work on the prototype and instead build a standard public informational business website. Instead of continuing with the prototype, we’d need to transform it into a full-scale beta site for the public to experience. While the rest of the team works on this I could resume pitching and creating interest in our platform. 

Although it was a valuable experience, I wouldn’t want to take on leadership alone again. I want to prioritize seeking cofounders to take care of the business aspects of the product so I could again focus on the design work. Clients had responded favorably to the idea of a company blog and message board to stay updated on our progress and evangelize to other agencies in turn, so that would be another priority.

Finally, we’d need a sustainable business plan to be able to acquire funding to accelerate development. This is not my area of expertise so it’s something I would want a trusted cofounder to work on. Applying to accelerators is another option. We’ll see what the future holds.

Excerpts from a pitch deck illustrating project goals.

Excerpts from a pitch deck illustrating project goals.

lighten pitch deck_Page_32.png