Our Process
How do we create excellent user experiences at Deep Why? Put simply, we start and end with people - what do people need, what are they good at, what are they afraid of, what do they already know, where could they use some training? What is going to make it easier to succeed and harder to fail over time? Then we move on to making the technology match.
What makes an excellent user experience in the Salesforce® ecosystem?
Clarity and Transparency
All users - including external users - are able to know where and how to enter and retrieve data for the tasks they have to do on a regular basis, and who to ask when something unusual comes up.
Staff turnover is not disruptive - losing your admin doesn’t mean losing momentum.
The sources, uses, and transformations applied to data are transparent to everyone. Users feel confident that they can connect the dots between data on a report or dashboard and data in the database.
It’s clear who should do what under what circumstances, and the barriers to success in completing those roles are removed to maximize the potential for success.
Equitability
The database is not a punishment for doing your job or balanced too far toward one group or another. It isn’t an afterthought, a second step, or something you need to set aside time on your calendar just to deal with. Instead, it is a useful tool that supports your daily operational tasks and is every bit as much of your process as email or the other tools you rely on.
Wherever possible, efforts are made to ensure that things are accessible to as many people as possible - through clear language, help and guidance, tutorials, as well as design for a range of experience levels and methods of approaching digital systems. We’re a neurodiverse team so we appreciate the importance of building for lots of different ways of dealing with screens and processes.
What does this look like in practice?
We look to work with your systems by adjusting the most enduring and sustaining things first and exploring increasingly custom options last and only after exhausting all other options.
We take this approach because at each step, you add more complexity and technical debt (ongoing maintenance cost) to your environment. So we need to make sure that we’re solving first through education and mutual understanding, second through process and alignment, third through the most common and well-supported tools, and finally customization only if it’s justified.
By proceeding through the first several layers of questioning, we also build the organization’s capacity to make a truly informed choice about their tradeoffs in the short and long term, and really understand what they’re choosing when they choose to customize.
Education and Mutual Understanding
Does everybody understand what their Salesforce® ecosystem is, does, and can do?
What questions and pain points are coming up that are pure demystification, training, and gap closing that we can address quickly and help the organization address sustainably over time?
Does everybody know the other tools (like a mass mailer, or a web form) that integrate with the organization’s Salesforce® environment?
Does everybody understand when and how to use their Salesforce® ecosystem to do their jobs?
What questions and pain points are coming up that are internal knowledge, job aids, internal clarity on roles and responsibilities?
For smaller orgs we can help with this, for larger organizations we have partners who can help out too, particularly where the misalignment between the data you capture for program and the data you need for reporting is a persistent pain point.
Process and Alignment
Is Salesforce® actually configured, at baseline, to do what is needed and expected and are your processes aligned with that Salesforce® can do?
Are the processes set up in a way that makes best use of the tools?
Are you expecting to use the right tools - whether Salesforce®, an integrated tool, or some other technology - at the right step in the process?
Are your processes and expectations aligned with what your Salesforce® environment actually can do, and does further education and and explanation about the toolkit’s strengths and limitations guide us into a process adaptation?
Is a simple process change or redesign, coupled with some adjustments, a viable solution?
Is there anything we can adjust easily in the toolkit to address misalignments?
Inside of Salesforce®, we look at Lightning page layouts, custom report types, permissions, sharing rules, and many other elements that often get left behind as the system evolves post-implementation.
Tools that are meant to be integrated may not be integrated well or at all, or may be configured in a manner that your organization has now evolved away from.
Looking to the Most Common and Well-Supported Tools
If your processes, understanding, and expectations are all checking out but your experience is still not OK, is it due to an inherent limitation or just needing to set up some more advanced tools within the Salesforce® toolkit (like Flows and Screen Flows).
More advanced tools within the Salesforce® toolkit start to add some technical burden for maintenance.
Who on your team can be responsible for ensuring future changes don’t break the new solution?
When Customization is Understood and Valid
If it’s an inherent limitation — Salesforce® just doesn’t do that — then we look to the broader toolkit and ensure you can make an informed decision about your tradeoffs.
Is there a product that solves this issue that is both affordable and sustainable for the organization?
What tools do we need and what does it look like to solve the problem?
What is the expected total cost of ownership plus the ongoing internal commitment to solving the problem with customization?