MPI - Plants Biosecurity Index

MPI - PBI

Website: piersearch.mpi.govt.nz/plants-biosecurity-index

Size: a searchable database showing the import status of over 30,000 plant species as seeds and nursery stock

Government status: Government Ministry

My professional status: contractor at MPI

Website client: Ministry for Primary Industries

Dates: July - October 2022 launch date. Post-launch upgrades October 2022 - January 2024

Categories: IA & UX, Website designer, Front-end developer, Writing for the web, Responsive web design/dev, CSS-based layout, CSS3, HTML5, e-govt/WCAG compliance, SilverStripe, Government websites, Large sites

Brief: The Ministry for Primary Industries is responsible for export opportunities for our primary industries, improving sector productivity, ensuring the food we produce is safe, increasing sustainable resource use, and protecting New Zealand from biological risk.

I worked at MPI as UX designer, responsive web designer, front-end developer, e-govt compliance specialist and post-integration tester, designing and building a series of web-based applications and tools within the biosecurity sphere, under the umbrella of the PIER (Product Import and Export Requirements) project.

As a last-minute addition to the PIER family, we were asked to redesign and rebuild the Plants Biosecurity Index (PBI) and integrate it into SilverStripe, ready for launch at the same time as the updated ONZPR and new PIER Search tools.

The PBI is a searchable database of over 30,000 plant species. It provides information on whether each species can be imported into New Zealand as seeds or nursery stock. This 20-year-old MPI online tool was so old and out-of-date it could no longer be updated by editors or even developers, and was in danger of falling over permanently at any moment. Losing access to this valuable tool was not an option for MPI, hence the decision to rebuild it and include it in the PIER project.

I was responsible for the UX design, responsive web design, front-end development, cross-browser and mobile device testing, e-government compliance and accessibility, and post-integration testing and QA. My WebWeaver colleague Tom St George did the SilverStripe integration.

Achievements:

  • With less than four months before go-live, switching my thinking towards this new PBI tool and figuring out how we could add it to the PIER family and launch it at the same time as ONZPR and PIER Search
  • Listening to initial "let's save time" suggestions from senior team members on how a limited new version of PBI might be designed, concluding that this would not be what our users wanted or needed, and successfully arguing my case for a more function-rich version that better suited the requirements of our users
  • Refining and improving on the UX of the original 20-year-old PBI, bringing the interface design up-to-date and making it much more user-friendly and intuitive
  • Using my existing ONZPR templates as a starting-point for the HTML/CSS build, both to save time and also because these were already being integrated into SilverStripe by our developer
  • Taking over as our SilverStripe post-integration tester after our actual tester's contract ran out, working directly with our SilverStripe developer to get everything perfect before launch.

My responsibilities included:

  • Reviewing and testing the current live version of the PBI, to see how it worked and what it could do - as we would be using this as a starting-point for the rebuild
  • Meeting with the product owner and other senior team members to get an idea of what functionality needed to be retained, what needed to change, and what new functionality they wanted to add
  • Reviewing the senior team's suggestions for radically changing PBI's functionality from a free search tool into a series of clickable tiles which would take the user to pre-made sets of search results - and feeling that this solution would not provide our users with what they wanted or needed
  • Drawing up wireframes for an alternative rebuild solution which adhered much more closely to the functionality of the current tool - which we knew users liked and found useful
  • Presenting my alternative solution to the whole team and succesfully arguing my case for why I felt it was important to retain the full free search functionality, rather than provide users with a much more limited set of pre-defined results
  • Using Balsamiq to wireframe the UX for the new PBI tool - including search box and initial results displays, modal windows, tables of refined results and import requirements detail pages
  • Continually updating these wireframes as the team added functionality, working through seven iterations as we refined how the application would work and the scope of the project gradually expanded
  • The wireframes then acted as a blueprint for the design and build processes, and included functionality requirements and detailed instructions for the developer, as well as a full set of responsive screens shown at various breakpoints
  • Writing the microtext, introductory text, and help text across all pages and templates
  • Working to solve some edge case scenarios which the product owner had identified before his contract came to an end and he had to leave the project, which we needed to cater for in the finished product
  • Running fact-finding meetings with our MPI business owner and our systems analyst - to ensure that I was incorporating the functionality they needed into my designs
  • Regularly presenting my wireframes to the rest of the team within the context of a group critique, requiring me to clearly explain each part of the process and allowing us to make ongoing improvements
  • Close collaboration and consultation with the database developer, to ensure that what I wanted the search tool to do, could actually be done and made sense - in the early days of this project, this was actually the person who had built the original PBI tool for MPI 20+ years earlier - which was handy
  • Attending bi-weekly standups and other meetings with the team, within an (informal) Agile working environment
  • Regularly updating our ongoing sprint records and bug-tracking system
  • Designing the look and feel of PBI, using my recently-updated ONZPR design which had been based on the existing MPI website as a starting-point
  • Focusing the design on a clean and minimal interface, where elements were logically positioned and easy to use, and as intuitive as possible
  • HTML5 and CSS3 build of the application using my updated ONZPR templates as a starting-point, writing a new override stylesheet for PBI to save time, designing and building new elements as I needed them
  • Providing the developer with a full set of HTML/CSS templates for each of the various page layout types, together with modal windows for help text and a print stylesheet
  • Extensive cross-browser and mobile device testing (screen and print) before I handed over my templates - using a combination of real devices and BrowserStack
  • Ensuring that we maintained the high standards of accessibility and e-govt compliance that we had achieved for the new ONZPR SilverStripe templates
  • Close collaboration and consultation with the SilverStripe developer, reviewing the build as it progressed (SilverStripe custom build, based on my templates)
  • Post-integration testing and QA, working alongside our full-time website tester until her contract finished, and then taking over testing myself, working directly with our SilverStripe developer to get everything perfect before launch.

