Sohrab Vossoughi discusses the restrictions current patent laws place on interaction design for Havard Business Reivew.

http://blogs.hbr.org/2014/03/dont-let-patent-law-hold-back-interaction-design/

Dr. John Ma from OHSU and Creative Director Eric Park are interviewed about "The First Five"- a project to reduce anxiety in the ER.

http://www.bizjournals.com/portland/print-edition/2014/03/14/how-ziba-and-ohsu-team-up-for-a-more-patient.html

The SAM Junctional Tourniquet is featured on the Portland Egotist.

http://www.theportlandegotist.com/news/local/2014/march/13/ziba-business-saving-lives

Ziba Munich’s PURE cleaning system is intuitive, simple and generates far less waste by combining cleaning concentrates with a single, refillable bottle.

http://www.fastcodesign.com/3027484/household-cleaners-get-an-eco-friendly-makeover#10

Interaction Design Director, Todd Greco, writes how a Comcast and Time Warner Cable merger could stifle digital innovation.

http://www.fastcodesign.com/3027314/the-real-victim-of-the-comcast-time-warner-merger-digital-innovation

Sean Madden explores the benefits and potential pitfalls of highly personalized technology and environments. 

http://www.wired.com/opinion/2014/03/designers-tracking-tradeoffs/

One of the improvements to ChefSpec in the 3.0 release is the ability to extend test coverage to execute blocks. Doing so requires the infrastructure developer to stub out shell commands run as part of the idempotence check. This is pretty simple as ChefSpec provides a macro to stub shell commands. However doing so where the idempotence check uses a Ruby block is slightly more involved. In this article I explain how to do both.

Quick overview of ChefSpec

ChefSpec is a powerful and flexible unit testing utility for Chef recipes. Extending the popular Ruby testing tool, Rspec, it allows the developer to make assertions about the Chef resources declared and used in recipe code. The key concept here is that of Chef resources. When we write Chef code to build infrastructure, we’re using Chef’s domain-specific language to declare resources – abstractions representing the components we need to build and configure. I’m not going to provide a from-the-basics tutorial here, but dive in with a simple example. Here’s a test that asserts that our default recipe will use the package resource to install OpenJDK.

require 'chefspec'

RSpec.configure do |config|
  config.platform = 'centos'
  config.version = '6.4'
  config.color = true

  describe 'stubs-and-doubles' do

    let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }

    it 'installs OpenJDK' do
      expect(chef_run).to install_package 'java-1.7.0-openjdk'
    end

  end
end

If we run this first, we’ll see something like this:

$ rspec -fd spec/default_spec.rb 

stubs-and-doubles

================================================================================
Recipe Compile Error
================================================================================

Chef::Exceptions::RecipeNotFound
--------------------------------
could not find recipe default for cookbook stubs-and-doubles

  installs OpenJDK (FAILED - 1)

Failures:

  1) stubs-and-doubles installs OpenJDK
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     Chef::Exceptions::RecipeNotFound:
       could not find recipe default for cookbook stubs-and-doubles
     # ./spec/default_spec.rb:10:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:13:in `block (3 levels) in <top (required)>'

Finished in 0.01163 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/default_spec.rb:12 # stubs-and-doubles installs OpenJDK

This is reasonable – I’ve not even written the recipe yet. Once I add the default recipe, such as:

package 'java-1.7.0-openjdk'

Now the test passes:

$ rspec -fd spec/default_spec.rb 


stubs-and-doubles
  installs OpenJDK

Finished in 0.01215 seconds
1 example, 0 failures

Test Doubles

ChefSpec works by running a fake Chef run, and checking that the resources were called, with the correct parameters. Behind the scenes, your cookbooks are loaded, but instead of performing real actions on the system, the Chef Resource class is modified such that messages are sent to ChefSpec instead. One of the key principles of Chef is that resources should be idempotent – the action should only be taken if required, and it’s safe to rerun the resource. In most cases, the Chef provider knows how to guarantee this – it knows how to check that a package was installed, that a directory was created. However, if we use an execute resource – a resource where we’re calling directly to the underlying operating system – Chef has no way to tell if the command we called did the right thing. Unless we explicitly tell Chef how to check, it will just run the command again and again. This causes a headache for ChefSpec, because it doesn’t have a built-in mechanism for faking operating system calls – so when it comes across a guard, it requires us to help it out, by stubbing the command.

