Skip navigation

Selected recent work

Pictures can be pretty, but without seeing the thought and process that goes into defining and solving a problem, it’s impossible to know if the result is successful.

Starting with some very recent work (still in-progress, to be precise) I hope to build a showcase that can communicate the process as well as the result.

The problem: Science’s cross-site search was built on Google’s Custom Search product, which was phased out in March 2018. A completely new back-end was constructed in-house, and a new front-end was needed to complement the new functionality and solve problems with the existing search that we learned about through user feedback.

The solution: We explored several options including a SaaS search platform and even just not having a search functionality. before deciding on an approach. The audience for this product is very well defined: scientific researchers of all career stages. We need to connect them with the research content they rely on to stay informed and do their jobs.

Search Revision 1

The first step in a successful search experience is to put high quality results in front of the user as quickly as possibly. For most users, this is the extent of what they need. They’ll hopefully find what they’re looking for and then move on. Most of this happens on the back-end.

Our users have told us a lot about what they expect from a scholarly search, including that they’re willing to drill down to get to what they’re looking for. Researchers expect certain advanced options. We needed to make it easy to understand the pre-search options, as well as how to drill down into results.

One additional feature we knew we’d want from the start is to swap the site’s standard alignment of thumbnail images, from the left-hand side to the right. The result is more scannable text, while keeping the image, which we’ve learned is useful to them.

This quick sketch gets to the heart of what I knew we’d need to deliver: A search field, advanced search options, search results, and refinement options.

Tools used: Marker and paper

Search Revision 2

The second revision takes specific field options into account and fleshes out the layout of the form. We experiment with a two-column layout instead of three, a top-left to bottom-right flow with the results appearing below the advanced form.

Tools used: Marker and paper

Search Calendar

Around this time, I also started to explore the more complicated form elements. Science’s content archive dates back to 1880, and a simple, yet powerful, date picker is essential to searching a range of dates.

Tools used: Marker and paper

Search Revision 3

The third revision builds on the second, focusing on the functionality of the fields and takes the existing layout of the site further into account. Additional detail in the margins uses information taken from discovery and requirements documentation. We’ve validated our basic concept and refined to the point where markers and paper won’t be of much more help. Time to commit this to the screen…

Tools used: Marker and paper

Search Revision 4

The fourth revision takes the concepts from the third and fourth revisions, and moves them to a Sketch wireframe. The fields are further refined, and the entire work begins to take on more of the look of the actual site design.

It was always going to be difficult to get all of the essential elements and functionality enough visibility to allow for discoverability, so we gave the three-column layout from the second revision another try.

Tools used: Sketch

Search default form Search Final

The final design revision shows the form in both default and complete states. As the user performs a search, the facets appear inline below the fields they relate to. Time constraints dictated that we needed to begin development at this point. After a round of validation with internal users with a simple prototype (not shown, sorry), we were ready to start front-end integration.

So what's next? Time constraints dictated by the sunsetting of Google Custom Search and the need to keep pace with the back-end engineering necessitated a light touch when it came to up-front research. A impending initial release means we can now begin a second phase, with a baseline experience in place. Now we begin learning from what we have and plan for future iterations…

Tools used: Sketch

The first release launched with many of the planned features. We decided to hold back on a few features, however, and start collecting data and direct user feedback to learn what was really necessary. The initial goal was to put high quality results in front of the user as quickly as possibly, and in this the launch was very successful.

We've been collecting a good amount of direct feedback and behavioral data since the launch, and we've learned a few things. The most striking issue was that while performance is excellent in the United States, we've received a substantial amount of feedback indicating real problems in China. It's on the agenda to track down in the near future.

The date picker also turned out to have some real accessibility challenges associated with it. We know from conversations with some of our vision-impaired users that this is a common problem. We hope to fix it by relying on the new HTML5 datepicker input.

Finally, we found that we need more options around author names. In our testing, we found that a facet might not be helpful since, with 140 years of content, there are hundreds of thousands of names, and a facet could only reasonably show a few. We're exploring the problem, but it's looking likely that we'll need to add a field to search first names and initials. It's a tricky problem that we can't solve entirely on the user end. Even many well-known authors have been inconsistently named in our records over the years.

For now, the work goes on.