What We Want to Learn When a Law Firm Starts Using What We’ve Built
By Chris Spencer | Spencer Technology Solutions, LLC
CYDRA Law has been shaped by input from legal professionals and people with firsthand experience working inside law firms. As we prepare for the next stage of hands-on testing, we want to understand how those decisions hold up in everyday use.
For me, that means paying attention to more than whether someone can complete a task. I want to understand whether the steps make sense to them, whether they can find the information they need, and where the software asks them to do more work than it should.
The upcoming exploration will use sample data, with no actual client information entered during this stage. It gives the participating team room to try workflows, ask questions, and tell us where the experience needs improvement before we move into beta.
Review the video below:
Legal experience has shaped the work throughout
Legal contributors have helped us examine what information should be collected, what needs review, and what must happen before the next step in the client journey.
That collaboration continues as people get more time with the product. Someone can help describe a process and later discover, while working through it, that a step feels awkward or that information belongs somewhere else. The hands-on experience gives us another way to examine the decisions we have made together.
A milestone that brings new questions
Recently, I watched a member of my team (a legal professional) demonstrate a complete workflow in CYDRA Law, from the start of a case through closure. Seeing that for the first time was emotional. My team had brought something I had envisioned into a form we could walk through together.
That walkthrough was a meaningful milestone. The upcoming exploration asks a further question: what happens when members of a law-firm team work through scenarios themselves, making choices and raising questions along the way?
This builds on our existing testing and workflow reviews. I want us to listen closely when participants’ experiences differ from what we expected.
Where someone hesitates
One thing I want to notice is where someone pauses. Do they know where to begin? Can they find a record without being told where to look? After completing a step, can they tell what happens next?
A pause does not automatically mean the design is wrong. Someone may be learning an unfamiliar system, or a question may reveal a training need. But it is worth understanding before we move on. If we explain every step immediately, we may miss an opportunity to see what the product communicates on its own.
I want to ask what the person expected to happen and what they were trying to accomplish. That gives us something more useful to examine than simply telling them which button to click.
Whether the workflow fits the work
A sequence can look sensible during a demonstration and feel cumbersome when someone works through it. We want to understand where a person has to repeat information, leave one area to finish an action elsewhere, or remember a detail that should be easier to see.
Reviewing payment and consultation scheduling has already prompted me to question the number of actions involved. If someone creates a booking link, can sending the related message be more straightforward? What needs to remain separate because it serves a purpose?
What happens when the process does not go as planned
We also want to explore scenarios that do not move neatly from one step to the next. Required information might be missing. A payment might be pending. Someone might need to reschedule a consultation.
Using sample records lets the team explore those situations without putting actual client information into the system during this stage. Can they see what is holding up progress? Is it clear who should act? Can another team member understand the status without asking someone to explain the history?
How we will use what we learn
Feedback may point to a defect, an unclear label, a missing instruction, or a workflow decision that needs another look. Those require different responses. We need to understand the problem before treating every suggestion as a request for another feature.
As we review the feedback, I want us to connect each observation to the work someone was trying to complete. We can then decide what needs fixing, what needs clarification, and what needs further discussion with the people involved.
We plan to follow this period of exploration with beta. What we learn here should help us judge readiness for that next stage. I would rather use the feedback to make that decision than treat the end of a calendar period as proof that we are ready.
Questions worth asking about any new software
For a law firm evaluating software, the same approach can be useful. Choose a realistic scenario and let the people who will do the work try it. Ask where they needed help, what they expected to see, and which steps required unnecessary effort. Include a situation where something is missing or delayed.
As a founder, I am proud of what my team has built. I also want people to feel comfortable telling us when something is confusing or cumbersome. Their feedback is part of building a product that supports their work.
The question I most want to ask at the end of a session is simple: “Where did CYDRA Law make the work easier, and where did it get in your way?”
Comments