hooked by Nir EyalNir Eyal’s Hooked: How to Build Habit Forming Products is perhaps one of the best books on User Experience and how to design for it available today. Not only does it cast light on the reasons that designers can use these mechanisms to influence action, it’s a handbook for how to develop these products, with an ethics-centered point of view that doesn’t proselytize. Anyway, accolades aside, what lessons can we take away from this book?

Variable Rewards

Before I had picked up this book, I found myself studying how User Experience design and Game design overlap. I was playing this game Crossy Road on my tablet, and found myself hooked. At the non-insightful level, I would have said “the gameplay was simple and addictive.” The barrier to beginning a new level is incredibly low; advertisement/monetization was brought in through a rather unique mechanism. You watch ads to get coins, which allow you to buy new characters. I saw that as being incredibly valuable, as it seemed to ensure that if you played an ad, you’ve taken the action, and therefore are more likely to watch it. You form an identity of yourself as someone who watches ads for fake currency. Or in my case, you play and play, gathering a dearth of coins spread out upon the course, or you wait for your six-hour bonus.

Yes, every six hours of real-world time, you would get a “free gift” from the game. You would get a seemingly random amount of in-game currency. Sometimes you’d get 90 coins— not enough to get a new character; other times you might get 450— more than enough for four characters.  I found myself looking forward to this. Or as Nir Eyal says, “variable reward systems must satisfy users’ needs, while leaving them wanting to re-engage.” (page 94)

As designers become more adept at utilizing techniques of “hooking” users, we may see more games which provide a better in-game user experience (hey! look at how few ads there are!) while working the long con in terms of creating habitual, long term users.

Crossy Road was tapping into a need for novelty and variability (page 94), rewards of the hunt (page 79), wherein I felt the need to “catch them all” (a couple can only be obtained via purchase), and I was driven to beat my high score, the reward of the self (page 81). As I stepped back and looked at what this game was doing, it was a incredibly sophisticated bundle of techniques designed to hook a user.

I could satisfy these compulsions, once instilled in me, through purchase, providing an effective monetization scheme. It certainly seemed that some of the techniques were outwardly borrowed from the world of video gambling (page 80).

However, you may be saying that this seems kind of obvious. Yes, many Zynga games pioneered this same technique (page 92); however, what I found most interesting was how conspicuously buried the monetization elements were. It’s possible to have a nearly entirely ad-free experience. Cross Road’s pitch isn’t one of making money, as much as it is about systematically creating habits which money can substitute for. It’s more sophisticated in its subtlety than other games. As designers become more adept at utilizing techniques of “hooking” users, we may see more games which provide a better in-game user experience (hey! look at how few ads there are!) while working the long con in terms of creating habitual, long term users.

 Hooking with Ethics

And that’s why I really like the model that is posited for helping designers, creators, and visionaries to see the impact of using the model. How do you know when you’re getting someone hooked if you’re operating in good or bad faith?

From: http://www.nirandfar.com/2012/07/the-art-of-manipulation.html

From: http://www.nirandfar.com/2012/07/the-art-of-manipulation.html

“With Great power comes great responsibility.” Is Crossy Road materially improving my life? Not quite. So are the designers my Entertainer or my Dealer?

I suppose the point isn’t to judge the makers of Crossy Road. I don’t buy characters, and I don’t even click the ads. I’ll take what they give me for free, so I think in terms of how it affects my life, it’s guilt free.

But as the maker, we shouldn’t necessarily be judged by our own, as much as we wish for others. I think this model, while not necessarily the be-all end-all, offers us a shorthand framework for gauging the ethical considerations of using these methodologies in our product.



The Art of Game Design (i)

the-art-of-game-design-1Schell’s The Art of Game Design is not designed to be a User Experience design text.  But it is designed to be a user experience design text. It’s about designing experiences within the game realm, but unlike many other foundational texts in contemporary user experience design which ground themselves in the web and product, Schell grounds us in the broadest terms from the book’s first pages.

