Hi again! You might remember me as a prior guest author - Austin the Product Manager. I'm returning to you as Binti's Head of Design. This was a newly created role in 2022, designed (ahem) to give the user experience an equal weight in our Product/Engineering/Design triad.
I'm publishing our design philosophy, not claiming to stand as a beacon of what design should be, but rather to share transparently how we think about design. We created our philosophy document to align the team on what we care about, so when we have healthy debates and tension, we can point to the principles behind our choices and debate how our choices reflect what we claim to value and in what priority.
My hope is, as you read through this document, you'll find the principles intuitive and "in the right order" – if they are for you, maybe you should consider joining our team ;)
Binti Design Philosophy
1) Put the Child First
- Prioritize all functionality that helps achieve Outcomes in Child Welfare – each module has a few core metrics that contribute to better outcomes and focus on those.
- Take into account best practices, core practice model, and trauma-informed practices. The software should support what we as an industry know about making the best choices for children.
- Design to save caseworker time so they can spend more time focusing on children and less time on paperwork and documentation.
- Design to make the most equitable choice the default choice.
- Make it easy to do the most secure thing – Options should prioritize security of child, family, and agency data.
- Introduce friendly friction around data sharing or high exposure actions (e.g., take the time to reduce chances of accidental information sharing)
2) Build a deep understanding of the need
- Spend time building deep empathy for our users by shadowing them and interviewing them. Get a full picture by researching all perspectives: speak to youth, families of origin, foster families, relatives, adoptive families, workers, supervisors, and directors.
- Dig down to the root and why of the problem before coming up with solutions.
- Where possible, get access to data to inform decisions.
- Understand the differences in how agencies operate and organize; there are usually reasons for how people chose to operationalize.
3) Be ultra accessible
- We should ensure that the maximum number of people can use Binti. As government software we should be WCAG 2.1 and ADA compliant.
- Users may have language barriers - We know that many families of origin and relative parents interacting with the system do not have English as a first language - we want to support them to drive reunification and permanence.
- Mobile accessible - Caseworkers are often out in the field supporting children, helping foster families. Families or children may have no access to a desktop device.
- Slow network connectivity - Frequently foster families and ICWA families may be in rural areas or have poor access to internet, and workers may be out visiting these families to ensure children are on their way to reunification.
- Low tech/average tech - Our research shows that caseworkers may have been in their line of work for a long time and have less exposure to new technology. Software that workers currently use is typically outdated, 20+ years old. We also know relative foster families may not have access to computers, even commuting to the Library to complete their paperwork.
- Be forgiving - users make mistakes and the app should lovingly enable them to back out of their changes.
4) Intuitive design
- Design with the aspiration that any user could onboard with 0 hours of training, and be able to complete their primary task their first time using the app.
- Try to reduce complexity. Our app is going to have more surface area than many apps due to all the different workflows. Given this, it's even more critical that we are really thoughtful when we add new features and try to figure out if we really need them or if there is a way to keep things more simple.
(E.g., Looking at alternative options - will changing a piece of copy solve customer need v building a feature need)
- Orient the user: make choices so it’s clear where the user is in the flow and where they can go from there.
- Simplify the primary workflows for a user so they can move quickly through the app and spend less time on paperwork and documentation.
5) Scalable, consistent design
- Wherever possible reuse existing components.
- Design components that can be used to solve similar problems across the site. When solving a new design challenge, pull similar problems to ensure new components solve multiple problems
- Don’t use language that is only used by some customers. Try to pick language that is used or at least understood across all customers. If that is not possible, make it configurable.
- As agencies sign on to more modules the learning curve for new modules should be shallow.
6) Modern, loving feel
- Take a critical eye to design trends and evaluate whether or not they give the feeling of warmth and stability before adopting them as our own.
- Congratulate users for their work by giving signals of success!
- Use language and visuals that signal love and empathy.
7) MVP with a blue sky mindset
- Designs should consider 1-2 versions into the future. This ensures the best engineering choices can be made that sets us up for success in the future.
- Test and learn - create ways to minimize engineering effort upfront until we have a design that we feel achieves our design principles and truly solves the problem.
- Look for high impact quick wins. The best design doesn’t have to be complicated, but should solve the problem at its root.
- Make design tradeoffs that simplify engineering effort without sacrificing above principles.
We consider this to be a "living document," meaning as new challenges arise and debates occur within our team, we will add and adjust our philosophy to reflect our truest ideals. Don't hesitate to reach out if you see a gap- we believe in embracing any idea that helps us put the child first.