Business-focused custom software

I recently worked on a design where we struggled with finding the best approach for a particular requirement. In the end, we came up with a great approach that is a big improvement over the current one. Here’s how our design approach evolved.

The Problem

The application is a search tool that helps people find affordable housing in Minnesota. The current system allows for several search criteria, including geographic location. The current implementation uses 4 list boxes – two for cities and two for counties. The first list box in each group shows a list of all the cities, the second list box contains just the selected cities. The county implementation works similarly.

To select a city, the user selects the items in the first list box, then clicks on an arrow to copy it to the selected list box. Checkboxes at the top of each section allow the user to limit the items to just cities or counties within the metro area.

There are a few problems with this user interface. First, it takes up a lot of space. Second, it is not exactly intuitive. And finally, users often found the search results they got confusing. That was because they would select a county, and a city (that wasn’t in that county), and they would get no search results, because our search rules stated that if a city and county was selected, BOTH criteria must be true to appear in the results.

Attempt 1: Simple selection

Our first attempt at a solution was to convert the city and county list boxes to drop down lists, and got rid of the checkboxes. Users could only select one county, and optionally one city, and the city had to be within the county. This restriction was so that our city list wouldn’t become so large that it was unwieldy for end users.

Quickly we realized this would not work. Users definitely wanted the ability to select multiple counties and/or cities. This solution would solve the city-not-in-county selection problem, however.

Attempt 2: Checkbox lists

Our next attempt used scrollable checkbox lists. Users would select desired counties. If they wanted to narrow the search by city, they would click on a “Get List” button which would then populate the city list. We also divided the county list into two sections, pulling the metro counties to the top of the list so that they would be found more quickly.

We were much happier with the scrolling checkbox lists, which we felt were more intuitive to use than the original list boxes. But the “Get List” button was problematic. What if the user retrieved a list, and then changed the county list again – would they remember to click the button again? It felt like we were closer, but not quite right.

Final Solution: Change the rules

After a design review with several staff who worked closely with end-users, we got some excellent feedback that really helped to improve this. First, we learned that users really do two types of searches – either metro area or non-metro area. Giving the user this option first could help us keep the city list to a manageable size without forcing the user to select a county first.

Also, we changed the rules. Previously the rules stated that records in the results list had to match one of the items in the selected county list AND one of the items in the selected city list. But we discovered that users really wanted to search for a particular county and a city or two outside that county. By changing the search logic, we are giving users what they want instead of imposing an arbitrary rule.

Lessons learned:

• Don’t give up! Each time we came up with another solution, I wasn’t happy with the result, but I thought it was the best we could do. Each time I was wrong! The final solution is one that I am happy and proud of. I think users will be very pleased with the end result.
• Get additional feedback! We got great feedback from our team that helped us come up with this final version. This happened during our review of the design with the organization, and it made all the difference.