Visual SQL query builder
The purpose of visual SQL query builder software is to make complex database report creation simpler and more accessible. The software is meant for people who don’t want to nor have the knowledge to write complex SQL queries themselves, but still need custom reports that they can produce on their own.
I was engaged by an already successful software developer who had a big vision to reboot their existing builder product. Not only did they want to clean up and modernize the interface of their plug-in software, but they wanted to turn it into a Windows Presentation Foundation (WPF) application and bring a number of new internet-connected features to the product.
The majority of my initial work on the WPF software took place via phone-calls, video chats and collaborative whiteboard sketching. Together with the developer I talked through issues pertaining to the current product, what they wanted to achieve with the new software and discussed the gaps between.
Next, the developer and I organized the ultimate end-state of the new WPF application with a software interface architecture plan. We grouped the application features into containers that made sense to us, knowing that as the WPF software was built changes would come and user testing may prove some of our theories wrong, but we had to start somewhere.
After drawing countless wireframes on the whiteboard and discussing these ideas with the developer, I designed an initial high fidelity mock-up of how the WPF application could look. Feedback from the developer was that while I didn’t hit the target, I did get close enough to see what we could iterate on.
I considered the feedback, pondered how I could better design the WPF application’s user interface and gave it another try. It took me a few attempts, but I finally landed on something that I thought could work. I showed it to the developer and they loved it.
Building atop the foundation
Once I nailed this foundational screen, I was able to take it and extend it to the rest of the application. There were many complex screens and interactions to consider (and thus build) so I gave the designs to the developer in short cycles so they could code a working version while I continued to lay out screens. This pattern continued until we had a feature-complete version they could take to customers and demo with real data.