c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel

Latest Updates: design RSS

  • erik 5:22 pm on February 8, 2009 | 0 Permalink | Reply
    Tags: design, , ,

    Sketching interaction stories with markers and iPhones

    I recently posted about Bill Buxton’s book, “Sketching User Experiences“, so I thought I’d share an example on using these kinds of techniques on a recent project.

    The problem at hand involved concepting a number of new features for an existing website, and sharing these concepts with a remote team. (When you can’t get everyone in the same room, it’s key that the team can quickly share ideas.)

    For this session, we used:

    • Whiteboards
    • Paper
    • Markers, scissors, and tape
    • iPhones
    • Keynote

    The goals were to:

    • Tell a story
    • Leave room for creative thinking
    • Validate concepts
    • Align thinking

    After open brainstorming and traditional white-boarding, a number of concepts were quickly sketched on paper (generally one sheet per screen.) These screen sketches were taped to a whiteboard, allowing quick note-taking and annotations:

    photo of whiteboard working session

    After walking through the concepts (and iterating) with a number of local victims, the screens were captured with an iPhone camera and pulled-into Keynote to create the storyboards. With each screen as a slide, a story can be told within the presentation format:

    bringing images into Keyboard

    Using this approach, stories can be shared globally, and changed in minutes. The hand-drawn images ensure that no-one gets hung-up on colors or copy writing, and they require a little creativity on the part of the reader, which gets the gears turning and leads to fantastic questions.

     

  • erik 6:44 pm on January 25, 2009 | 0 Permalink | Reply
    Tags: , design, ,

    Book: Sketching User Experiences

    I finished “Sketching User Experiences: Getting the Design Right and the Right Design“ last week in preparation for the upcoming UX Austin Book Club meeting.

    It’s 400+ pages, but a rather easy read. The book covers a range of topics, including:

    • The value of good design.
    • Good design only happens when designers understand the context of use, and explore many possible solutions.
    • Sketching allows designers (and potential customers) to explore ideas at low cost.
    • Sharing sketches enables early feedback.
    • Techniques for sketching interactivity.
    • Sketching can involve computers, cameras, and smoke-and-mirrors provided that it remain quick, inexpensive, disposable, etc.
    • There are many examples of quality sketching available in the archives of HCI history, and replicating these experiments is good practice for a budding interaction designer.

    My opinions on the book are mixed. It definitely offers positive motivation for sketching — and some great stories to feed those “why are we drawing pictures instead of coding” conversations that come up all-to-often with clients unfamiliar with UX Design. However, the book does come across a little passive, yet arrogant at times, while making numerous references without context. This gives it a somewhat academic feel, reading more like a light-weight thesis than a typical design book. That said, if you work in UX Design, being familiar with the ideas in this book will go a long way toward helping your career.

    While reading, I highlighted a few quotes, which I’ll list out below. I grabbed these not because they represent the theme of the book, per se, but because they had unique meaning to me, or something I’m working on. (For example, I’ve already used one of the quotes below in a presentation on the design process.)

    Quotes:

    “In order to design a tool, we must make our best efforts to understand the larger social and physical context within which it is intended to function.”

    This is a classic UX/HCI principle of understanding the user and their context for interaction as a design constraint/criteria. It’s a basic requirement in designing a product/solution that delivers value to a customer.

    This next quote is an interesting one for companies thinking that they can solve “design” simply by hiring a few designers:

    “It does not matter if you already have the talent to save your company among your current employees. If you do not have the vision, will, and power at the highest level, then that talent is almost certain to remain as wasted as it is frustrated.”

    Becoming a design company isn’t as easy as hiring designers (just like becoming an innovative company cannot happen simply by filling the ranks with a few smart people.) Companies can only lead the pack when these values go all the way to the top. Until that happens, organizational practices (and politics) will keep those talented stars from shaping the companies’ future.

    This one’s fantastic (and the one I used in a presentation):

    “Even if you do a brilliant job of building what you originally set out to build, if it is the wrong product, it still constitutes a failure.”

    Meaning, that even if your company can execute a product vision perfectly (ie., you have great developers/craftsmen/etc.), you’re still wasting your time, and money, if you haven’t validated that your concepts will provide the market value you’re trying to achieve.

    On the reason it’s important to share all ideas when brainstorming:

    “…better idea[s] would never have come about were it not for the idea that it replaces.”

    In other words, even bad ideas provide value via the thinking that occurs when we consider them.

    On team dynamics and the work environment:

    “A healthy team is made up of people who have the attitude that it is better to learn something new than to be right.”

    “A design studio without ample space to pin up sketches, reference photos, clippings, and the like,… is as likely to be successful as an empty dance club.”

    And finally, a reminder on why you never skip peer reviews:

    “It is better to have your preliminary work critiqued by your colleagues while there is still time to do something about it — no matter how difficult the criticism might be — than to have the finished project torn apart by strangers in public.”

     

  • erik 11:00 am on January 23, 2009 | 0 Permalink | Reply
    Tags: design, , , , ,

    IDEO Labs LiveView: an iPhone app for on-screen prototyping

    IDEO Labs just released a killer app for iPhone prototyping called LiveView. The application allows the iPhone to view, and interact with, a region of your desktop machine’s screen. Using this, you can have a prototype (or even an XCode application) running on your desktop, and try it out from your iPhone.

    LiveView screen shot

     

  • erik 3:27 pm on October 13, 2008 | 0 Permalink | Reply
    Tags: , design,

    Defining Design Thinking

    “Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”

    (Via Design Thinking.)

     

  • erik 8:01 pm on January 23, 2008 | 0 Permalink | Reply
    Tags: design,

    Formality and Audience

    Hard vs. soft edges differentiating the intended audience and meaning of the message:

    street markings

    Non-standard shapes and markings and the ability for drivers to ignore them based on unfamiliarity:

    street markings

     

  • erik 10:22 pm on September 4, 2007 | 0 Permalink | Reply
    Tags: design, ,

    User error vs. machine error vs. interaction design

    Why the high volume of discarded stickers? What does this tell you about the users? What about the machine?

    The full context:

    The design of this self-service, produce-pricing machine includes an area for discarded “mistakes”; but at what point is it an indication that it’s no longer user-error?

     

  • erik 11:44 am on August 25, 2007 | 0 Permalink | Reply
    Tags: design, , ,

    Interface design on Sparkfun’s new GeoChron

    Interface design on Sparkfun’s new GeoChron

    Sparkfun just released a new, stand-alone GPS logging device, which looks to be a slick alternative to all the “mobile-device + Python + bluetooth GPS” hacking I’ve resorted to for similar tasks. It’s a pretty tempting package if you need dirt-simple GPS logging. However, I’m a bit confused by the switches. Take a look at the picture of the device below:

    There are two toggle switches: one for on/off, and one for standby/run. Take a minute to look at the switch diagrams and labels, and think about how to use this device. How do you turn it on? How do you make it start logging?

    Now that you’ve thought about it, was it clear? What does the ‘1′ on each switch mean to you? What does the graphic under each switches label mean? Ignore the ‘1′ and ‘0′ and look just at the diagram. Based on the graphic alone, which switch position should “on” be?

    I used to get the ‘1′ vs. ‘0′ on switches backwards when my mental model was of the ‘0′ indicating a completed circuit. Now I use a binary metaphor, where a ‘1′ bit is on, and a ‘0′ bit is off. That seems to be what the switch means. But if I take that approach on the GeoChron, then the standby/run switch is installed backwards. Personally, I think I’d drop the graphic under the switch labels (I think it’s more confusing then helpful), and flip the standby/run swtich so that ‘1′ means ‘run’, and so that the switches are both pressed in the same direction when the device is on and logging. With a device this simple, you really shouldn’t have to think about how to turn it on. (I still want one though ;-)

     

  • erik 4:01 pm on October 23, 2006 | 2 Permalink | Reply
    Tags: design, , , , , , ,

    Dashboard Widget to mash iTunes library with OnTour.net

    Just the other day I had a friend mention a desire to scrape tour schedules in MySpace so that he can find out when artists he’s interested in are in town. (He eventually decided it was too much hassle and would like someone else to do it, which is why I’m able to mention it here.) It’s a cool idea, though the OnTour Dashboard Widget takes it to perhaps another level.

    The Widget monitors tour information in OnTour.net and compares it to the music you have in your iTunes library. The downside being, of course, that you have to hit F12 to get a notification. But otherwise, the interaction model is perfect — meaning that you don’t need to change your behavior at all, yet you gain new value and information. Brilliant.

    (Via Lifehacker)

     

  • erik 12:59 pm on September 11, 2006 | 0 Permalink | Reply
    Tags: design, ,

    Feature-bloat and customer satisfaction

    In my day job as a Product Manager of mobile development tools, there’s a frequent struggle between feature-bloat and a desire to simplify the development process. Even when you know that it will improve the user experience, it can be difficult to build a business case for removing features or re-factoring a user interface. Because of this, I’m always excited to find any tangible data on the ROI of simplifying complex technology. (ie., It’s not enough to say “customers will like it better”, and it’s not easy to find compelling data to clearly demonstrate a tie between improved usability and improved consumer uptake.)

    Even still, war stories and the occasional bits of research do help the cause. For example, the post “Capability, usability and feature fatigue” offers a short summary of a Harvard Business Review article titled, “Defeating Feature Fatigue“, which features the following quotes:

    “Before use, capability mattered more to the participants than usability, but after use, usability drove satisfaction rates. As a result, satisfaction was higher with the simpler version of the product.”

    “If companies conduct market research by asking consumers to evaluate products without using them, too much weight will be given to capability, and the result will likely be products with too many features.”

    This idea ties nicely to another Harvard article, titled, “Feature Bloat: The Product Manager’s Dilemma“, which also caught my eye.

    (Via In-store good or at-home good?)

     

  • erik 6:44 pm on January 18, 2006 | 0 Permalink | Reply
    Tags: design,

    Followup: “Agile Software Development Techniques and its Impact on Product Management”

    I posted last week about going to a talk on “Agile Software Development Techniques and its Impact on Product Management.” Since I mentioned I was going, I thought it might be useful to post some followup comments, so here goes…

    I went into the session hoping to hear some strategies and practical advise on applying Agile (and XP) to large-scale software projects that have key requirements and a timeline which is dictated by an outside driver. For example, let’s say you need to deliver a podcasting application for a piece of commercial hardware that has a fixed shipping date. Well, the answer from the session was simply that Agile isn’t always a good fit. Fair enough. And, to be honest, I was glad to hear advocates of Agile/XP being blunt about when the technique does or doesn’t fit well to a project’s needs. (Note: absent of the fixed shipping date and requirement to be installed on hardware that might not be easily upgraded, a podcasting client would normally be an excellent fit for XP.)

    I was also hoping to here more opinions on mapping Agile/XP techniques to the Pragmatic Marketing process (that it seems all Product Managers have studied, including me.) I was a little disappointed here as well, since although the Pragmatic process was mentioned, there wasn’t a discussion on how the two approaches can harmonize.

    Since the session, I’ve been looking for more overlap between XP and Product Management and ways to adapt some of philosophies to my current projects. One area where I believe the Pragmatic approach can adopt XP techniques in User Stories vs. Use Cases. (extremeprogramming.org has more on User Stories if you’re interested.) User Stories offer a simplified approach to documenting and explaining customer requirements, with a focus on involving the customer in the process. This is actually a much better fit for Product Management then Use Cases, since they are quicker to write, less technical, and completely focused on customer-driven requirements.

    I was also glad to find that XP projects do have a role that somewhat maps to Product Management. They call it a Customer Representative. This role focuses on real customer requirements, much as Product Managers do already, but drops tasks like Market Research, Win/Loss analysis, etc. (which you might not want to do for a commercial product.)

    Overall, I didn’t get what I wanted out of the session, but it has prompted me to look for more ways to influence product creation process using philosophies from XP. XP itself isn’t new to me, nor are Agile and Iterative development processes, but I rarely get to use them outside of personal projects. Applying XP in an environment that favors more traditional approaches will be an interesting challenge, but they pay-off for the team and the customers could be worth it.

     

  • erik 2:00 pm on August 23, 2005 | 0 Permalink | Reply
    Tags: design, ,

    “Extreme Programming vs. Interaction Design”

    Here’s a topic that hits rather close to home: In the interview, “Extreme Programming vs. Interaction Design“, Kent Beck and Alan Cooper discuss opposing views on producing better software, and unfortunately, I can’t say that either one really “wins” the argument.

    The piece hits close to home because I used to work in Interaction and Information design, so I fully grok the value proposition Cooper presents. The argument is the typical Human-Computer Interaction (HCI) / User-Centered Design (UCD) pitch — that up-front interaction design will (1) produce a higher-quality product, and (2) will reduce development costs by solidifying technical requirements. However, what surprised me in the interview is that Cooper seems inflexible on how to best apply this UCD process, insisting that it is a design “phase” that starts and finishes before any development begins.

    The central assumption in Cooper’s argument is that programming is expensive and programmers are unwilling to throw out prototype code. Because of this, Cooper believes that you should not allow programmers to begin working on a project until 100% of the requirements are set. I used to believe that too, but I have since seen the light.

    The trouble is, rigid processes with pre-defined phases and deliverables are best used when managing a large group of low-to-moderately skilled developers. However, small teams of smart people change the rules and the outcome. Development teams that recognize the value in Agile Development and XP also understand that the assumptions driving waterfall-style development phases are based on faulty assumptions, which easily fall apart given the following findings: (1) It *is* possible to reduce the cost of developing code (see Python and Ruby on Rails); (2) Better products are often the result of iterative design (compare a forth-gen iPod to a first-gen); and (3) If your programmers aren’t capable of “sketching in code”, you need to hire better programmers (see all of Paul Graham’s and Joel Spolsky’s articles ;-)

    This isn’t to say that interaction design isn’t helpful, because it most certainly is, and any company serious about serving it’s customers should at least consult a user experience and interaction designer about their products, if not have such a designer on the team; However, there is even greater value in rapid iterative development — both in interaction and implementation, and companies that understand how to utilize this advantage will produce higher-quality user experiences in a shorter time-to-market.

    (via Signal vs. Noise.)

     

  • erik 10:29 am on August 15, 2005 | 0 Permalink | Reply
    Tags: design

    “The Best Product Designs of 2005″

    It seems a little short-sighted to release a “Best Product Designs of 2005” article only halfway through the year; However, it does contain quite a few examples of excellent product design. The article itself is light on content, so you might as well skip straight to the Slide Show to enjoy all 158 examples of eye-candy goodness.

    One of my favorites: the Self-watering flowerpot.

     

  • erik 11:37 am on May 25, 2005 | 0 Permalink | Reply
    Tags: design,

    xyle scope

    I like trying new tools (especially text editors — I’m a sucker for text editors.) Today it was Xyle scope, a funky CSS editor for OS X.

    The concept is interesting. Xyle scope let’s you surf the web in one pane, while providing a cluster of hierarchical CSS and DOM tree views in adjacent panes. The DOM tree and CSS inheritance can be explored in what I found to be a fairly intuitive manner. CSS properties can be changed, and live previews provide immediate feedback.

    This is all very interesting, but unfortunately, that’s about where the usefulness seems to end. I couldn’t figure out how to view or edit the raw HTML, nor could I figure out how to add or delete CSS properties instead of just editing existing ones.

    As a tool to explore web page construction (especially new-school pages that rely heavily on CSS), it’s an interesting product. If you often find yourself debugging someone else’s CSS, it might be something to look at. But this isn’t an authoring tool. You’ll still need something else (like a good text editor) to compose your HTML and CSS.

     

  • erik 2:02 pm on April 22, 2005 | 0 Permalink | Reply
    Tags: design

    When will they learn…

    Giving your customers access to their own data, and encouraging them to extend your products, is key for a high quality customer experience. For example, Karl and I were chatting the other day about the recent trend in extending Google Maps to build new applications that drive traffic. (For example, Google Sightseeing, Housing, over-laying subway maps [here and here], etc.) It’s one of the reasons flickr and del.icio.us are so popular — they encourage remixing (to use Rael’s term.)

    However, support for open architectures and empowering one’s customers hasn’t caught on for everyone. Take this example: Nikon encrypts D2X white balance metadata. Nikon has decided that in their high-end cameras (the kind only bought by die-hard camera types), they will encrypt the previously open metadata stored with each photo so that customers can only use Nikon software to work with their images. You’ve got to be kidding! Locking in customers doesn’t work anymore guys! And if you’re looking for a reason why, it’s right here: “Nikon’s photo encryption reported broken.” Customers wanted to use those cameras so much that they reverse engineered the encryption scheme. (Which, yes, probably violates the DCMA.) Fortunately for Nikon’s customers, this makes their product somewhat attractive again. But they’ve still risked turning away their own customers trying to lock them in.

    Take a lesson from the cluetrain — your customers have a voice, and potential customers listen to it. Good customers will even work for you if you let them, but you have to open up, listen, and be good to them.