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
- 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
The Problem and it's Costs
The Solution and it's Impact
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.
Our Guiding Philosophies
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.
User Experience Design
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.
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.
Identifying Software User Roles
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.
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.
Information Architecture (Data Modeling)
The Lighten Data Specification
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.
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:
- 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
- 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
- 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
- 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
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.
Second Iteration Mockups
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.