New Product Launch: IDB Project Mapping

idb project mapping

As we wrapped up the redesign of the IDB website, the team reached out to see if Analogous could assist with a redesign of their mapping tool, MapAmericas.

MapAmericas was used as a secondary mechanism for IDB employees in the field to input project data, with the additional benefit of geo-targeting projects and their corresponding results. The public-facing map featured every project across Latin America, introducing users to contextual information within a click. The concept was useful, but the interface segmented projects by country, had limited filtered views and the iconography overlapped and confused navigation. With a low adoption rate by all users, we had our work cut out for us.

As I wrote up a heuristic evaluation of the user experience, the design team researched mapping solutions out in the wild to review the variety of visual and experiential options in play. After a review of all our findings, we settled in on an overarching approach:

  1. The project map couldn’t exist as a destination point in the global navigation. While it had the potential of being be a smart, useful visualization of regional projects, it just didn’t fit the context of how users browse or might use it. We decided early on that the map needed to be accessed contextually from project, sector and country pages while providing avenues to return to the same templates when appropriate
  2. There’s a large amount of structured data found on project pages, but only structured in terms of the information design of the page, which allowed for great readability. We needed to free up data as explicit attributes for filtering purposes to navigate within the map interface.
  3. The overlap issue needed to be address, so we decided upon a clustering approach for projects living in nearby proximity at high-level views, and situations when exact geo-coordinates overlapped. We also created two tiers to the map—a pre-project view and a project/results view—which allowed for different behaviors specific to the context of the current task.

idb-maps-interaction-model

project filter wireframe

The resulting experience now allows users to view projects across all of Latin America, but subsets particular to persona interests. So an Education Minister in Bolivia can view all education projects in her country, and then broaden the results to show education project across the entire continent, allowing for better context. Similarly, data points such as total cost and phase were made available as filters, so that same user can now view projects in the approval phase that cost $50M-$100M. These were simple, yet powerful changes to the browse paradigm.

project view wireframe

Once the user drills down to a particular project view, results are now explicitly tied to the project, whereas previously, results lived within their own view with no discernible relationship to a project and/or a mechanism to get more project information. The cognitive result is an immediate processing of scale—how many outcomes were produced by a single initiative.

A decent amount of code tweaking remains in order to get the experience exactly right, but that should occur over the next few months. Once we have usage numbers, I’ll update this post.

Ajax… About Time

So it’s Friday night and I find myself cruising around the web after a night out. In my travels, I landed on JJG’s blog and subsequently stumbled into his Ajax essay on the Adaptive site. The only real conversation I’ve had on the topic was a recent conversation with a client-side developer pal and after reading Jesse’s well defined description of the approach and the benefits, my initial reaction was pretty much, “ok.”

I don’t say that to offend, nor downplay the great client-side work anyone is doing right now, it’s just that I’ve been immersed in online application design for years now and have always attempted to communicate these types of design solutions to developers. I say “these types of solutions” lightly, as I’m a designer, not a developer, so from my perspective these communication calls have been screaming to be stiched together for a while now.

Jesse spoke to the difficulties of designing online applications due to the technical workarounds which have been historically necessary to successfully support innovative interface behavior. While I agree on the impact on next-generation type apps, I disagree with the approach to design, for while practicing interaction design, scenarios shouldn’t be modeled based on technological constraints.

As David Fore of Cooper exhorts, the period of scenario modeling should be a period of making magic—that’s how innovation occurs to support user needs; the limitations of the front-end evolve over time. I agree that one has to understand the constraints of the medium when designing for it, but only to a degree, otherwise one can handcuff a more useful experience by setting the box too tight.

So how can one design for the user, while considering possibilities of Ajax?

While at Ameritrade I was able to convince management to include our relatively small client-side development team in my UX team. That brief organizational commitment created a huge opportunity for me to espouse innovation and collaboration across both designers and developers. I didn’t know how long the group structure would last, so I instantly switched up working from the level of context scenarios and began to iterate on features

We used the phrase “push the browser until it pushes back” more times in our weekly staff meetings than could be counted. Our client behaviors needed to be supported in our online applications, so in turn, I refused to limit us to any narrow definitions of client-side technology.

snapticket

Thankfully, my CSD team latched onto my mantra with vigor and did the heavy lifting to evolve our conversations into working code, while myself and the IxD team returned to iterating user needs into interface behavior.

Did the team use the Ajax approach per se? Probably not, but they pretty much pushed the browser until their SOP is now reflected in some of the latest Ajax app behaviors, such as Gmail.

Business as usual for design and development at Ameritrade began to evolve.

Were the solutions as soundly executed across the board as Google’s current attempts in leveraging an Ajax approach? I’d have to say no again, as we were performing Ajax-type workarounds on the fly. But the mere fact that the team addressed dynamic interface scenarios on a case-by-case basis, with dynamic executions on the presentation layer, led our marketing group to center their next campaign around the slogan:

Welcome to the 21st Century. Now trade like it.

The ripple effect of progressive experience design was contained, as it only applied to the authenticated Apex trading platform, but Barrons seemed to notice it by giving us a 4 star rating (up from 2.5 stars the previous year).
deposits_withdrawals_ui
A switch to a complete Ajax approach at Ameritrade today would entail a short period of refactoring, but would make the current authenticated interface move from “singing” to “harmonizing.”

Ajax should mark the sweet spot of the golden age for presenting complex scenario relationships as simplified behavioral experience in the browser.

Elegance in motion.