Decision Matrix proof-of-concept

This proof-of-concept is the product of a thought experiment on how we decide between alternatives when making decisions. The tool enables the creation of a basic decision matrix, while supporting basic prioritization and qualifiers for uncertainty. The design was inspired by tools such as the Pugh Decision Matrix.

This tool was built using HTML, Javascript, and jQuery. The code is riddled with poor logic and inefficiencies, but it mostly works.

Check it out on Github

There is also an accompanying writeup on Medium:
“Decide Better with a Decision Matrix.”

Interaction Conference recap


Picture by @ekskloosiv

Last week, I was fortunate to be able to check out the three-day Interaction 15 conference here in San Francisco. It was a great time, and I loved having the chance to hear some awesome talks, see old and new friends, and even rub elbows with some of my biggest interaction design heroes. Some take-aways:

Social responsibility
Several speakers stressed the need for designing for social good and not simply chasing the dollar. As companies grow larger, Jan Chipchase argued that they emphasize replicability of process and deliverables and lose their creative edge. Be mindful of the “walk/talk” ratio: the disconnect between the idealistic and humanitarian actions that companies say, and the corporate and profit-seeking actions they actually engage in.

Tristan Harris and Kristian Simsarian asked: what if instead of designing for clicks and repeated use, we instead prioritized how well our interfaces supported human thinking styles and relationships? What if apps were certified for their potential to create “good times” between two people? The Redefining Software to Serve Life project hopes to explore these questions and more – check out their newsletter to stay in the loop.

Design agencies are NOT a thing of the past
In a conversation with Alan Chochinov, Tim Brown argued that although companies are increasingly beefing up in-house design teams, design work will always be in high demand and thus, consultancies will continue to provide value. Further, consultancies will excel in offering a more diverse skill set and outsider viewpoint and transferable methods that in-house teams can’t always compete with.

Designer humility
Although it wasn’t discussed directly, several talks touched on the importance of staying humble as a designer. Being in such a high-demand field, being increasingly showered with perks, and sitting higher and higher in the business and strategy realms of companies can inflate one’s ego and cause us to lose sight of our mission. We should remind ourselves that although our process and creative working style may set us apart from colleagues, we’re first and foremost connectors and facilitators for our colleagues and stakeholders.

Culture is paramount in fostering good design
Several speakers reiterated the importance of workplace culture and how it can be a boon for good design. Phi-Hong Ha shared many of her favorite methods for fostering workplace wellbeing, including the heartwarming practice of “love showering” colleagues and the  importance of regular off-sites for unwinding and reflecting as a team.

“I am not a designer”
Of all the talks, I found myself really digging  Ayah Bdeir’s presentation on her journey as a designer engineer human and how it lead to the success of LittleBits, a new language for people of all ages to make and invent new ways of interacting with electronics without needing to know their way around a breadboard or a command prompt.

Fun fact: The first prototype of Ringly was actually made with LittleBits!

“Designers: You have been lied to”
Mike Monteiro’s closing keynote was the cherry on top. Once again, his humor and “tough love” speaking style brought us insight into how not to fuck up our client presentations, while giving us enough laughs to bring tears to our eyes. In his thirteen-step checklist of mistakes designers make, he emphasized the importance of confidence, accountability, and earnestness. A well-earned standing ovation.

Some of my favorite quotes:

“Avoiding confrontation is increasingly expensive.” – Not to get too deep, but I’ve seen this to be true not only in design, but in all personal and professional relationships. I agree with Monteiro in thinking that one of the most valuable skills a designer can have is being willing to get fired for advocating good design. This isn’t to say your opinion is always right, but not speaking up may just land you a pink slip when the project fails after letting things fester for six months.

Mistake #13: Asking “Do you like it?” – You’re not a third grader in art class. You’ve gotten your approval along the way – don’t “sabotage” yourself “by inviting subjectivity into the room.” Remember that liking something on a personal and subjective level doesn’t necessarily mean that it will lead to a success for your client.

“My cockpit.” Don’t pass the buck – confidence is part of the job. As a designer, your client should depend on you to lead the presentation (exceptions, of course), and confidence “isn’t about you” at all – it’s about making the client feel at ease.

You can find videos for all the talks on IxDA’s Vimeo channel.

Design team “skill share” sessions


Just a snippet from the beginnings of our skills/tools spreadsheet

No matter the workplace, we all get lost in the design and product doldrums sometimes. There are times when everyone is so heads-down in their work bubble of production, spec’ing, etc. that we forget we’re even working on a team.

For this reason, design teams often hold regular meetings to come back up for air and set aside time to talk about ideas, inspirations and other what’s-on-my-mind and “professional development” topics.

Rather than listening to presentations or watching yet another TED talk, I wanted something more pragmatic and no-nonsense. The result was the skill share session, which runs as follows:

  1. The facilitator (that’s you!) puts together a list of 20-30 popular design and development tools – some that are more well-known and others that are new or even yet-to-be-released.
  2. Participants are asked to review the list, marking each skill as “Would learn” and “Would teach”, and are encouraged to add missing skills or tools to the bottom of the list.
  3. Prior to the session, the facilitator puts together a “suggested” list of pairs based on matches in teaching and learning designations – these pairs aren’t set in stone, but it helps to get the session started off quickly.
  4. At the session, pairs are formed and the meeting time is split into a “you teach me” / “I teach you” format, where each person gets to teach a skill and then learn a skill with their partner.