What Skills does a Game Designer Need?

A heady and incredibly broad question. Many first-time User Experience designers, those new to the craft delve right into the nitty gritty of wireframing. Of product design. Very few [especially in interviews! shockingly few] recognize that whatever their background [I have a Bachelor’s in some non-UX field; my hobby is totally unrelated] it probably has taught them something about experience; that is if they’re astute and practice listening (p. 5)

For an introduction to Game Design, let me list the skills that Schell describes as being helpful, beneficial, and to some degree, even required to make a good game:

By calling them to mind in the first 10 pages, Schell reminds the reader that Game design, as in all experience design, requires a sound understanding of a vast range of disciplines.

Animation, Anthropology, Architecture, Brainstorming, Business, Cinematography, Communication, Creative Writing, Economics, Engineering, Games, History, Management, Mathematics, Music, Psychology, Public Speaking, Sound Design, Technical Writing and Visual Arts (p 3-4).

By calling them to mind in the first 10 pages, Schell reminds the reader that Game design, as in all experience design, requires a sound understanding of a vast range of disciplines. Like a Victorian era naturalist, who must combine knowledge of several scientific disciplines; or a true polymath, the Designer [notice dropping the prefix] must have a diverse breadth of expertise, but also know enough to know what they don’t know.

the Designer must have a diverse breadth of expertise, but also know enough to know what they don’t know.

A rare reminder that in a world where we see the web professions increasingly credentialed [how many thirty-something web professionals went to school for what they do now? contrast that with today’s 20-somethings….] that User Experience design knows no single best happy path. Well other than an appetite to continue learning and well, listening. But


Rocket Surgery Made Easy

rocketsurgery_largeExpectations are high when one of the iconic names in UX puts out a book expectations are high. Don’t Make Me Think is rightfully considered essential reading among UX designers. But his work Rocket Surgery Made Easy tackles a topic more apt for a screed than a highly engaging manual; however, whereas it might have been essential in 2009, a lot of Krug’s advice is now commonplace enough to be mundane among practicing professionals. Shall we review anyway?


We’ve already talked about Gothelf’s Lean UX, but the premise of Krug’s 2009 work is essentially the same. Test at regular intervals, and test narrowly. Test to identify the biggest problems. Surely a wide-ranging test of hundreds will identify as closely as one can all the problems. In all truth, rarely does a budget exist to support that sort of test. Similarly, that sort of “all eggs in one basket” sort of text jives more-so with the waterfall method of software development, which is hopelessly out of style [and for good reasons, truth be told] in software shops.

Ever budget sensitive, Krug even suggests testing arrangements for any price. Find some free software? 3 users? Boom. The point is clear: budget shouldn’t preclude you from doing user testing. Important advice [and well told] for those who work in UX at non-profits and the like.

As I said, not revolutionary today, but the advice is still sound.

“We’re doing it Live”

Krug’s books have been around for my entire career. And having done a large number of usability tests, much of his advice and scripting seems redundant. Almost tedious; however, I think there’s an important reminder/lesson in there for those of us that aren’t new to this. He reminds us of the impact of words; the interpretations of our statements. I found myself considering that perhaps there is some merit to sticking more closely to parts of his script. Though honestly, I find they suffer from a made to read rather than be read aloud. When you’re on the listening side, they can be over-long and tedious. Again, I found myself taking aspects and refining my language; not wholesale lifting his test introduction

Brain Science Made Easy…

If you’re new to the profession, Krug offers a hard-to-fail-at checklist to ensure you make a good test happen. It’s entirely lean and a natural fit for the agile processes. For experienced professionals, its a helpful set of reminders that comes with a familiar feel-good-name attached to it.


The Glass Cage

The Glass cageConsideration of how a product makes a person is a critical part of what user experience can bring to a project; however, Nicholas Carr’s The Glass Cage offered a source of insight into some surprising results of a recent set of interviews.

First the Project

