Below I've listed a few examples of when I've helped a Business Ask (a proposed solution) evolve into a more well-defined, lower-risk Problem Statement.
In each case, this helped me deliver a product solution that saved the business needless expense, and helped earn the business increased revenue -- all by giving users what they wanted, in a way technology could deliver it.
To see visuals and more details, check the Portfolio section.
"Users say search sucks.* How can we improve search on the whole platform, so medical journal users can actually find what they're looking for?"
*actual quote
A CMS-based enterprise website product, used to publish 300 different online medical journals
Not only did this project save the company from losing a $300,000 customer, it also caused our central search team to roll out the improvements we made to other products.
"Turn this existing website into a native app usable by doctors at patient bedside. And let us know what needs to be in MVP because we don't have much money. Oh, but design for future iteration too!"
Native mobile app offering clinical tools doctors need to use in seconds to provide patient care.
The original instruction of "turn the website into an app" would have resulted in a horrendously bloated project. By instead identifying only the primary tasks users wanted to complete, the business saved countless hours of developer time, and the users wound up with a much more easy to use product.
"How can we make these lengthy documents* about a specific Prescription Drug more usable for patient care?"
*"lengthy" meaning about 40+ printed pages, written in huge walls of text
Subscription-service-based website product used by global medical researchers and doctors, to learn about drugs.
When dealing with third party content, never make assumptions about what's easy to change. In this case, even the smallest change could mean months of work.
By analyzing past research, tackling the largest user pain-point, and co-creating wireframes with clinicians, we quickly knew what to change first, and what to plan on addressing in the future.
"Turn this book into a mobile app for physicians, so we can save printing costs and avoid book pirating."
Mobile app containing library of health condition information, written in medical shorthand, to be used by doctors.
By taking time to understand how doctors used the printed book, we made sure we supported all user needs.
If we had not examined the book first, we would have made an app that was worse than the printed version, and entirely estranged the print audience.
"Tell us which native app features and content are needed when doctors are offline -- in Brazil, France, Germany and America."
Multi-language, multi-country, native mobile app and responsive website, used by doctors at bedside, to provide clinical care.
Nearly all business assumptions were disproven by the survey results. Offline wasn't a "by country" challenge, or a "by care facility type or location" thing... It was far more nuanced than that. User needs extended down to the Use Case, of "today I'm working near the MRI machine and there's cell interference", and caused us to rethink our entire feature approach.
"Can you design these 100+ screens with reusable design patterns so the Tech Team can avoid rework when building?
Also, coordinate what you're doing with the Corporate Design System team.
And make sure the international branding team is happy too."
Design Pattern Library, organized by components, to document the Design System Branch used by our product.
The original ask here was just to help the Dev Team avoid rework. No one specifically asked me to create a Design Pattern Library. But I knew the product was big enough, and the team large enough, that it was the best strategy.
I'm proud to say that several of my design components now live in the corporate design system -- user tested, and user loved.