Posted: September 21st, 2010    By:    0 comments

The Joy of Print: Part Deux

Today we got a simple brown package from one of our clients. Inside were four hand-addressed envelopes to Matthew, Lindsay, Matt and I. Inside those envelopes were handwritten letters from our client, thanking us for the workshop we did with them last week. As you can see from Matt’s face, we were delighted. Real mail! At work!

It got me thinking about my thesis research on how technology can impact well-being. How can the joys of print be incorporated into the digital setting? A few thoughts/design patterns:

1. The timing of the letters was perfect. Not too soon, not too late. Technology has a reputation of making things faster, but perhaps it loses that magic timing. Choosing when an email gets sent or being reminded about a meeting hardly qualify as “magic timing”…

2. The personalized nature of the cards made us feel special. So how can technologies really be personal (not just demographic or data-based)? I think when we all start building our own networked devices with something like arduino (the lego of the networked-world) we might get a bit closer to making each other feel special through technology. 

3. The tactile quality of the card meant that I could carry it with me, and separate it in physical space from the rest of the package and everyone else’s cards. Perhaps, in the future, we will create technologies that can provide useful information, and change shapes. More than just holding an iPhone in the palm of your hand, you should be able to grab a physical piece of “data” from a larger container and take it with you. Imagine a “mailbox” full of actual digital pieces of mail (each of them smaller than an ipad!) that you could separate out and carry with you. Then you would just put them back into the “mailbox” you have at home and access them from anywhere again later.

Ok, so that one’s a bit crazy… Neal Stephenson’s Snow Crash sci-fi must be influencing my brain already!

0 comments

Posted: September 20th, 2010    By:    0 comments

(@elledog)

I realized something yesterday: at some point over the past year or so, we stopped making client presentations (that’s a PPT deck in a hotel lobby I was in recently). I don’t mean we stopped sharing ideas, content, outputs, deliverables, but we don’t really do “presentations” like we used to, instead we share insights and facilitate activities.

Last week four of us facilitated, and participated in, what’s become a regular activity for us: the persona workshop (in that same hotel). Because much of what we deliver are tools meant to be used in the practice of design, the presentation format just doesn’t work. The introduction of design tools to client teams versus documentation presents an inherent need to demonstrate how to use the tools, and thus, makes everyone part of the design process.

In this particular instance, we did a scenario design activity to get team members excited about, and using, personas. In teams, participants had to design a future scenario by acting it out and role playing with their persona at centre stage. Also known as bodystorming, this activity got participants out of their chairs, thinking like the customer, and testing ideas to see if they might work in the “real” world.

But it wasn’t the final scenarios that were most valuable in all of this. I was so happy when one of our clients commented that it was really time spent working out the design of the scenario, having conversations, reviewing persona details, drafting ideas, throwing them out, testing ideas by bodystorming and realizing they don’t work (or that they do) that is critical. The upfront time spent “designing” the scenario is like a microcosmic design process the group goes participates in to come to a good future scenario to be presented to the group. This is the activity of prototyping. Here are some of the elements that made this a success:

  • the brief: what is the “problem” you are trying to solve?
  • the teams: multi-disciplinary groups of people dedicated to “solving” the problem
  • the environment: the right tools, defined space to work in, good lighting, time constraints, work table
  • permission: participation of senior level management

Give people tools and they will create!

0 comments

Posted: September 15th, 2010    By:    0 comments

The Joy of Print


We just got the print proof for Normative Design and Torch Innovation’s first Design Research: Methods, Techniques, Outputs deck. This set is specific to Customer Research, and in the future we’re going to expand the deck to include Business Research and Competitive Research. The Customer Research deck is inspired by our practices at Normative Design, and includes 9 Methods (from In-depth Interviewing to Adventure Research), 8 techniques (including Active Listening and Team Facilitation), and 5 outputs (from Personas to Mental Models). Email me at ayla@normativedesign.com if you’d like to order a copy of this deck or the whole deck!

It’s pretty exciting to get something printed again, after spending a lot of my time learning about things like python, web analytics, interaction design patterns and photoshop effects. I think the rest of the office was pretty thrilled too. In a time when everyone seems determined to rid the world of the printed page, there is still something kind of magical about the physicality of print design. When you create a digital design file for web and devices, it goes through a process whereby it changes shape and style to conform to another digital format, but ultimately, it stays on a screen. With print, your file leaves your computer and your hands, and enters a (somewhat magical) machine – a technology in its own right – that transforms it into something you can touch and hold. I know, I know, you can touch and hold an iPad or a mouse. But for me, there’s nothing quite like the tangible texture of a fresh print job.

0 comments

Posted: September 10th, 2010    By:    0 comments

True hypertext narrative… Finally.

(@emenel)

Since the first days of the web people have been talking about hypertext narrative – the ability to tell stories using nonlinear text, linked together and organized through the power of HTML. 

In the mid 90′s there were many experiments in hypertext storytelling. Authors and artists tested methods of single-author nonlinear work, multi-author writing, and participatory storytelling like MUDs and MOOs among other things. We saw a proliferation of CD-ROM games that were highly narrative like the work of LucasArts (Monkey Island, Day of the Tentacle, Sam and Max, etc).

Lots of interesting and entertaining work came out of that era, but the technology and user base weren’t mature enough to truly realize the potential of hypertext media for storytelling. Those early experiments led to a deep understanding of nonlinear stories, which we can see manifest in massive video games like Fallout – games that tell a cohesive character driven story while still allowing the player freedom to explore and perform actions in their own way.

