8 Apr, 2013
Creating a prototype is usually the most effective means of expressing a designer’s vision. There is a hazard in prototyping though that may cloud a designer’s judgement, and, ultimately, lead to biased and irrational decision making.
10 Oct, 2012
In a couple weeks I’ll be jetting to Columbus, OH to do a talk at the M3 Conference on prototyping techniques for mobile interface designers. In addition to a quick overview on why prototyping is essential for interaction designers, I’ll also do some hands-on demos of some of my favorite prototyping techniques and tools.
11 Jun, 2012
The more I work in an Agile development environment as a designer, the more I come to terms with the strengths and weaknesses of both the Waterfall and Agile methods.
24 Mar, 2012
On January 9, 2007 Steve Jobs unofficially ushered in a new era of personal computing. One day later in an article on CNET, AppForge CEO, Gary Warren, predicted the death of the mobile web browser. Gary was wrong.
In only a few short years mobile web browsing has jumped from virtually nothing to 8.53% of global Internet traffic (that’s more than Internet Explorer 6 and 7 combined, source). Google predicts that in 2012 over one billion people will use a mobile device as their primary Internet access point. That number will only continue to rise.
Pull out your phone, and go to your company’s website. How does it look?
9 Mar, 2012
I recently read a post by Jaime Creixems on his affection for the superior experiences crafted by Disney Imagineers (and to a lesser degree Apple). It’s nothing that hasn’t been said before; in a nutshell, Disney & Apple care deeply about and excel at user experience design (water is also wet).
Jaime also said the following, which I could not agree with more:
To achieve that kind of ‘awesomeness’ you need to care deeply about details.
His attention to detail comment, coupled with Andy Budd’s recent scathing remarks about the agency model inspired this post.
7 Mar, 2012
It happens to every project—there are a dozen feature requests in your backlog, but your team only has enough time to implement no more than four of them before the next scheduled product release date. Normally, you do one of the following:
- Start at the top of the list and work your way down until you run out of time
- Pick the features that the CEO/VP/Client added to the backlog
- Bust your ass to do a mediocre job squeezing all 12 features into the next release (8 of which were inadequately tested and stand a good chance of crashing the entire app/site)
Here’s another option to prioritize what matters: The Kano Model.