MPI - PIER Search

Size: an online search tool providing info on hundreds of thousands of import and export scenarios

Government status: Government Ministry

My professional status: contractor at MPI

Website client: Ministry for Primary Industries

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

Categories: IA & UX, Content designer, Website designer, Front-end developer, Writing for the web, Content-loader, 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, content 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.

The core product in Phase 1 of the PIER project is PIER Search. This online search tool enables users to find NZ import and export requirements for a range of commodities and countries.

PIER Search for Imports covers commodities that pose a biosecurity risk to New Zealand, some of which must meet certain requirements to be imported while others are prohibited or have not yet been assessed. PIER Search for Exports covers the phytosanitary requirements for a number of commodities and countries/regions that are used as the basis for export certification.

PIER Search is a search tool that enables users to drill down to the very specific commodity/country combination they are interested in, and provides them with detailed import or export requirements for that commodity. This tool provides users with a short-cut to the information that is otherwise hidden away amongst the hundreds of pages that make up the many Import Health Requirements (IHRs) and Importing Country Phytosanitary Requirements (ICPRs) published by MPI over the years.

PIER began life as "Plant Import and Export Requirements". By the time I joined the project a few months after its inception, it had expanded its scope to become "Product Import and Export Requirements" - and it continued to expand in complexity and detail over the next three years.

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

Achievements:

Built on the work I'd already done on ONZPR, improved it, and expanded it into the UX and design for PIER Search
Got my head around the complex (and ever-growing) PIER Search data model and used that to shape my initial UX thinking and design
Designed and built an online search tool that catered for the very wide range of personas and user types listed in the original specifications
Completely revisited the accessibility and e-govt compliance of the HTML/CSS, as I wasn't happy with the levels we achieved for ONZPR within too-tight time constraints and knew we could do better - by the time I'd finished we were at gold star level with WebAim, WAVE, AXE and Cynthia Says
Designed and built an online search tool that replaced a number of existing MPI tools - with no complaints from existing users who had no choice but to switch
Created a simple and clean interface that worked for everyone - regardless of their level of interest or expertise.

My responsibilities included:

Using Balsamiq to wireframe the UX for the homepages, search screens, modal windows, tables of results and import/export requirements detail pages
Continually updating these wireframes as the team added functionality, working through 23 iterations within three completely different design directions for Imports and 12 iterations for Exports - 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
Content design - writing the microcopy, introductory text and help text for the entire application
Working closely with the product owner, Udo Froetschl, to brainstorm and figure out some of the trickier functionality he wanted to include, and to wireframe our solutions
Working to solve a wide range of edge case scenarios from the product owner, which we needed to cater for in the finished product - a couple of which prompted wholesale re-thinks and/or expansion of various parts of the application
Running fact-finding meetings with various expert-level MPI staff who would be using the new search tool - including Import and Export Advisers, Market Evaluators and Quarantine Officers - 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
Regularly presenting my wireframes to major stakeholders across MPI within the context of a show-and-tell presentation inviting feedback, requiring me to clearly explain each part of the process in order to ensure we were meeting their expectations
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
Close collaboration and consultation with the database team, whose job it was to read and translate the IHSs and ICPRs into a series of individual requirements, and enter these into the ever-expanding database
Using HTML to quickly mockup various options and keep a strict eye on the design practicalities - for example the maximum number of columns that can be fitted into a responsive table
Using these mockups to push back on impractical requests - and finding an alternative solution instead
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 of the look and feel of PIER Search, using my ONZPR templates which had been based on the existing MPI website design as a starting-point
Tweaking the MPI design elements to give us more horizontal width (many multi-column tables of results to display) and with an improved level of e-govt compliance and accessibility
Improving and expanding the responsive behaviour of the templates, including increasing the horizontal real-estate at various breakpoints, multiple breakpoints for the layout of the search form, and resizing header and subheader text responsively
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 ONZPR templates based on the existing MPI page templates (HTML and CSS) as a starting-point, writing a new override stylesheet for PIER Search 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
Completely revisiting the accessibility and e-govt compliance of the HTML/CSS, as I wasn't happy with the levels we achieved for ONZPR within too-tight time constraints and knew we could do better - by the time I'd finished we were at gold star level with WebAim, WAVE, AXE and Cynthia Says
Close collaboration and consultation with the SilverStripe developers, 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.

