Argentina’s National Migration Department (DNM, by its initials in Spanish) sought to unify data from national and international sources (such as INTERPOL and other countries’ governments) to better predict criminal threats from anyone traveling to or from Argentina.
‍
SAM (Migration Analysis System) is a platform based on enterprise open-source software. With this new platform, the department gained a consolidated view of a person’s data, including information on attempted entries and potential criminal alerts. The National Migration Department can now use artificial intelligence (AI) more effectively to analyze potential threats and coordinate with security organizations.

We started with a set of ethnographic research activities, immersing ourselves in the daily routine of the DNM to gather insights and real pain points in their actual processes and tools.

We studied their teams and analyzed how they manipulate, cross, match, and interpret data provided from border crossings (land, air, and sea) and other national and international sources.

We were eager to understand:

• How users go about their day firsthand, which tools they were using, and what the real context was.
• The collaboration process between national and international departments, including securi
• All types of reports generated from the migration department in order to collect and study them.
• All detected problems and be able to highlight those that could be opportunities for the product.

Activities included passive observation, contextual interviews, card sorting, and expert review of their digital tools.

We invested several weeks doing so and, fortunately, we gathered a considerable amount of information. The anxiety from stakeholders began to mount. We were about to build a product from scratch in every way.

Our next step was designing and running an “Ideation Workshop.” DNM’s staff, developers, and stakeholders participated.The different perspectives brought different visions of the ideal product that helped us in the process and, equally important, aligned expectations.

Everybody was very excited about the activity, and the amount of information we were collecting at that point was growing fast.Many ideas were coming up, and we started merging them and putting them down in a hypothetical prioritization matrix as reference.

Among the hundreds of insights, the following ones were those that inspired our first ideas:

• They were suffering daily because of the tool’s performance. Those who had to manipulate the old software daily found themselves with limitations to handle a significant volume of data. Therefore, they were crossing fewer data sources, getting less information and inaccurate reports and, not least important, they were getting very frustrated. “Why can’t this be as fast as Google or Facebook, what will it take to make it so?”
• The current tool wasn’t offering data visualization, so users were spending too much time reading tons of sheets of data and doing inaccurate reports.“I need faster ways to read all this”, “This isn’t like in the movies, with a bunch of graphs, big screens or artificial intelligence.”
• Data crossing was done manually by printing and marking sheets. They had many tricks we needed to learn and transfer to a feature. “When I have to cross data, I print sheets, and I use markers to get it done, it’s not only the fastest way, it is the only way.”
• All the border crossings in Argentina have different types of equipment and technology. Some of them, such as airports, are very advanced, but others are quite simple. In consequence, data was coming in different ways, formats, and times. “Our goal is always to be a few steps ahead of criminals. It is hard work with all the border crossings.”
• They were manually creating reports and spending too much time doing so. As a result, the information was mostly accurate, but the way they were printing it out was without the advantages of data visualization. “Our bosses want conclusions so they can proceed, but data gives relevance and understanding to those conclusions.”
  

With all these ideas broken down in a manageable format, we started to think of a strategy to plan the product. We knew that prototypes should be tested very fast in a feedback circuit (Design Sprint) to shortcut the endless debate cycle.

The list of selected features was big, so we invested a few days in prioritizing those that were feasible and added value to the different kinds of DNM users.

The product would also have special features available for some users, so we also had to prioritize which user personas to work with first. The information architecture was challenging mostly because of the amount of user access levels since there was too much sensitive information.

We had long meetings to understand the technical implications of each feature we were proposing and to explore alternative design solutions. We always looked at everything that came out of the ideation workshop, feature references from other products, and new artifacts we were designing. At this point, we had already visualized the first version of the product and how to build it properly.

After several sprints, we launched the first version of the product successfully, and we started an iterative process of designing and launching new features on the testing stage every week.

To get this done in terms of delivery, we did wire-flows, wireframes, prototypes, user testing, more interviews, user diaries after launch, and much more. We also worked closely with statistics professionals and engineers to improve our data visualization ideas. With the help of the users we iterated a lot in these fields to create better reports and expand the amount of relevant information on it.