This introduces some testing vocabulary – vocabulary that is worth stating explicitly, for the avoidance of confusion. I’m a fan of the approach described in Gerard Meszaros’ 2007 book xUnit Test Patterns: Refactoring Test Code, and this is the terminology used by Rspec. Let’s itemise a quick glossary:

  • System Under Test (SUT) – this is the thing we’re actually testing. In our case, we’re testing the resources in a Chef recipe. Note we’re explictly not testing the operating system.
  • Depended-on Component (DOC) – usually our SUT has some external dependency – a database, a third-party API, or on our case, the operating system. This is an example of a DOC
  • Test Double – when unit testing, we don’t want to make real calls to the DOC. It’s slow, can introduce unwanted variables into our systems, and if it becomes unavailable our tests won’t run, or will fail. Instead we want to be able to interact with something that represents the DOC. The family of approaches to implement this abstraction is commonly referred to as Test Doubles.
  • Stubbing – when our SUT depends on some input from the DOC, we need to be able to control those. A typical approach is to stub the method that makes a call to the DOC, typically returning some canned data.

Let’s look at a real example. The community runit cookbook, when run on a RHEL derivative, will, by default, build an RPM and install it. The code to accomplish this looks like this:

bash 'rhel_build_install' do
      user 'root'
      cwd Chef::Config[:file_cache_path]
      code <<-EOH
tar xzf runit-2.1.1.tar.gz
cd runit-2.1.1
./build.sh
rpm_root_dir=`rpm --eval '%{_rpmdir}'`
rpm -ivh '/root/rpmbuild/RPMS/runit-2.1.1.rpm'
EOH
      action :run
      not_if rpm_installed
end

Observe the guard – not_if rpm_installed. Earlier in the recipe, that method is defined as:

rpm_installed = "rpm -qa | grep -q '^runit'"

ChefSpec can’t handle direct OS calls, and so if we include the runit cookbook in our recipe, we’ll get an error. Let’s start by writing a simple test that asserts that we include the runit recipe. I’m going to use Berkshelf as my dependency solver, which means I need to add a dependency in my cookbook metadata, and supply a Berksfile that tells Berkshelf to check the metadata for dependencies. I also need to add Berkshelf support to my test. My test now looks like this:

require 'chefspec'
require 'chefspec/berkshelf'

RSpec.configure do |config|
  config.platform = 'centos'
  config.version = '6.4'
  config.color = true

  describe 'stubs-and-doubles' do

    let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }

    it 'includes the runit recipe' do
      expect(chef_run).to include_recipe 'runit'
    end

    it 'installs OpenJDK' do
      expect(chef_run).to install_package 'java-1.7.0-openjdk'
    end

  end
end

And my recipe like this:

include_recipe 'runit'
package 'java-1.7.0-openjdk'

Now, when I run the test, ChefSpec complains:

1) stubs-and-doubles includes the runit recipe
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     ChefSpec::Error::CommandNotStubbed:
       Executing a real command is disabled. Unregistered command: `command("rpm -qa | grep -q '^runit'")`"

       You can stub this command with:

         stub_command("rpm -qa | grep -q '^runit'").and_return(...)
     # ./spec/default_spec.rb:11:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:14:in `block (3 levels) in <top (required)>'

ChefSpec tells us exactly what we need to do, but let’s unpack it a little, using the vocabulary from above. The SUT, our stunts-and-doubles cookbook, has a dependency on the operating system – the DOC. This means we need to be able to insert a test double of the operating system, specifically a test stub, which will provide a canned answer to our rpm command. ChefSpec makes it very easy for us by providing a macro that does exactly this. We need to run this before every example, so we can put it in a before block. The new test now looks like this:

require 'chefspec'
require 'chefspec/berkshelf'

RSpec.configure do |config|
  config.platform = 'centos'
  config.version = '6.4'
  config.color = true

  describe 'stubs-and-doubles' do

    before(:each) do
      stub_command("rpm -qa | grep -q '^runit'").and_return(true)
    end

    let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }

    it 'includes the runit recipe' do
      expect(chef_run).to include_recipe 'runit'
    end

    it 'installs OpenJDK' do
      expect(chef_run).to install_package 'java-1.7.0-openjdk'
    end

  end
end

Now when we run the test, it passes:

$ rspec -fd spec/default_spec.rb 

stubs-and-doubles
  includes the runit recipe
  installs OpenJDK

Finished in 0.57793 seconds
2 examples, 0 failures

That’s all fine and dandy, but suppose we execute some Ruby for our guard instead of a shell command. Here’s an example from one of my cookbooks, in which I set the correct Selinux policy to allow apache to proxy to a locally running Netty server:

unless (node['platform'] == 'Amazon' or node['web_proxy']['selinux'] == 'Disabled')
  execute 'Allow Apache Network Connection in SELinux' do
    command '/usr/sbin/setsebool -P httpd_can_network_connect 1'
    not_if { Mixlib::ShellOut.new('getsebool httpd_can_network_connect').run_command.stdout.match(/--> on/) }
    notifies :restart, 'service[httpd]'
  end