Staff members historically were tasked with planning a complex event. It involved many different people, diverse needs, rigid time structures, and with so many moving parts, the actual day of the event was fraught with stressors galore. The time that went into planning these events; the stress they caused; and the need for the participants to have a good outcome caused the business to identify it as a place where we could help people.

Automation of the arrangement [taking all the variables into account], was identified early on as a potential solution to the needs we clearly heard and identified during the research portion. However, when we tested it, the automation functionality was viewed with skepticism and alarm. Some other factor seemed at play behind the reactions.

…and now the People

During our interviews, we consistently heard how “proud,” users were of coordinating such an elaborate event. Many identified it as one of the most important functions they performed. This event required creativity, agility, and quick thinking. Our users may have found it frustrating, but probing deeper, they also found this task to be a core part of their identity at work. This was what they did, and pulling it off gave them great satisfaction. Our initial designs concepts would have certainly saved them time, but at what cost? The cost was human.

This is the tension posed by automation, and the tension that Nicholas Carr elucidates in his book.

Automation and people

Carr points out the tension of airline security vs. the role of pilots. Most planes can be safely flown with nearly no interaction from the pilot. During this period of increased automation, Pilots have self-reported decreases in their skill-sets (page 64); however the cost of this has been great in terms of the human and emotional.

“But pilots’ self interest, when it comes to matters of automation, goes deeper than employment security and pay, or even their own safety. Every technological advance alters the work they do and the role they play, and that in turn changes how they view themselves and how others see them…Am I the master of the machine or its servant? Am I an agent, or an object” [page 65]

Certainly in the realm of air travel, automation has made things safer and more efficient. The intention isn’t to be a Luddite, and suggest that progress, change, and efficiencies are not important things to work for. The lesson flying has for us as practitioners of user experience is to consider the ways that [especially when designing business applications] that work/self worth are internalized in the execution of a task or the use of a tool.

Certainly Human-Factors studies have long advocated for designing from a user’s capabilities outward (page 167), such as game designers have (page 181-2) whereby a program can develop a user’s skill in a certain area by operating at the periphery of their ability. The program challenges them to think, and we gain by developing a skilled, motivated and most importantly (especially for airlines) engaged user.


In short, taking the lessons and cautions from the research we were able to design an experience which combined elements of game-thinking while challenging them to think creatively  about how to plan out the day. The interface is easy to use “out of the box,” supporting a novice user in rapidly putting together a schedule by surfacing the right information; however, we left the user in control of the ultimate schedule of events.

The business was able to see efficiencies in terms of a reduction of a time planning these events; common event day stressors can be handled manually or automatically depending on the user’s real life proficiencies in solving these challenges. We managed a tool which let the user remain in control of the machine; while allowing the machine to reduce the cognitive load during critical junctures in executing these events.

Nicholas Carr’s lesson for UX designers was well-heeded.


About Face (ii)

About FaceOften a subtle tension emerges over the course of a product. When your User Experience team manages both the business analyst hat and the interaction design, these concerns can often be smoothed over as a result of the UX process. Other times, these needs come to be represented by two different teams.

It’s important to note that this dichotomy is false; good UX “hits the sweet spot,” and creates products which meet both needs seamlessly. However, that being said, often times the business stakeholders and business goals have a seat at the table; rarely does the user’s. So certain goals are often easier to be met, since a business stakeholder is present and their subconscious goals manifest in terms of “gut feelings,” reactions, or other thoughts/actions. The user’s subconscious [but equally as important in a successful product!] are not well represented.

While we can suss out these reactions through proper testing, it’s important for research teams to have an orientation towards understanding these often unstated goals early in the discovery process. Cooper’s About Face presents a nice orientation towards how we can ensure that we discover enough to represent these internal, and often, subliminal tendencies that affect a user’s perception of a product.

Types of Goals