So far, the meetings have been very successful, with attendees seeming eager to participate and get the opportunity to both flex some muscle and learn a new skill in a short timeline. Learnings thus far:

Alleviating stage fright
I’ve been using a public spreadsheet where everyone has read/write access – it’s easy to do, but also ensures that the team can see the recent additions from teammates without some sort of approval process. Since all team members can view the spreadsheet, it’s possible that some team members may become self conscious about their visible lack of skills, or they may feel tempted to misreport skills to alleviate such concern. This is why I’ve labelled columns as “would teach” and “would learn” rather than something such as “has this skill”. Further, I’ve made it a point to encourage attendees to label skills that they would be most enthusiastic about teaching, and to not mark skills that they have little interest in teaching – because the skill is rusty, perceived to be of little future value, or any other reason. Alternatively, other team members responses could be made private – this would require an intermediary system for managing ratings and additions – something I frankly haven’t had time to explore, but I suspect it would be worthwhile to try, especially for larger teams where relationships aren’t as tight. For our team, I think the current system works well, and – to be completely honest – I suspect that participants actually appreciate seeing the larger list and generally knowing what skills are “hot” for the team collectively. An aforementioned “intermediary system” might still expose the “hotness” of skills without revealing individual preferences, perhaps. Food for thought.

Keeping the list simple and accessible
Since the list can be added to at any time, and because new design tools are popping up seemingly overnight, it’s important to revisit the list and encourage participants to update their preferences prior to any skillshare meeting. Categorization of skills/tools might seem valuable, but I’ve found that, because the list can change rapidly and be added to, categories are mostly ignored or only add noise to the list. Would you categorize Macaw as a “development tool”, “prototyping tool”, or “responsive design”? For the purpose of the skillshare meeting, who cares?

Being realistic about what a “session” entails
Depending on the time you can devote, it can be difficult for participants to learn and teach anything meaningful in a short span of time. If Fred really wants to learn Objective-C, should you even bother with a 30-minute time limit? For this reason, I’ve emphasized that our one-hour sessions focus on introducing partners to the topic and, if it’s a more ambitious topic, to focus on introductory resources and ideally acting as a future mentor or go-to person when the partner is pursuing the topic outside of the session.

I’m hoping to run another skill share session this week, so I’ll continue to riff on the format. If you end up exploring a similar process on your team, I’d love to hear about it!

Shadowbox Prototyping: A Method for Live Interface Enactments

This is a brief writeup on a recent publication for “shadowbox prototyping” – a method my team and I used to convey interaction prototypes with remote clients. The work was presented at the Ethnographic Praxis in Industry Conference in March. From the abstract:

“Working with a remote client to develop interaction design concepts, we found ourselves in need of a quick‐and‐dirty way to share half‐formed design ideas. Using a document camera, a telepresence application capable of sharing images and audio, and a reconfigurable paper prototype, we devised a method we called “shadowbox prototyping” to approximate an interactive onscreen experience with a remote collaborator, while allowing us to quickly iterate through interface ideas in real‐time.”

To read more, visit the full writeup.

Stop motion photography for prototyping

During a recent practice lunch event, a colleague of mine and I recently explored stop motion as a prototyping method.

Like paper prototyping and other low-fidelity methods, stop motion photography relies on widely available skills and materials. WIth applications like iMotion HD (free on the App Store), there are no technical setups to get started, and creating a movie is incredibly quick as a result. Real-time video rules don’t apply because of the choppy character of the film, making the entire process much more forgiving. It’s no problem to add and remove scenes and distort time and physical setups to one’s will.

As computing becomes more physical, tangible interfaces are particularly well-suited to be prototyped using stop motion. Similarly, interface transitions that mimic physical movement (e.g., the paper-like folding menu in Deal In) can also easily be explored and faked using physical objects.

I’ve not yet made use of this technique for UI design – this was more of an exploratory exercise – but I’m looking forward to giving it a shot when the next opportunity arises.

Further reading:


I tried out a new idea for ideation for my past project, which our team dubbed “Flickerstorming”. This group brainstorming methods involves the members of the group viewing a rapid slideshow of images to inspire idea generation during the brainstorming process.

To carry out flickerstorming, you’ll need a small group with a designated moderator for controlling the slideshow and transcribing ideas. For our purpose, we used a public photo sharing site (Flickr) to retrieve relevant photos, but also included several wildcard words or phrases to elicit interesting combinations of photos. The team shouts out any ideas they have that are sparked by the photos and the moderator records them.


From my experience, Flickerstorming has been an excellent method of helping a team to brainstorm a large amount of ideas in a very short span of time. The fast nature of the exercise prevents attachment to any one idea (which is why it’s important to have an automatic slideshow and short duration for each photo), and also helps gauge where the group members’ interests may overlap as each individual may have a very subjective and personal interpretation of the photos. Furthermore, the informality of the exercise encourages the full group to cooperate, as the risk of having a “bad” idea is minimized by the somewhat chaotic and rapid sharing of ideas.

I highly doubt that I’m the first individual to use this “method”, but thought I’d share my experience given how fun and effective it was for our project team. Application of this method is quite limited – it won’t help you come up with a new business plan – but it does seem to be useful for getting initial ideas together for a new product or service.