end

Now, OK, I could have used grep, but I prefer this approach, and it’s a good enough example to illustrate how we handle this kind of case in ChefSpec. First, let’s write a test:

it 'sets the Selinux policy to allow proxying to localhost' do
  expect(chef_run).to run_execute('Allow Apache Network Connection in SELinux')
  resource = chef_run.execute('Allow Apache Network Connection in SELinux')
  expect(resource).to notify('service[httpd]').to(:restart)
end

If we were to run this, ChefSpec would complain that we didn’t have an execute resource with a run action on our run list. So we then add the execute block from above to the default recipe. I’m going to omit the platform check for simplicity, and just include the execute resource. We’re also going to need to define an httpd service. Of course we’re never going to actually run this code, so I’m not fussed that the service exists despite us never installing Apache. My concern in this article is to teach you about the testing, not write a trivial and pointless cookbook.

Now our recipe looks like this:

include_recipe 'runit'
package 'java-1.7.0-openjdk'

service 'httpd'

execute 'Allow Apache Network Connection in SELinux' do
  command '/usr/sbin/setsebool -P httpd_can_network_connect 1'
  not_if { Mixlib::ShellOut.new('getsebool httpd_can_network_connect').run_command.stdout.match(/--> on/) }
  notifies :restart, 'service[httpd]'
end

When we run the test, we’d expect all to be fine. We’re asserting that there’s an execute resource, that runs, and that it notifies the httpd service to restart. However, this is what we see:

Failures:

  1) stubs-and-doubles includes the runit recipe
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     Errno::ENOENT:
       No such file or directory - getsebool httpd_can_network_connect
     # /tmp/d20140208-30704-g1s3d4/stubs-and-doubles/recipes/default.rb:8:in `block (2 levels) in from_file'
     # ./spec/default_spec.rb:20:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:23:in `block (3 levels) in <top (required)>'

  2) stubs-and-doubles installs OpenJDK
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     Errno::ENOENT:
       No such file or directory - getsebool httpd_can_network_connect
     # /tmp/d20140208-30704-g1s3d4/stubs-and-doubles/recipes/default.rb:8:in `block (2 levels) in from_file'
     # ./spec/default_spec.rb:20:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:27:in `block (3 levels) in <top (required)>'

  3) stubs-and-doubles sets the Selinux policy to allow proxying to localhost
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     Errno::ENOENT:
       No such file or directory - getsebool httpd_can_network_connect
     # /tmp/d20140208-30704-g1s3d4/stubs-and-doubles/recipes/default.rb:8:in `block (2 levels) in from_file'
     # ./spec/default_spec.rb:20:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:31:in `block (3 levels) in <top (required)>'

Finished in 1.11 seconds
3 examples, 3 failures

Boom! What’s wrong? Well, ChefSpec isn’t smart enough to warn us about the guard we tried to run, and actually tries to run the Ruby block. I’m (deliberately) running this on a machine without the ability to run the getsebool command to trigger this response, but on my usual workstation running Fedora, this will silently pass. This is what prompted me to write this article, because my colleague who runs these tests on his mac kept getting this No such file or directory – getsebool httpd_can_network_connect error, despite the Jenkins box (running CentOS) and my workstation working just fine. So – what’s the solution? Well, we need to do something similar to that which ChefSpec did for us earlier. We need to create a test double, only this time it’s Mixlib::ShellOut that we need to stub. There are three steps we need to follow. We need to capture the :new method that is called on Mixlib::ShellOut, and instead of returning canned data, like we did when we called stub_command, we want to return the test double, standing in for the real instance of Mixlib::Shellout, and finally we want to control the behaviour of the test double, making it return the output we want for out test. So, first we need to create the test double. We do that with the double method in Rspec:

shellout = double

This just gives us a blank test double – we can do anything we like with it. Now we need to stub the constructor, and return the double:

Mixlib::ShellOut.stub(:new).and_return(shellout)

Finally, we specify how the shellout double should respond when it receives the :run_command method.

  allow(shellout).to receive(:run_command).and_return('--> off')

We want the double to return a string that won’t cause the guard to be triggered, because we want to assert that the execute method is called. We can add these three lines to the before block:

before(:each) do
  stub_command("rpm -qa | grep -q '^runit'").and_return(true)
  shellout = double
  Mixlib::ShellOut.stub(:new).and_return(shellout)
  allow(shellout).to receive(:run_command).and_return('--> off')
end