Experience goals like “having fun,” “remain focused,” and “feel smart or in control” (page 92) can be assumed. We don’t often need to probe this during our research phase. How often does a user want to feel distracted and stupid? Donald Norman did a great job in his works of illustrating how destructive these emotional states can be when unintentionally designed into a product, so I wont’ go too far into these. These can be assumed. These are the gut feelings that UX researchers can express early and often, and rarely be wrong.

The next type of goal is the one that we most often research towards understanding: End Goals (page 93). If we don’t know why a person would pick up our product, how can we find the sweet spot? In short, these are the ones I think the UX profession does the best job of picking out.

Finally, I wanted to talk a bit about the type of goal that is the hardest to represent, but at the same time might be the most important (page 93-4). A person might use Instagram to upload a photo. Uploading a photo to share with friends is the end goal; we know how they want to feel when performing that action. But what is the real goal? What is the “Life Goal” that drives their choice to participate in this social network?

Tools that can tap into this are going to be most successful: they don’t rely on a user to understand the product to formulate a motivation. They don’t rely as heavily on branding/visual appearance to invite them further. Simply put, a product which appeals to one’s life goals intrinsically creates motivation and investment (94).

Working with Life Goals

Cooper offers some suggestions for how to uncover these powerful motivations. “Ethnographic research and cultural modeling are critical for discovering users’ behavior patterns and deeper motivations.” I find that often these sort of things can only be uncovered through extensive face-to-face interactions, with contextual interviewing being the most powerful and most accessible. Without the environment, clues and evidence that might lead you to understanding how the thoughts, words, and goals might be lost.

Additionally, they’re rarely spoken aloud. These sort of goals often operate slightly below the liminal for a lot of us. I want to upload a photo to Instagram because I like to share with people, but perhaps I’m uploading because it helps me give meaning to my life and see a narrative of meaningful moments*.

These goals often explain or support user goals, which are often developed in tight nexus with the business goals. However, although these are often harder to determine and easier to leave out, I find that when looking at a holistic experience [a la a user journey or user user experience map exercise]. it’s vital to do some research around these and attempt to understand the grander motivations that might support or work against your product.

Organizations have Life Goals too

Although often not stated outright, when looking at a series of business goals I think its vital to try and understand the unspoken “life goals” of an organization. An organization may say things like “provide support to x group;” however, the life goal often remains concealed or unspoken. When we create support, what might we want to do? Create an evangelical army for our product, who uncompensated will share with others. Maybe that’s your spoken team goal. Perhaps there’s something below that even further. I think that there’s a nexus of “life goals” for both user and organization, that are implied, but often obscured when looking only at the traditional business goal and user goal orientations.

*For example, this is not based on research. I’m just illustrating the type of “life goal” we are talking about, and perhaps giving an example for why it might operate below our conscious.



Microinteractions (ii)

microinteractions by Dan SafferAs we are halfway through the year that thinkers and technology prognosticators thought would be the year of “Wearable Tech,” it seems like an appropriate time to review, but in particular reflecting on a key facet of the technology through a Microinteraction lens.

The value of wearable

One of the largest untapped ways a technology can engage us with more information is through the senses. Audible interactions are often helpful, but only for systems which have speakers attached to then. Visual interactions are clearly among the most important.The tactile quality of an interface can affect the way we interact with it as well; but where wearable technology has a vast untapped potential is through its contact with our skin. This enables device makers to make use of haptic feedback in a way that has never quite been possible before.

The limits

The universal example is the cell phone set to vibrate in one’s pocket. How often does a call get missed because you did not feel it vibrating?

Even more than vision and hearing, our sense of touch (technically our cutaneous sense) is limited. Not by our skin, which is extensive…but by our brains. (page 132)

Simply put, the great reservoir that wearable technology is set to open up to interaction designers, isn’t so great. If its level of precision is only 1% that of hearing or we are only able to process somewhere between three and four different levels of vibration (page 132), does wearable actually open up anything new? In other words, is the inherent value of the medium such that it actually presents an upgrade to existing technology? If there isn’t much information that can be added by the introduction of the wearable part of the device, it remains to be seen if the act of wearing alone is enough to encourage adoption.

