Some Assembly Required

The IKEA Effect and AGOL COTS Applications

Universal human behaviors are often exploited through commercial means long before they can be articulated through proper scientific study. In the 1950s, Gillis Lundgren, an employee at a fledgling Swedish mail-order business, pioneered flat-pack, ready-to-assemble furniture resulting in wide-ranging benefits: the ability to hold more inventory on site, cost-savings on assembly, easier consumer transportation of purchased goods, and easier commercial bulk shipments. Today, that mail-order business is IKEA, the world’s largest furniture retailer, with an annual global revenue in excess of 35 billion Euros. Although the business case for flat-pack furniture seems straightforward; Norton et al.’s The IKEA effect: When labor leads to love articulates a deeper psychological mechanism underpinning the success of ready-to-assemble products aptly termed the “IKEA effect”.1 Broadly, this describes how consumers value items they help assemble at higher levels than identical products assembled by others. Understanding and recognizing this cognitive bias can lead the average GIS professional to produce more polished, effective applications utilizing custom-off-the-shelf (COTS) applications available in the ArcGIS Online (AGOL) ecosystem.

The IKEA Effect Unpacked

The IKEA effect was based on the analysis of a series of experiments where certain participants constructed and bid on IKEA storage boxes or folded origami, while others bid solely.1 These experiments measured value by comparing willingness-to-pay against the different classes of products assembled by participants and assembled by others, with the caveat that the assembly process must be fully completed.

Establishing the IKEA Effect and its Magnitude - Experiment 1A & 1B

These first two experiments focus on identifying the existence of higher valuation for self-assembled products and finding relative benchmarks for how much higher those valuations are in comparison to different standards. Experiment 1A shows that participants were willing to pay a 63% premium for a simple box that they had constructed themselves, as opposed to an otherwise identical box that was pre-constructed. This is the broadest sense of the IKEA effect and justification for the namesake. Perhaps even more interesting was the next experiment measuring magnitude.

First, participants, termed builders, were asked to create an origami frog or crane, and offered a chance to purchase their own creation. Second, a group of experts constructed the same types of origami creatures. Third, a different set of participants, termed others, were asked to bid on both sets of works-- --setting a market price for papercraft animalia ranging the spectrum from amateurish to expert. The resultant average bids ranged from $0.05 - $0.27; builders valued their artistic endeavors at a premium of 23 cents, while others were willing to pay the paltry sum of a nickel for the self-same creations, and consummate origami was priced at 27 cents. The acute implication of this data is that builders without fundamental instruction, rote, or preparation imbue value into their products at comparable levels to the market rates for expert-crafted products.  

At first glance, it may seem odd to evaluate the cognitive biases exploited in the creation of consumer goods; however, there are parallels to trends within the geospatial technology. The increasing prevalence of software as a service (SaaS), has shifted the focus of geospatial technology from desktop-based programs to distributed cloud-based applications. The consumerization of software users outside of the initial purchase and licensing is mostly achieved by aggressively offering online, custom-off-the-shelf (COTS) applications. The GIS professional’s interactions with these COTS applications mirrors the ready-to-assemble furniture experience; minimal instructions, standardized parts throughout an ecosystem, and lightweight components requiring no technical expertise. If cloud COTS applications mimic the flat-pack workflow, how do we make the most of our understanding of the IKEA effect?   

Built to Last

The worst web maps I’ve ever had the pleasure of seeing were made by me, I have also built a spectacular end table that holds the litter box for my cat. The more honest truth is the cat-box seems to be coming apart at the hinges, and requires a weekly kick to straighten it out; my web applications suffer the most when I don’t take the time to polish the end-user experience. At home, my feline customer doesn’t complain about the architectural deficits introduced in the assembly of the facilities. At work, my potential customer base includes 180,000 residents, the working population and any visitors or guests that the City may see on a given day. The following are some selected strategies to employ in order to polish and more effectively utilize COTS products available in ArcGIS Online (AGOL).

Don’t “Deploy in Minutes”

One of the greatest stren?gths of the COTS paradigm is the inclusion of What-You-See-Is-What-You-Get (WYSIWYG) preview capabilities. These applications allow you to visualize what the end-user sees when interacting with your product. This is not a frill, it’s an opportunity to preempt embarrassing phone calls, emails, and social media posts from the viewer-base. The temptation to stand up an application, in mere minutes often sacrifices the chance to create a great experience for the end-user, one that is unencumbered by distractions created through a sloppy delivery.