Now when we run the test, we’d expect the Mixlib guard to be stubbed, the test double returned, and the test double to respond to having the :run_command method called be that it returns a string which doesn’t match the guard, and thus the execute should run! Let’s give it a try:

Failures:

  1) stubs-and-doubles includes the runit recipe
     Failure/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     NoMethodError:
       undefined method `stdout' for "--> off":String
     # /tmp/d20140208-30741-eynz5u/stubs-and-doubles/recipes/default.rb:8:in `block (2 levels) in from_file'
     # ./spec/default_spec.rb:20:in `block (3 levels) in <top (required)>'
     # ./spec/default_spec.rb:23:in `block (3 levels) in <top (required)>'

Alas! What have we done wrong? Look closely at the error. Ruby tried to call :stdout on a String. Why did it do that? Look at the guard again:

not_if { Mixlib::ShellOut.new('getsebool httpd_can_network_connect').run_command.stdout.match(/--> on/) }

Aha… we need another double. When the first double is called, we need to return something that can accept a stdout call, which in turn will return the string. Let’s add that in:

before(:each) do
  stub_command("rpm -qa | grep -q '^runit'").and_return(true)
  shellout = double
  getsebool = double
  Mixlib::ShellOut.stub(:new).and_return(shellout)
  allow(shellout).to receive(:run_command).and_return(getsebool)
  allow(getsebool).to receive(:stdout).and_return('--> off')
end

Once more with feeling:

$ bundle exec rspec -fd spec/default_spec.rb 

stubs-and-doubles
  includes the runit recipe
  installs OpenJDK
  sets the Selinux policy to allow proxying to localhost

Finished in 0.7313 seconds
3 examples, 0 failures

Just to illustrate how the double interacts with the test, let’s quickly change what getsebool returns:

allow(getsebool).to receive(:stdout).and_return('--> on')

Now when we rerun the test, it fails:

Failures:

  1) stubs-and-doubles sets the Selinux policy to allow proxying to localhost
     Failure/Error: expect(chef_run).to run_execute('Allow Apache Network Connection in SELinux')
       expected "execute[Allow Apache Network Connection in SELinux]" actions [] to include :run
     # ./spec/default_spec.rb:31:in `block (3 levels) in <top (required)>'

This time the guard prevented the execute from running, and as such the resource collection didn’t contain this resource, and so the test failed.

Conclusion

One of the great beauties of ChefSpec (and of course Chef) is that at its heart it’s just Ruby. This means that at almost any point you can reach into the standard Ruby development toolkit for your testing or infrastructure development needs. Hopefully this little example will be helpful to you. If it inspires you to read more about mocking, I can recommend the following resources:

Author:
Topic: Methodology

This article was originally posted on VMSD as separate contributed pieces titled: Has Retail Lost its Way, When Magic Matters, Retail Renaissance and I Want it Here, Now

Retail has lost its way. Not so long ago, people knew their butcher, baker and candlestick maker, and had valued personal relationships with these artisans. Today, too much of retail has become an undifferentiated, one-size-fits-all delivery machine. Competition is steadily increasing – digital advances mean the barriers to entry in the retailer game have never been lower – and people are better informed of options, prices, and alternative channels than ever before. More back-and-forth communication between people and brands means that consumers are leading the way, moving faster and faster, forcing brands to evolve even more quickly, just to keep up.

Big ships turn slow, though, with lots of lead time needed just to change direction, let alone turn 180 degrees. Consider the many big retailers who redesigned or rebranded in 2013, ranging from the widely reported trials and tribulations at JCPenney, to the latest in a never-ending streak of experiments at Target.

All brick and mortar stores are being pressured by new channels with low overhead, ever-expanding offerings and innovative delivery options. IBM reported smartphones were behind 22 percent of this season’s online Black Friday purchases.

The same digital devices that have put consumers increasingly in control of the terms of retail interaction are also constantly distracting them. People complain of being overwhelmed by choice; “retail fatigue” is a thing. In fact, there are threads linking all these seemingly disparate problems. Let’s investigate a few things retailers should already be thinking about – although not all seem to be – in order to stay on top of the game tomorrow.

1. (Re)embrace craft, in every sense of the word.
Refocusing on the craft of selling will help retail find its way again. Examples of highly specialized retailers thriving through attention to the craft of retail are out there, if you look. And they’re not all new.

Selfridges and Harrods have both managed to stay relevant to their consumers for more than a hundred years by continually leading with strong retail narratives. Re-embracing the craft of selling means getting back to storytelling by leveraging both technological and analog strengths. Storytelling needs to happen at every touchpoint – make stores places people want to go, not spaces for stuff. Put on a show. Think bigger than just sales and holiday decorations.