While gaming matured and learned how to tell better stories in interactive and nonlinear ways, traditional written storytelling has never really found it’s footing in new media. A few authors have tried with varied success, but it never really took off.

Now, almost 15 years after many of the early online hypertext narrative experiments, we have a real candidate for making this successful. Neal Stephenson and a group of other writers and artists have started a hypertext novel called The Mongoliad.

Their approach to this is really interesting in a number of ways:

  • A new publishing platform – As part of this experiment they are trying to test a new episodic publishing platform. Each week a new official chapter comes out, written by Stephenson and/or the other writers involved. These are official releases and considered part of the canon of the work.
  • Multimedia content – simultaneous to the production of written work other artists involved with the project will create illustrations, maps, and other media to compliment the written story.
  • A wiki – Along with the official story there is a member editable wiki. This is meant to allow people the freedom to add to the world of the story and as a place for the “official” writers to add back story, concepts, and supporting materials. The wiki entries can be linked to form the official chapters, creating entry points into the larger world of the story.
  • Member contributed content – Any content contributed by members can be adopted into the official canon. This adds an elements of peer production to the process.
  • It’s not free – in order to gain access to the new chapters as they’re written, and be able to contribute, you have to pay for a subscription. This in tern funds the production.

A lot of attempts at hypertext fiction, especially peer produced fiction, have been completely open or completely closed. Both of those pose problems for the longevity and focus of the work. The Mongoliad is experimenting with a hybrid approach, all official content is produced by the authors, but every member has the opportunity to add to or influence the work.

I got my subscription last week and am currently reading through the first chapter and the associated wiki pages. It’s an incredibly interesting approach, and I’m eager to see how it progresses, and what comes out of it.

Check it out: http://mongoliad.com/

0 comments

Posted: August 31st, 2010    By:    0 comments

Balancing Risk vs. Reward in Gameplay

(@jpmcardle)

That electric shock of in-game excitement you feel when nailing a headshot in Half Life, harassing an opponent early in Starcraft, or finally getting that Tetris you’ve been building towards?  Chances are that experience was bourne out of a contentious internal battle over in-game risks versus rewards.

Like every product has a bit of it’s own story embedded in its essence, every one of these examples helps each player internalize a narrative.  This narrative effectively bridges the gap between the virtual world and the “real world” (or meatspace, IRL, or whatever you’d like to call it!), and provides built in word of mouth marketing.  How many times have you heard a friend excitedly relate their latest video game war story, trying to get you to play?

The balance of risk vs reward is tough to strike, but absolutely crucial for almost any game to be successful.  A headshot provides maximum virtual damage for minimum effort, but requires a high degree of skill to achieve.  Starcraft strikes a similar balance;  if an opponent has the right counters to your plan, you’re likely to be at a huge disadvantage if it fails.  If it succeeds, you are likely to have the upper hand tactically and strategically.

These are but two examples, but this element is prevalent in single player games as well, particularly in those that utilize leaderboards or other means of tracking high scores.  A game like Ikaruga, whose delicate dance through bullet hell is a constant balance of survival and the technical pursuit of a high score is a perfect example.

In fact, risk vs reward is a core element of almost any game you can think of, transcending video games, board games, and games we played as children on the schoolyard.  If you’re creating a game, it’s absolutely integral to the success or failure of your product.

So how do the very best in the industry achieve a compelling balance?

They iterate and test.  Constantly.

The stories are myriad.  Hideo Kojima’s novel approach of building levels for the Metal Gear series in LEGO and “playing” through them in a turn based manner, (all the while videotaping the whole process as a design artifact) ensured a constant game of cat and mouse between Snake and the veritable army of soldiers charged with stopping him.  LEGO might not be the medium you first expect for rapid-prototyping gameplay elements, but it’s modular nature allowed for extremely quick reworkings of levels before they were brought into the virtual world for construction.

Valve Software builds whole sets of levels in a scope similar to an Act in a movie, but doesn’t add art assets until much later in the project.  This allows the modelling and texture teams to iterate while the level design is evaluated from a pure gameplay standpoint, without the “distractions” of final game assets.  It also allows the quick experimentation with original enemy and gameplay types, which is one of the main differentiators of their product versus their competitors’.

The original Starcraft had a public beta that was originally supposed to last for 1 month.  When Blizzard finally launched the beta (a few months later than originally announced), it ran for 9 months instead of just 1. Throughout this beta, almost every unit in the game received tweaks to various attributes, and some were excised entirely.  Not many of us are in a position to launch our products 9 months later than expected, but Blizzard’s intensive approach to balancing the risk and reward inherent in the game resulted in the most widely played competitive video game in history,  one that was played professionally for over 10 years and kickstarted a nascent competitive gaming industry.

What can we learn from these experts? All of these companies, and many others, undertake immense efforts to ensure the balance of risk versus reward.  It’s not something that comes easily to them.  Even they don’t get it right at product launch, but it’s often 95% there.

Many of us working to create compelling digital experiences have a lifetime of gaming influencing us, and as more and more clients and products require the inclusion of gameplay, we feel the pressure to include them in our designs.

Some have gone so far as to create idea decks of gameplay elements, as if a list of buzzwords considered individually can make you a compelling product.  We all saw how well that approach worked around 2000 or so… why do we think it will work now?

Delivering a truly compelling balance of risk versus reward is not easy.  Like much  digital design work, it requires constant back and forth, many iterations and a good deal of analysis.  It’s messy.  It won’t happen overnight.  It’s a skill that needs development over time, and often won’t be 100% right, even after launch.  Balancing risk vs reward is a marathon, not a sprint.

 

0 comments