…is the inherent value of the medium such that it actually presents an upgrade to existing technology?

If the interface itself doesn’t prevent a novel addition (opening up a new sense in a meaningful way for interaction), then the device itself has to compete as an equal against existing devices on those same merits. Does a wearable watch with a small screen meet your needs/expectations for the medium?

Samsung's 2013 Wearable Watch

Samsung’s 2013 Wearable Watch

To take it another way, is the constant availability and present interface enough to change the ways we use our devices. Think abut the culture of in-person interaction that our phones have become involved in. Putting your phone face down on the table says “I’m waiting but you have my attention.” Face-up says something different, as does putting it back in your bag. Does a watch fit this mode? And can it change these interactions [or resist them?] if it doesn’t add some novel value?

Stephen Balaban wearing Google Glass in 2013

Stephen Balaban wearing Google Glass in 2013

And Google Glass sits on the other side of the spectrum: as a wearable it engages the visual sense while adding the ability [potentially] for haptic feedback. Though the innovation isn’t truly in the ‘wearable’ part as it is in the situation, and it isn’t in the haptic as much as it is the visual. The latter perhaps being an example of how wearable can tap into our senses in new way to add value to an existing product; the former is perhaps an example of a product where the new interaction value might not be enough to encourage adoption.


Bringing it back home, it seems clear that wearables open up a new sense for use by interaction designers. As of right now, how to use them aside from the fairly narrow range of use cases traditionally seen is not certain. Saffer suggests interaction designers limit them to accompanying a physical interaction; alerts only when audio is unavailable and; to add texture in the rare cases where it might be needed to limit an interaction (page 132).

Why do the blind have a more refined/precise sense of touch when compared to non-visually impaired people? Practice

I think Saffer might be not doing justice to the long term future of the medium. Though I agree in the short term it is wise to stick to best practices, I think that as these devices proliferate designers will experiment with them. Just as the touch screen radically transformed our notion of best practices for user’s gestures as for interaction, the bold of us will find ways to add value and impart information through the newfound proximity of device and skin.

I’ll leave on this final piece of hope for the use of haptics and a word on why that 1% or 3-4 might be moot in ten years. Why do the blind have a more refined/precise sense of touch when compared to non-visually impaired people? Practice [so says this 2011 journal article from McMaster University].

In short, I believe the more prevalent wearables become; the more we experience the average person will have with haptic feedback. More designers will begin experimenting with it, and the fidelity of the average user’s haptic recognition skills will improve.

 2014 will likely not be the year of the wearable (sorry Samsung), but I do believe that there’s a better chance 2024 might be.

So in short, I’m making a bold prognostication of my own. It’s a long road for wearables to capitalize on this new sense. 2014 will likely not be the year of the wearable (sorry Samsung), but I do believe that there’s a better chance 2024 might be.


About Face (i)

About FacePerhaps one of the most striking recommendations in Cooper’s quintessential textbook on the topic of Interaction Design is the one that might be the most challenging for those of us who have been in the profession for a long time.

A powerful tool in the early stages of developing scenarios is to pretend the interface is magic.

Why it’s right

Being untethered by restrictions and constraints is necessary to come up with novel solutions to interaction problems. As we’ve talked previously on the book club, a user’s mental model rarely aligns with the technical reality of the situation. Elegant interaction design can tap into this, facilitating a friction-free experience for the user. When friction is reduced and tension between a user’s understanding and interface’s function are reduced, we can begin to develop for joy, surprise, delight, and other of the loftier goals.

Why it’s hard

Technical requirements often can constrain our thinking as designers. Our mental models can be affected and constrained by knowledge/experience of what may be correct. How many times have you toiled away on a product, only to have the new person come in and immediately see a way out of a design conundrum that’s stumped you, or to offer a simple, even more elegant solution to something you thought you already had figured out? It’s not just that those new designers are incredibly talented and sharp. It’s that having an outside perspective sometimes enables us to more freely suggest a “truly novel” (page 160) solution.