Giving customers an experience along with the goods helps reinforce larger narratives, like Danner has done at Portland’s new Union Way. The product might be available elsewhere, even at a lower cost, but fun and excitement aren’t as easily transferrable. Anthropologie has not lacked for plaudits, and they deserve the credit for building such rich, cohesive presentations. The lifestyle on display in-store – it’s even further developed online – makes Anthropologie feel like a real destination. Even Best Buy, which was slated by many to suffer the same fate as Circuit City, has benefitted from investing back into their store experience, racking up greatly improved sales, with shop-in-shops and revitalized store brands. BBY was up 250% over the course of 2013.

This renaissance isn’t just going to be a return to higher level in-person or online service… it’s also going to require an elevation of the quality, caliber and thoughtfulness of curation and goods.

2. Get comfortable with prototyping all the time (and be prepared to fail, quickly and cheaply.)
To try to keep up with consumer evolution, retailers need to test ideas in-market, as fast and early as possible. Test across every relevant dimension: merchandising and visual marketing, store design, digital tools, products, services. Think of being agile and iterative; don’t lock ideas in a box for months (or years) of development.

Nordstrom’s Innovation Lab, for example, operates like an in-house retail SWAT team, applying technology to improve customer experience by iteratively testing concepts, apps and new service offerings in single stores before rolling out new programs more broadly.

If this sounds scary, consider recent successes with unbranded test labs, like at JCrew’s Liquor Store, or Starbucks’ 15th Ave Coffee & Tea. This is testing with limited brand risk in case of a flop. The future will take courage: to paraphrase Nordstrom’s Ryan Rosensweig, if you’re not failing from time to time, you’re not trying enough.

3. Infuse service (design and thinking) into every touchpoint. Empower. Enable.
Customer-facing brand representatives need to be a rare breed of experts, armed with the knowledge – and enthusiasm – to converse with customers but not talk over their heads. Get comfortable investing in empowered employees. Take time at hiring to ensure your salesforce has the right background and proper motivation, then arm them with training and tools.

Ziba’s recent work on Reebok’s Fit Hub stores is one good example; Sephora University is another. Investing in the ongoing education of a large, decentralized staff, with training well beyond core offerings, helps ensure engaging delivery. The sort of specialization mentioned earlier will help here, too – a one-staff-fits-all approach doesn’t work in highly bespoke environments. How you’re staffed directly drives the service you can provide at retail, which can be thought of in two ways: what services are you offering, and how are they being delivered?

Service offerings embedded into retail opens opportunities for even more impact, through highly personalized product delivery. Apple’s Genius Bars and in-store theaters turn a purchase experience into an ongoing ownership narrative; without one-on-one counseling, lectures and development workshops, Apple would just be running another electronics store, and not the one with the lowest prices.

Consider JCrew’s Very Personal Stylist service, which offers shopping and fitting advice, along with a host of other conveniences, all on the consumer’s terms: flexible store hours, door-to-door delivery and returns, and detailed recordkeeping of your preferences with no purchase minimums and no added cost.

Define new value with unified, interwoven digital and analog channels, leveraging the strengths of both.

Whither the Future?
These three keys – storytelling, testing and service – should be considered retail fundamentals. The next step? Real omnichannel retail. This is a sore subject for a lot of businesses, because omnichannel got off to a bad start as a complex, stressful must-have. In many cases, ‘omnichannel’ only functioned as a stand-in term for ‘digital,’ but that’s not what it really is, or not all it should be. Omnichannel means seamless experiences that span all consumer channels, physical and digital. And that’s the future.

Sound far-fetched? Consider Apple hiring Angela Ahrendts from Burberry, with her explicit charge to unite online and brick-and-mortar retail offerings at the most valuable brand on Earth. Or think of what Disney has been working toward for years, and now stands to realize, with the recently introduced MagicBand. This personalized, wearable technology takes the place of a ticket and handles in-park payment for food or souvenir purchases, as well as (possibly) allowing Cinderella to spontaneously greet your children by name when they arrive on the steps of her castle. And that’s just for starters: Disney says even wider, deeper integration is coming.

The MagicBand is as close to perfect as seamless integration of digital and physical gets, today. Highly choreographed delivery and a consistent narrative extends everywhere guests look and to everything they touch in person and online, whether they’re planning at home, en route, or in the midst of a visit to the Magic Kingdom. Regardless of who you attribute the idea to – Arthur C. Clarke and Charles Fort are both contenders – the basic premise here is “[a]ny sufficiently advanced technology is indistinguishable from magic.”

