Sketching, prototyping, and Balsamiq Mockups

Although it is a few years old, Sketching User Experiences by Bill Buxton is one of the best books I've ever read describing the user experience design process. In the book, Buxton basically argues that UI/UX designers everywhere are omitting one of the most basic and fundamental steps in the design process: Sketching. Many software professionals use the terms "sketch", "prototype", and "storyboard" interchangeably, when in fact they are very different. Sketches are meant to be cheap, plentiful, and ambiguous. Sketches should raise questions - you need to be able to get more out of a sketch than what you've put in. Too often, designers commit themselves to a design that was never measured against alternatives. Designers cling to early ideas, and before long, they've created elaborate power point presentations, pixel-perfect Photoshop mockups, and GUI specification documents of the wrong design. Buxton contends this happens because designers aren't prolific enough in their sketching, but also because managers, developers, and customers like to see "finished" designs - reinforcing the notion that higher fidelity designs are *better* designs. "Sketches" or "hand-drawn" artifacts don't convey the warm and fuzzy feelings of a finished design; consequently, they are given less importance as deliverables.

Below is a (long but good) video of Buxton explaining how Sketching relates to the User Experience Design process:

After I've done my homework creating sketches and had some help identifying some viable designs, I usually try to create a paper prototype to test with users. From my experience, this step has been invaluable for learning about the user's mental model, expectations, and is very helpful in flushing out design flaws in early in the process. Perhaps the most important part of a paper prototype involves creating the right scenario or tasks for your users to effectively exercise your design. By making someone "use" your design, you start to reveal the "arrows" or "transitions" between states (the static screens). Buxton stresses the importance of these transitions in his book, contrasting the difference between interface design and experience design; if you only design states, and do not design the transitions, you are not accounting for the experience - only the interface.

I mention Buxton's book and his ideas about the importance of sketching, in particular the call for lower fidelity designs early in the process, because I just stumbled on a new tool that I think could help. To keep designs from getting too polished too early, take a look at Balsamiq's Mockups. Mockups is a tool that allows you to quickly create software mockups using popular GUI components using a WYSIWYG drag 'n drop interface. Unlike traditional paper and pencil sketches, Mockups allows you to work electronically, making it easier to share and collaborate on ideas - especially on geographically dispersed team. Unlike other electronic design tools, Mockups renders controls with a hand-drawn style, making them appear as unpolished, works-in-progress. The combination of electronic authoring and hand-drawn appearance provide a great tool for any UI/UX designer's toolkit. Although Mockups does not replace the need for paper and pencil sketches, I think it could fit well between the sketching and prototyping phases.

To learn more about Balsamiq's Mockup, see the video above, or check out some of the examples posted on the website.

0 Comments  |   Permalink  |  Tag(s): sketching prototyping tools software-design  |  Posted:09.16.08

Google maps in 4D

Lately, I've been thinking up some "wouldn't it be cool if..." scenarios for Google maps. After some initial searches, I could only find a handful of examples that related to what I had wanted to do; namely, combine a Google map with some sort of time-line. The idea stems from the need to view a timeline of events in a geographic or spatial relationship rather than a flat text listing.

To illustrate this idea, imagine viewing a police blotter in map form rather than a text listing. If you are searching for crimes close to your neighborhood, or other point of interest, a map is a much more efficient means of displaying that information. Scanning a list and mentally calculating the location can be a bit awkward, so a geographic representation seems like a natural fit. Adding the dimension of time could allow you to discover all sorts of relationships and patterns that may not have been evident from the data alone. Viewing a mapped police blotter over a specified period of time could reveal impacts of new neighborhood watch programs, extended police patrols, or track and correlate certain crimes to geographic locations.
The mockup below shows how you might display this type of information on a map with a slider to control the timeframe (think weeks, days, or hours)

Another useful scenario would be to map upcoming events to locations... For example, sometimes I will pull up the Guidelive events page or upcoming.org to see if anything interesting is happening around DFW for the upcoming weekend, etc. The result is an html page chocked full of events and attractions. You can narrow this down a bit by using the guidelive neighborhood filter, but you can only choose one neighborhood at a time, and I am not really sure what those designations mean anyway... (What is the difference between north dallas and far north dallas?)
The example below samples how you might view upcoming events over the next week.

Although the examples above show a fairly simple implementation, with a little work, you could find all sorts of ways to combine different date pickers, slider controls, and animation techniques with public data and calendars to come up with some great mashups. With the newly announced support for Flash in the Google map API, the possibilities are endless.

Here are some other applications where it might be useful to see map data over time:

• Public calendar mashups (see upcoming conferences / meetups, view a sports team or band schedule, etc.)
• Disease outbreaks (see John Snow's discovery in the 1854 Broad Street cholera outbreak)
• Travel itineraries
• Tracking packages, deliveries, etc.
• Geo-Twitter, social mapping, etc.

The maps above use the Google maps API to read marker data from an external xml file. Many thanks to the good people at the Blackpool Community Church Javascript Team for providing such great tutorials. The top map also combines jquery's slider control (hat tip to Chuy for helping me out his javascript ninja skillz) Note: Firebug seems to slow down the map performance, so if you are seeing some weirdness while using FF, please disable firebug and reload the page.

0 Comments  |   Permalink  |  Tag(s): maps google ideas  |  Posted:05.17.08

TI-Navigator: a visual explanation...

Although I've always been interested in illustration and informative graphics, I really haven't had a lot of spare time to work on those skills. I recently decided to give it a try... I figured if I could choose a subject that was work-related, I might be able to score some bonus points at work while getting some practice at something I'm interested in pursuing. Since I work closely with the TI-Navigator system, I thought it would be a good candidate.

See the full size poster (11x17) here.

0 Comments  |   Permalink  |  Tag(s): infographic illustration ti-navigator  |  Posted:04.05.08