To think about things in a true tabla rasa, with no restriction is to think about world building as a fiction writer might. How would the ideal society go about doing this? Fiction writers have an easier go of it, simply because if their magic systems are unexplainable, or their methods for propelling a spacecraft faster than light are based on specious reasoning, no one’s going to hold them responsible for that. It’s fiction after all.

We’re not developing fiction. Out solutions must be feasible and technically implementable. One thing I have to be consciously aware of is how a) my experience in developing back ends [oh so far ago!] and b) my 10+ years of pitching solutions for backends sometimes causes me to consider prior limitations earlier in the process than I should. Pitching a solution for Drupal? worked with Drupal before? It definitely requires a sort of mindfulness to get back to the magic and put these things away.

All planning is implementation – Urban Planning School

It certainly can be a challenge, and it’s a tension that experienced user experience designers must navigate in their work. It’s an asset when we have a familiarity with the technology so that we can have meaningful conversations with partners on a project: we can collaborate to mitigate technical limitations and come to better solutions. But sometimes, we need to put the negotiation and implementation part of a project away for a second. Surely “all planning is implementation,” and one without the other is not either or. We should not lose sight of the importance of not caring about the plausibility of a solution, when brainstorming. Sometimes to capture the magic, we must not try to understand the magic.


Lean UX (ii)

Lean UX

Design by Consensus.

Although Lean UX doesn’t call it out specifically, there’s moments where the recommendations seem to skew a little bit in the direction of this ineffective practice.

Gothelf and Seiden call this out specifically “Lean UX is a collaborative process…but it’s not design-by-committee”  (page 33). I feel though the process outlined demonstrates an effective way for involving all participants in the design process, they gloss over the difference between “consensus,” “committee” and “collaboration.”

In consensus/committee models, the mode of decision making is “all participants must agree on the solution.” The risks to this are many: the loudest voices tend to win [and often loudest correlates directly with power, years experience]; it tends to produce conservative, status-quo solutions; it subordinates the role of ‘design’ to merely organizing elements on the page [which is not design].

Collaboration models involve divergent voices and allows them to be heard. It gives the designer a great deal of input to work with, but ultimately the designer must make sense of all of these loose ends to create a coherent and consistent product. The big difference in the collaborative design model is that the designer, as the leader, must negotiate the conflict inherent in this process: not everyone’s work will get built. “Feeling heard” is important and creates the model of trust, transparency, and inclusion that Gothelf and Seiden frequently reference. What Lean UX doesn’t go into is how you negotiate the process of working from a collaborative process. What happens when you don’t include the tech lead’s design suggestion? What about the project manager who felt like since a common element emerged on six of the eight activity sheets, that she felt that was what you were going to do?

This is hardly to say that a designer should revert to the ‘hero model’ of design, but I don’t think Lean UX gives the practitioner a helpful framework for navigating what can be very dangerous waters. The process outlined veers a little too close to Design-by-Committee and the text itself becomes a little too “buzz worthy.” Managers and the like might really love the inclusive, collaborative, team-building nature of the process outlined, but designers might find themselves asking “how do I take this methodology forward.” I’m not sure Lean UX necessarily posits an answer here, as Gothelf and Seiden seem more invested in their concept at this point.

I’d suggest the Team Idea Generation step (page 41) be somewhat scaled back a bit. Having the team decide which features to the parking lot, or deciding what ends up in the MVP feels a bit too much like design-by-consensus. The authors even say “to get a consensus, the team will need to prioritize and pare back features.” They start with collaboration and end with consensus.