Let’s be clear: magic isn’t homogenized or undifferentiated, and “seamless” shouldn’t be, either. Too often, lately, omnichannel has ended up diluted into endless-aisle e-commerce, actually failing to deliver much in the way of experience, and it still represents less than 10% of retail sales. Not all of this retail evolution will be consumer facing, and not all of it will be sexy; it’s going to take a lot of hard work on backend operations to bring that number up, making magic your customers will never really see. They’ll know it’s there, though, when they experience it.

Even behind-the-scenes functions have the capacity to support differentiation. Ship-to-store and now same-day in-store pickup at Walmart is just the tip of the iceberg. How do you feel about Amazon’s latest delivery innovation announcement, Prime Air? Drones are actually perfectly on-brand, for the world’s biggest online retailer; Mr. Bezos and company are also busy automating shipping facilities, along with who knows what else. This kind of fulfilment may be back-end, but it has the potential to become consumer-facing, and either way, it’s unquestionably a part of retail service delivery.

Nordstroms pioneered this kind of tangible/intangible delivery integration many years ago, tying inventory from every channel together and shipping – regardless of point of origin – straight to the customer’s door. This isn’t surprising, given Nordstroms’ dedication to innovation in service, but now Macy’s and even KMart is following suit.

Right now, lots of retailers are scrambling just to keep up, and get digital offerings up to parity with competitors’. Start thinking more broadly about differentiation, and leveraging what makes your story different, your products special, and your services unmistakable. Being a better retailer means telling better stories, and celebrating regional, historical or experiential difference. “I want to design every single Starbucks store differently. When you’re in a crowded market, it allows you to stand out.” says Thom Breslin, Starbucks Design Director. The Boston Globe published research recently indicating increasingly ubiquitous touch-enabled tech – both in-store and on tablets at home – stands to better connect with people currently feeling alienated by clicking a mouse.

Beyond just e-commerce, the future will see digital insights manifested in store environments. This is a good first step toward more engaging, personalized retail experiences. Think about how to harness customer data, and what that information might mean for the services you offer and deliver in store, in the future. Amazon-style predictive product curation is still just a dream for most brick-and-mortar retailers, but an offering of that caliber is going to be nonnegotiable soon.
The omnichannel trend is truly fueled by big data: just right, just for you, right now. More data will means mass customization, whenever and wherever. And that might yield a renaissance for retail: heightened emotions, more discovery, and a return to truly engaging shopping experiences.

Business leaders that grasp this are making meaningful reorganization of their merchandising, marketing and design teams a priority today. Director of Store Design and Visual Merchandising Elizabeth Dowd led a complete overhauled at REI recently, doing away with siloed departments. Now sales, messaging, and product design are fully integrated and working collaboratively.

It’s crucial to maintain perspective on your existing organizational culture, however. If your company isn’t ready to embrace seamless omnichannel, build bridges – or institute a series of smaller, gradual shifts – to support new strategies. This will take more than just securing a budget. Without staffing contingencies and real executive support, in fact, funding for radical design changes can be a recipe for real trouble… most organizations can’t tolerate a Ron-Johnson-level stumble.

Storytelling, whether you’re selling peanuts or whole lifestyles, is the warp to strong delivery’s weft. Put them together and you’ve got the fabric of cross-threaded retail omnichannel. Without a clear sense of narrative, derived from authoritative handling of ownable value propositions, brands today are lost. Making magic will require nuanced attention to everything from messaging, to presentation, to staffing.

Focus on finding your magic, and delivering it with no seams, regardless of channel. Disney seems to think the answer lies in a wearable device; iBeacon indicates similar ideas in Cupertino. Regardless of how things manifest technologically, what omnichannel really means is true integration: physical, digital, and whatever comes next.
______

Author:
Topic: Insights

Flawless Function is Tomorrow’s Great User Experience
Sometimes the biggest upheavals come from the simplest places, like fixing an experience that everyone knows is broken.

The outcome of using a Nest thermostat isn’t really any different from that of thermostats from 50 years ago—despite its sleek, iPod-like appearance and array of sensors, the puck-shaped device is still just a way to control the temperature. Yet its intuitive interface and predictive algorithms have made it, along with Nest’s more recently launched smoke detector, design icons as well as commercial success stories. And they’re not alone. Next wave taxi service Uber, once the domain of tech-savvy San Franciscans, expanded in 2013 into dozens of new cities on three continents, showing urbanites everywhere that hailing a cab can be predictable, civil and comfortable. Even online travel booking has been undergoing a small revolution, with the continued success of Hipmunk, a website that’s been delighting savvy travelers with its comprehensible timeline-style search results, sorted by a “least agony” algorithm that puts travelers’ most desirable flights at the top.

