Apex Solutions is a global market research company. Apex developers designed a Query Builder tool to allow users to create SQL-like queries without knowing code. Data analysts found the tool both powerful and very confusing. Apex Solutions wanted my help improving the usability of the tool and the rest of their platform.
An onsite workshop with developers and users from Apex greatly informed my designs. Prototypes of ideas from the brainstorming session the day before elicited amazing feedback. By collaborating with users, we redesigned the Query Builder to accommodate their needs.
Approximately 90% of the platform's users are data analysts. While analysts vary widely in technical ability, we trust they are comfortable working in Microsoft Excel and with running predefined scripts.
The remaining 10% of users are software developers who help analysts with more complicated data extraction. Developers write new scripts and develop additional functionality as needed.
Developers naturally designed the platform to suit their needs. However, they neglected the needs of their primary users, data analysts. To achieve our project goals, I used a persona to remind the developers of the needs of our primary users.
Users define conditions in the side menu which then populate the main canvas.
Some on Team Apex wanted the "Condition Builder" side menu to expand full screen. This would offer more room for input fields and less visual distraction to help users focus.
After some debate, I opted to put the Condition Builder in a resizable side panel. I wanted users to have the ability to see the main canvas as they worked to add conditions. I also wanted to minimize context switching for users during these long, complicated wizard flows.
As I learned to build queries, I would describe my intention in text and ask the team to check my work. This exercise inspired the "Written Expression" window. The window translates what's on the canvas into text, helping users see their mistakes. The previous design communicated mistakes only after the query had run.
This component was a huge hit when I shared it with users at the onsite workshop.
We wanted to empower users to use the tool in whatever way makes sense to them. However, more freedom for users meant more possibilities to account for. The developers and I worked hard to define the tool's behavior for all scenarios.
A simple example of this can be seen when a user reorganizes an "OR" grouping. If a user abandons a lone condition within an "OR" grouping, the operator defaults to "AND".
The developers who created the platform naturally designed it to fit their needs. I wanted to also address the needs of the primary users, data analysts.
1. The long list of 20 recent jobs on the home page suits developers who troubleshoot the latest errors. Analysts, who only need to refer to their most recent 2- 3 jobs, found the long list overwhelming.
2. The "Apps" button triggers a modal which displays all available apps in a long list (not shown). Developers launch many apps in the course of their work, but analysts only use the same couple repeatedly. Analysts grew frustrated poring over the exhaustive list to find the few they wanted.
The new home page has a much cleaner user interface.
1. Users can now pin favorite apps and jobs to the top of the view for one-click access
2. I simplified the long "Recent Jobs" list.
A complete, searchable list of all apps is now available on an apps landing page.
Team Apex was very enthusiastic about these design updates. I'm happy to report that while we made changes with analysts in mind, developers were also excited to pin favorites and appreciated the simpler, cleaner interface.
Data analysts run scripts (or lists of commands) in the course of their work. The Script Editor tool allows developers to edit scripts within the platform.
Like most flows in the original design, the Script Editor was implemented as a wizard. Users complained of not being able to skip steps that were unnecessary to their work. Also, I witnessed users having to navigate back to reference data shown in earlier steps. It became clear that a wizard was the wrong design pattern for this tool.
I redesigned the Script Editor as a dashboard.
1. Data tables display in floating, collapsable, resizable windows (like tools in Adobe Photoshop).
2. Developers can now refer to the code they're editing on the main canvas as they fill in related data tables.
3. Users can easily ignore tables when they're not needed (unlike the previous wizard design). In the wireframe, the "Dictionary" window has been left closed since its not currently needed.
The developers at Apex were a dream to work with. They patiently spent hours walking me through the Query Builder tool, to teach me how it should (and how it did) work. I really enjoyed learning so much about a new domain, albeit in a very short timeframe.
The whiteboarding sessions during the onsite were the highlight for me. Having users so involved in the process was exciting and helpful. My quick and dirty prototype managed to convey our ideas enough to solicit valuable feedback. While my time with Apex has ended, they continue to be invested in our new design and will improve it over time.
"Ben did an excellent job of working with the users and iterating through various designs quickly to arrive at a solution that was intuitive and simple." - Project Lead, Apex Solutions