I’d suggest scaling this part back. Using the terminology suggested, or using the outputs directly in the prototyping process perhaps improperly applies finality to the decisions you make in the process. Don’t ask the team to create a final solution. Let the individual concepts be the end. Talk about the decisions that were made, but instead of trying to piece them together, use tools from your ethnographic methodologies. “Why” and “How” is this a good solution, rather than, “do we agree this is a good solution.” Allowing the team to categorize and prioritize might increase investment, but I think it causes two other unintended side effects: Firstly, the end product is not the result of a cohesive vision of summative understanding of how solutions answer design questions. It’s simply summative. Secondly, this causes your designer to feel somewhat less-invested and less-critical to the process. UX designers must be good facilitators. Certainly. But the value a good designer adds to the process is more than simply aggregating outcomes.

Elderly community members wanted some quiet space; younger kids wanted a skate park: to the community these goals were mutually incompatible. To the designer? These weren’t. Consensus would never have come up with a solution which included both.

This isn’t to criticize collaborative design. Certainly in my time as an urban planner, design charettes were incredibly valuable activities which allowed people not involved in architecture or local governance to articulate clearly what sorts of change they would like to see for themselves and their community. However, consensus rarely emerged from these meetings, because folks with differing hopes and goals rarely can see how all of their needs can coexist.

Take a park for example. Elderly Community Members wanted some quiet space; younger kids wanted a skate park: to the community these goals were mutually incompatible. To the designer? These weren’t. Consensus would never have come up with a solution which included both.




Lean UX (i)

Lean UXFrom the “must read” files, filed under “buzzworthy” and “trending” is Gothelf and Seiden’s work on Lean UX, which posits that UX designers, with a few adjustments to their craft, can work in harmony with the agile philosophy that is all the rage amongst development teams. You know this is more than a fading trend,  when even the esteemed Nielsen Norman Group weighed in on agile UX last week.



I think we can all get behind the declaration that we should ‘get out of the deliverables business’ (page 12). Right?

I don’t think this is a revelation of any sort, the profession has been mired in this tension since the roles of “visual designer” and “user experience designer” diverged. Although document themselves don’t solve business problems, they do maintain their sway over UX developers [and even myself at times!]. Well-crafted UX deliverables are absolutely imperative to one’s career trajectory. The UX portfolio is a time-honored piece of one’s application: for right or wrong, although we design to support behavior, the word ‘design’ carries with it some other baggage.

To be fair, Gothelf and Seiden do point out this tension in the introduction (page XV), but until the craft transforms sufficiently, I’m not sure we can simply suggest that a UX designer commit “career suicide” in the name of Lean UX. Snappy visual representations are probably not going anywhere. While these sort of deliverables might help you achieve [the much maligned, and often pejoratively referred to] ‘rock-star’ status (page 10), we should be careful to choose the right deliverable to match the right design problem. Not every design problem is an opportunity to complete the portfolio bingo card.

UX Rockstar bingo card


101 Things I Learned in Architecture School (iii)

101 things I learned in architecture schoolAmong the potential lessons for UX [and designers in general] from Architecture is the way that the impact of spaces can differ from the impact of the whole.

For example take a building. Does the emotional impact of a corridor necessarily need to match the grandeur of its exterior? Can a grand cathedral have a humble entryway? Let’s take the emotional requirements for a banking website into consideration. Perhaps its exterior needs to convey a message of “authority”, to instill a sense of “security.” But quite counter to that, the daily user of the site wants to feel something “safe,” but “friendly” and ‘warm.” Could a banking website project the reverse and have a strong web presence? Perhaps, but the lesson isn’t as prescriptive as it is instructive: the experience of the parts doesn’t necessarily have to be the same as the sum.

“A floor plan demonstrates the organizational logic of a building; a section embodies its emotional experience.” (page 168)

But what I like about this statement is the way it posits the scales on which components of a whole  are experienced: the emotional comes from the smaller scale interactions; the experiences on the task level or on a specific task model. The organizational feel comes form the large: the organization, the scale, the relationship to the external. Does information architecture function more acutely at this scale, while the emotion and experience takes place at the ‘lower’? I think of us as colleagues [titles aside] but does a title say something about a perspective or orientation? What is in a name after all?