Hipmunk, Uber and Nest are all relatively small companies that managed to shake up very large categories this year, not by introducing a completely new product or service, but by optimizing what was already there. That makes them prime examples of a trend that Ziba identified at the beginning of the year: Flawless Function is Tomorrow’s Great User Experience.

This insight came out of a series of discussions between Ziba’s researchers, analysts and creative directors, which ultimately resulted in an article on FastCoDesign, outlining 12 predictions about design in 2013. Looking back from the tail end of the year, we’ve been able to match up innovation success stories with most of them: the growth of Reddit as a credible information source, for example, bears out the Everyone is a Specialist insight, and the popularity of extreme obstacle runs like Tough Mudder and the Spartan Race reinforces the idea that The Mind is a Competitive Environment, where intentional suffering can co-exist with enjoyment.

There are also some important trends that we didn’t catch, or at least failed to grasp their full impact. The rise of micro-manufacturing and nearshoring, for example, has pushed consumer expectations for unique products to a surprising degree, whether in the hundreds of variations made possible by Nike’s Flyknit process, or the way Motorola and Google differentiated the Moto X smartphone by making it hyper-customizable, and assembling it in Texas, not China. There’s also the surprising counter-trend of people rebelling against all-in-one tech solutions. Single-purpose wearables like the Fitbit and Fuelband, for example, have earned far more consumer attention than smartphone-based fitness apps lately, while limited-access social networks like Snapchat, Tinder and Lulu are stealing some of our attention away from established players like Facebook. This caught a lot of observers, who expected more and more integrated technology, by surprise.

But many of the biggest innovation stories of 2013 aligned in one way or another with those 12 predictions, and it’s useful to see the sometimes surprising ways they played out. Here are a few of our favorites.

Brand Loyalty is How We Escape Decision Fatigue
Subscription services have been around forever, primarily for print and online publications, and less commonly for food, consumables and physical goods. One model that’s really blown up in 2013, though, is the brand-based product subscription service. Birchbox, and its sister site Glossybox, offer monthly deliveries of personal products (men’s grooming and women’s cosmetics, respectively), without specifying what the contents will be. Quarterly.co takes the subscription concept a step further, offering quarterly deliveries of products, picked by a range of curators, including style expert Nina Garcia and Make Magazine founder Mark Frauenfelder, or brands like quirky LA-based Poketo.

What’s remarkable about these services is that they’ve convinced people to lay down serious money—sometimes several hundred dollars a year—for goods that someone else is choosing, which runs counter to the customer-is-in-control mantra we hear so often. The thrill of discovery is part of the appeal, of course, but there’s also the thrill of not having to decide: when you’re bogged down by decision fatigue, latching onto a person or brand whose choices you trust can feel like liberation. Even if you have no use for a box of candy-colored paper straws.

Repair and Repurpose are the Next Killer Apps
The Vamp is a device that resurrects dead speakers, which isn’t as strange as it sounds. Essentially a small, battery-powered amp with Bluetooth reception, the cube-shaped Vamp is designed to sit on top of an old speaker and feed it signals received from your smartphone or laptop. The Vamp’s Kickstarter video features its designer, London-based Paul Cocksedge, professing his love for old, boxy audio gear, and appealing to the hacker and tinker in us all, as well as that jolt of eco-satisfaction we all get when rescuing something from the garbage heap.
Vamp’s Kickstarter campaign has been an unqualified success, raising three times its initial funding goal, and earning extensive coverage in Wired, Core77 and other stalwarts of the design press. It also affirms the insight that an increasing number of people are embracing repair and repurposing, sometimes instead of purchasing new products. To a lesser degree, it also shows the lasting appeal of analog technology, even when it’s driven by digital media.

There’s also the peculiar modern/retro dichotomy that Vamp presents. It’s a totally modern product that relies on recent technologies like Bluetooth and USB charging, but it doesn’t work unless perched on top of another, older piece of technology — preferably one from the ‘70s or ‘80s. Given how comfortable consumers have gotten with supposedly conflicting preferences, though, this shouldn’t be surprising, and makes a strong case that The Mind is a Competitive Environment.

Technology Moves Too Fast to Care About
The Motorola/Google partnership that produced the Moto X smartphone is remarkable for several reasons, including its unique customization interface during ordering, its “always on” voice recognition, and the fact that it’s assembled in the US. But one of its most telling features is a thing it doesn’t have: an ultra-high-res display.