MPI PBI responsive screens in various devices

As a last-minute addition to our already super-tight timeline, PBI was an interesting curve-ball - especially as the original tool was now over 20 years old and about to expire.

It's based closely on the other members of the PIER family in design and layout, which allowed us to save time on the design and build, but it's got its own special eccentricities which made it an interesting challenge to get right, especially within such a tight timeframe and alongside the work I was already doing for ONZPR and PIER Search.

I particularly enjoyed figuring out the rules for the Boolean OR search (show all options selected) within a single set of results (Seeds for sowing or Nursery stock), contrasting with the Boolean AND search (show only the results that match both options selected) between the two sets. I drew these up in my wireframe diagrams as a single screen showing multiple sets of results, so that the developer could understand the interface behaviour I wanted to achieve, and the tester could test it. I do love a nice bit of logic.

Naming conventions

Once I'd handed over my PBI templates to the developer for integration into SilverStripe, I switched my attention to a new wireframes document entitled "Naming conventions". Now that I could see all four tools together (ONZPR, PIER Search for Imports, PIER Search for Exports, and PBI) it was clear that there were some inconsistencies in titles, breadcrumbs, h1 headings and linked tile text. It's inevitable when you're working on a number of tools across a three-year life cycle, but it didn't sit well with me and I wanted to make it right.

I used the wireframes document to list and summarise each of the page types within each of the tools, recording the page name, page h1, tile text in parent page, page title (approx 65 characters will show up in Google search results), number of characters, breadcrumbs, hamburger menu text and sidebar navigation text. Once all this data was displayed in a single table it was easy to see patterns and inconsistencies and make updates and improvements, as well as setting the naming convention rules for future additions.

I then drew up a wireframe example of each page type and marked with sticky notes all the updates and changes that needed making to each one. This document was provided to the SilverStripe developer so that he could make the changes and set up auto-rules for elements such as breadcrumbs and titles, and to our tester so that she had an exact reference for testing. Super-satisfying for this detail-oriented completer-finisher perfectionist!

We launched SilverStripe versions of all four PIER tools - PIER Search for Imports, PIER Search for Exports, ONZPR, and PBI - on the same day in mid October 2022.

Post launch upgrades, improvements and a few fixes

Once the four PIER tools had been successfully launched, we switched our attention to upgrades and improvements. I had a mental list of all the nice-to-haves that we had wanted to include in the first iteration of the PBI, but which we had had to put on hold due to time limitations.

I compiled an "upgrades" set of wireframes for the team, that contained screens showing all the improvements and embellishments we'd discussed and explored during the design and build process, but which we hadn't yet had a chance to implement. I then created a matching spreadsheet listing all the possible upgrades across all four PIER tools, with a summary of what needed doing, a time estimate for each, a grading for level of importance, and an indication of which members of the team needed to be involved. I also included one or two fixes I had identified needed doing, where the interface was not quite behaving as expected, and could be improved.

I shared this spreadsheet with the team, and together we decided on a priority list for fixes and upgrades, which Tom and I set about working through in the first instance. Other team members were brought on board as needed. I kept the spreadsheet updated so that we could track our progress and see what still needed to be done. As blocks of work were completed they were published to the live site and the wireframes updated to match.

We continued this work - and also some preparatory work for Stage 2 of the PIER project - until January 2024. In February and March we discussed ongoing SLAs and SOWs with the new product owner, at which point the project was put on hold due to budgetary restrictions.

Other MPI websites