“Agile” applied to our search re-design
12:17:45 pm on March 29, 2012 | # |
See our search engine at: http://search.apps.lclark.edu
From the begining of the search redesign project, we have focused our design efforts on keeping things simple and clean. Instead of trying to get everything perfect in the first release, we have smaller releases with improvements and feature additions over time. This process is usually a Rapid Application Development (RAD) cycle with agile coding practices. We primarily base our RAD development off a system called “build measure learn” and use a web application called “pivotal tracker” to track and manage our progress. This type of design methodology basically enables our team to quickly design, deploy and learn from our previous cycles. We then take what we learn and “pivot” or change our tactics to better address what we learned from previous cycles. What this means is most of the improvements we make are based on feedback from our users, bugs we find, or feedback from our web monitoring service. As our design improves, the frequency of needed improvement and feature requests continue to drop and we have a more stable search application.
When we began the design process we had numerous ideas and features that we needed to analyze. We knew many of them would not make the cut, but we still wanted to have an awesome product that was easy to use with a clean concise interface.
At first we ran with a few crazy cool ideas about cutting edge interfaces, but we soon realized we needed to reduce our set of functionalities to the “minimum viable product” or the features that we just couldn’t live without. We tossed out several dynamic embedded designs for a more traditional one and moved some design elements to a future release iteration.
The initial release has a clean tabbed interface. The tabs make it easy to switch between having combined results and filtering by specific content types. Additionally we decided to integrate a Google site search in a separate Google tab.
Throughout the initial release phase we did a lot of “learning” about our design. One thing that we quickly discovered was our “recommended links” where often seen as as adds. Using our Pivot strategy we tried a couple of design variations, pivoted and tried another and finally found one that seems to work for most people.
Almost as soon as we deploy a change we are able to see it reflected in our feedback both for good and bad and then pivot to address those issues. Using an agile design and development strategy lets our small team respond quickly to issues and increase the quality of our products without sacrificing our sanity… Well what we have left anyhow
– Nick Shobe