Just three years earlier, Apple wowed the technology world by doubling the resolution on the iPhone 4, calling the result “Retina display.” Digital cameras went through a similar process in the first decade of the century, with manufacturers racing to cram in more and more megapixels, leaving users bewildered and image sizes gargantuan. So when the Moto X was released with a resolution of “only” 1280 × 720 pixels, critics were quick to call it out as a liability when held up to higher-res competitors like the HTC One or Samsung’s Galaxy S4.

The critics may have been surprised that Moto X’s display didn’t seem to impact sales at all, or that when the iPhone 5 came out the following month, it had the same 1280 × 720 resolution. Moto X also drew heat for using dual core processors, dismissed by some as “last year’s technology”, yet reviewers have been quick to point out that actually using the smartphone is a revelation, not because it revs faster, but because so many of its interactive details have been thoughtfully improved. The Moto’s continued robust sales in the face of competition suggest that, for a growing number of consumers, GHz or dpi is like Aaliyah’s age: nothing but a number.

Narrative is a Delivery Vehicle for Making Ideas Stick
J. Crew and Domino’s Pizza may not share many obvious traits, but these two long-established brands have both reinvented themselves over the past couple of years, by infusing their service offerings with a healthy dose of narrative.

J. Crew has been around since the early ‘80s, but entered their current golden age by consciously rejecting the easy-access style that had pigeonholed them as a preppy version of Gap or Banana Republic. Instead of sensible cotton basics, they turned to more idiosyncratic and fashion-forward collections, and a new focus on personal service and relationships. A big part of that move was the Very Personal Stylist service, launched in late 2012, which uses in-store tablets to tell detailed video “stories” about various clothing articles to shoppers, and hooks them up with professionals who can put together an outfit or take care of holiday shopping—all free of charge.

We could soon see branded apps and websites moving away from just providing functionality, and toward telling richer, more personal narratives.

In a less elaborate way, Domino’s “Pizza Tracker” infuses the late-night pizza order with story and personality too. Besides letting customers place their order online, and create Pizza Profiles to shortcut the process, the Tracker graphically charts the progress of your order, tells you exactly what time it left the kitchen, and in some cases even gives you the name of the person who made it. The Tracker also opens up avenues for human interaction, encouraging customers to leave notes for the pizza makers, some of whom develop personal followings. This feeling of being able to chat with the kitchen staff and watch them work is part of the appeal of small, non-chain restaurants; Domino’s has managed to bring it into the most formulaic chain-store food experience imaginable.

In both cases, a formerly generic brand was able to differentiate itself by telling a story that emphasizes human interaction. J. Crew in particular, by tying the in-store digital experience to a living, breathing expert, has invested the moment of purchase decision with a level of empathy that no digital story can match—something we discuss in another insight, Human Interaction Has Never Been More Precious. The fact that both Domino’s and J. Crew did this through a digital medium suggests that we could soon see branded apps and websites moving away from just providing functionality, and toward telling richer, more personal narratives.

Empathy, Experience and Story
If there’s a thread that ties together these insights, it’s this: the triggers that make us care—about goods, services and brands—are shifting. It used to be that a successful brand conveyed authority and reliability (think General Motors or IBM); now it’s about empathy. Technology used to attract us through specs and features; today it has to enable an experience. Even our perception of what makes a product valuable has shifted, to the point where a brand-new sound system or a dress like the one on the magazine cover is actually less desirable than something with a strong story attached. That can take many forms: a revived speaker from the ‘80s, a box of mystery items curated by a favorite brand, or an outfit chosen with the help of a trusted expert. Increasingly, it’s these stories—coupled with basic functionality that’s absolutely dialed in—that win people over in the long run.

For a complete list of the 12 Insights Ziba presented in early 2013, see the article in FastCoDesign. More detailed explanations are in the Perspectives section of the Ziba website.

Art Credit: Bob Gallup, Matthew Baranauskas, Michael Etter


Author:
Topic: Insights

In late 2012, we gathered Ziba’s lead designers, researchers and creative directors together to look back at the year’s most important insights — the crucial discoveries about how consumers behave, technologies change and markets shift. Throughout 2013, we’re sharing one of them each month, through the words and images of the Zibites who know them best.

Constant communication and social media are pushing us to show off our passion and specialized knowledge, as a way of standing out in the storm of mundane information that fills the air. Mom posts photos of Victorian furniture on Pinterest while Dad’s Facebooking his latest cooking project, and your cousin tweets about nothing but Korean pop stars. We’ve always had these secret pools of expertise, but now they’ve got an outlet, and an appreciative audience.

You’re a specialist too.

Trying to be everything to everyone is a losing proposition. As customers embrace their connoisseurship, they seek out brands that match it. The success stories of 2013 are companies unafraid of putting a stake in the ground, to boldly indicate where their expertise and passion lie…and where they don’t.