Akin to reading the instructions before assembly, a standardized checklist should be an integral part of the development process before any COTS application is floated either internally or externally. Cartographic conventions aside, this usually starts with your Web Map item and configuring the pop-ups. From legacy attribute architecture to the 10 character limit of the dreaded shapefile, your <Field Alias> needs to be different from your <Field Name>; concise, explanatory, and use spaces. Don’t display attributes you don’t need, this includes ObjectID and shape fields. Get rid of the thousands separator option. Omit unnecessary pop-ups, if it’s the only thing on the map and has a unique symbology, this would be an excellent item to put into a legend.

Metadata is helpful to your colleagues, other GIS professionals, and your future self. There are now subtle prompts directing you to fill in metadata in the description page of your Web Mapping Application, Web Map, Dashboard, Feature Layer, etc. A summary should be at least 30 words, and accurately describe the purpose of your map. The description should be more than 100 words, and might go further into detail about the types of layers within the application, update schedules, links to other applications in the AGOL ecosystem, and other pertinent information. Tags will help others find your work, and thinking about how to tag your own work can lead you to other sources of inspiration for the problem you’re trying to tackle.

For the applications themselves, throw in your logos/branding, standardize the color scheme between applications and make sure that you link back to your main site. Your tagline doesn’t have to be “with Web AppBuilder for ArcGIS” or “A story map”. For the more narrative-driven applications, spelling and grammar become important considerations. While you may not be a wordsmith, there are plenty of free applications and browser plug-ins to ferret out the most major infractions; I’d recommend giving Grammarly2 a go for basic spelling and grammar, or the Hemingway Editor3 if you suffer from being too rambling and verbose.

Despite the straightforwardness of the phrase, face-value is difficult to assess under the dual influences of the IKEA effect and the usual intimacy of a GIS professional with the data in which they work. Developing standardized ways of interacting with COTS applications will help ensure that the end-user experience is as uniform as possible between each visit and across differing applications hosted by your organization. At the end of the day, I shouldn’t have to kick the catbox, I should have built it correctly out-of-the-box. In like fashion, robust standard operating procedures should keep the wobbles out of your web apps.  

Display with Pride

Interaction with the AGOL COTS ecosystem exposes us to the IKEA effect, but unlike the average consumer, our shoddy constructions are not safely sequestered within the halls of a private domicile, they live in the cloud, available to anyone across the planet with an internet connection. This makes it imperative that we identify and resolve our psychological predispositions to value work at a level higher than its face value. While we may gloss over the imperfections inherent in our own works, the end-user is unlikely to be as forgiving; our perceived value closer to a nickel than a quarter. 

“Don’t try to get all fancy…it doesn’t work.”

The word “fancy” brings up about 20 results in my inbox, this is one of them. I’ve also gathered other gems like “interactive map is horrible” and “map is useless”. In all fairness, they were right. The map in question had an issue that made the selection radius horribly small, a handful of pixels. Less than noticeable on a desktop computer, glaringly obvious on any mobile device. This experience opened my eyes and let me see the unwieldy, rickety applications that I had proudly deployed.

This same critique can be applied to the ever venerable All-In-One map. If your map has 30 layers, you’re not doing anyone a service by hosting it. Disparate data needs to be presented with the proper context, single subject, focused applications should be the rule of thumb. In a similar vein, just because you can add a dashboard doesn’t mean that you should. Your data tells a story, it does so in specific ways. Averages and on-the-fly calculators don’t mean anything if the data they crunch was not significant to begin with.

I've heard it said a few different ways, usually a variation of, if X can't use it, then you need to make it simpler. Be careful to casually cast a net involving X-type of person, the more accurate advice is to ask your audience to test your application. This is easiest if your audience is limited or exactly known. If your audience is nebulous or too broad, go and ask subject matter experts, GIS colleagues, laypersons, and those you would consider to be computer illiterate. Each of these people will provide insight that you may not have had yourself, or find difficult to see through the spectre of the IKEA effect.

The general trends of the geospatial industry are not changing anytime soon, and we will continue to see SaaS play an ever larger role as data complexity deepens and so too the computational requirements to effectively analyze it. The demand for cloud-based infrastructure, out-of-the-box data science, and COTS applications will only be outpaced by the avalanche of data that we continue to produce in real-time streams through increasingly web-enabled devices. These tools are powerful, convenient, but rely on “the builder” to assemble them correctly. Our natural impulse is to over-value the fruits of our labor, even when it involves minimal expertise. Recognizing this cognitive bias allows us to control its effects. A detailed and thoughtful examination of our interactions with ready-to-assemble applications can help us pass along showroom-quality experiences to “the others” that use our products the most.

1Norton, Michael I., Daniel Mochon, and Dan Ariely. "The IKEA Effect: When Labor Leads to Love." Journal of Consumer Psychology 22, no. 3 (July 2012): 453–460.

2www.grammarly.com

3www.hemingwayapp.com

This article was originally published in URISA's The GIS Professional Issue 282.