PIER Search took a long time to design and build - nearly three years from inception to Phase 1 launch. When you first look at it, it seems simple enough - it's just a search tool, right? How complicated can it be?

In fact, for all of us who worked on this project. it quickly became apparent that it was really quite complex - and not easy to get your head around. We went through a few database wranglers, developers and testers along the way - some of whom stayed for the duration, and others who only stuck it for a short while before they realised it was all too much.

PIER Search was an interesting challenge to design and build, not least because the initial specifications had identified nine different persona groups who had to be catered for, with 42 unique user types being listed. This included MPI advisors, border security officers, professional importers and exporters of all kinds - plus the general public. A huge range of requirements and personas that needed to be covered in a single web search application.

Udo Froetschl was the heart of the project - and the brains of the operation - and the only one of us with a complete picture of the inner workings of the entire application in his head. He drew the first data model and the last (which was quite a bit more complex) and all the ones in between, and helped the rest of us understand it and make it work.

He and I spent quite a bit of time working together on mad edge cases he'd have thought of in the middle of the night, and which absolutely had to have a solution. Together we'd brainstorm, whiteboard, argue to and fro for a bit, decide on the best way forward, and then I'd go off and think through the details and wireframe them. He's fantastic to work with, and because we think the same way, we always came up with solutions we were both happy with. Useful!

As an island nation, New Zealand is in a unique position as regards pests and diseases - there are many that we don't have here, and don't want to have. One of MPI's responsibilities is to monitor the biosecurity risk of all imports, and to produce rules and requirements for importers bringing in commodities from overseas. MPI's Import Health Standards (IHSs) detail these requirements for a vast range of commodities imported from each country - based on which unwanted pests and diseases could potentially be found on a commodity imported from a particular country.

There are over 270 different IHSs, some covering a single commodity from a single country, others covering a broad commodity type such as nursery stock from a huge list of countries, with different requirements for each species from each country. As a result, some IHSs can be over 350 pages long, complex, and have been written and rewritten and edited many times over the years. They are sometimes hard to understand - even for professional importers - and they're not always logical and consistent.

Most countries also have their own set of phytosanitary requirements for different commodities being imported from different places, and these requirements vary quite dramatically from country to country. It's a complex maze for NZ exporters to navigate. MPI obtains these phytosanitary requirements from importing countries, and publishes these as Importing Country Phytosanitary Requirements (ICPR) documents. ICPRs include the phytosanitary requirements that must be met by New Zealand exporters. There are over 3,300 ICPR documents, and, like the IHSs, some are long, complex, and not very easy to search.

At its core, PIER Search is a tool which sidesteps the time-consuming trawl through hundreds of pages in IHSs and ICPRs, and instead enables importers and exporters to go straight to the import/export requirements for a specific commodity type, commodity, and country combination.

PIER Search is made up of two parts - the data, which has been painstakingly extracted by our data team from the official documents and placed into thousands of rows in our data tables - and the search tool itself, which is the interface through which the user chooses the commodity and the country for import or export.

PIER Search distills the mass of IHS and ICPR information down into tiny bite-sized pieces and presents it to the user as a series of search results, based on the commodity and country criteria the user enters. It allows the user to drill down through the mass of variables that define even a single commodity (commodity type, end use, part or life stage, state and condition), filtering out the ones they aren't interested in, and producing as its end point a requirements page that summarises all the import or export biosecurity measures that must be carried out. This page also includes direct (anchored) links to the relevant section(s) in all applicable IHSs or ICPRs.

In addition, the requirements page lists the related pests for the specific commodity and country combo the user has asked for. Each pest on the list is linked to that organism's detail page in the ONZPR (Official New Zealand Pest Register), which is also part of the PIER project.

So for each product, the PIER Search requirements page summarises the phytosanitary measures that must be met and provides links to other key information, such as the legal requirements under an IHS or ICPR, any permits or declarations that must be completed and any guidance MPI has developed.

The design is simple, clean and clear. Clarity and simplicity of the interface is helpful for everyone, whatever their professional level of expertise or interest. This tool has to work equally well for an MPI adviser, a professional importer or exporter, and Mrs Bloggs down the road who just wants to buy some wildflower seeds online.

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 PIER Search, 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.

MPI - PIER Search

Post launch upgrades, improvements and a few fixes

Other MPI websites