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.

5 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.

2 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.

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

How to use interactive forms in the product development feedback cycle

In product development, there is (or at least should be) a constant stream of feedback coming from your users to inform your development decisions. This feedback can come from a variety of formats depending on where you are in the development cycle. You might start out with interviews, contextual inquiry and observation, progress to storyboards and prototyping, but sooner or later you'll be able to put something in users' hands.

Recently, I began a pilot site evaluation for a product I'm working on at TI where I started using interactive pdf forms to gather and compile data from my pilots. In addition to site visits, email, and web surveys, interactive forms can fill a nice little niche in the feedback cycle. For example, surveys are perfect vehicles for assessing product performance at specified intervals. (e.g., alpha release, beta release, end of project release, etc.) Observation and email communication can be a great tool for getting a sense of how people are using your product, their general likes and dislikes, as well as where your product may need improvement, but managing all the feedback can be a daunting process, especially if you have a large number of customers.

This is where an interactive usage form can come in handy - the form can gather a set of common data across a range of users, and provide a way to analyze that data in an quantitative way. This can be a great supplement to the kind of summative assessment you get from a survey, and can also put some of your anecdotal observations into perspective. For instance, feedback forms may reveal some usage patterns you didn't expect in your product. You may also find some correlations amomg certain usage patterns, environmental variables, and product bugs that would be difficult to uncover in an SQA lab. As I go through an example, all this may start to make some sense...

The following example should give you the basic idea of how to:

• Design and configure an interactive pdf form
• Deploy the form to your end users
• Combine submitted form data into a spreadsheet
• Use Excel to analyze the submitted data

First of all, you will need to be able to create interactive forms. I am a big Adobe user, and I have access to most of their desktop software though my work. You will need a copy of Acrobat Professional - more specifically, you will need Adobe LiveCycle Designer. I believe this comes with Acrobat Pro, but you can always download a trial version to get started. In any case, LiveCycle Designer gives you the capability to create the form and configure how submitted data will be named, etc.

As you can see, LiveCycle Designer is a WYSIWYG form editor; drag different control widgets on screen from the library panel, then edit their properties in the object panel. Depending on how your users will access the form, you can add whatever form elements make sense for your particular product. All the values will eventually be dumped into a spreadsheet, so it may help to think about what types of information you will want to pull out later for comparison, then work backwards to determine what fields to place in the form.

In my experience, I've asked users to fill out the form everytime they use the product. Users keep the form in an easy-to-access location (e.g., their desktop) and when they finish using the product, they fill out fields and submit the form via the button located in the pdf. This model allows you to see what parts of your product people are using, any problems they've encountered, and how they rate each experience with your product. If you make the form short and concise, I've found people are more than willing to use it, usually while the details are still fresh in their memory.

A Note about submitting the form: There are a few ways to get data returned from the form... I've used the email submit button, which basically extracts all the form data, and sends it as an attachment to an email address you specify. You can configure this to attach a pdf form, xml file, or xdp file. You can also configure the form to submit the data to a URL where you will need to setup a server with OLED DB and some mechanism for stuffing it in the database. This is probably the way to go if you plan on using this for a long term customer feedback solution. I believe you can also configure the form without any submit button, and direct users to save the pdf file, and return it as an attachment. Since most people will be using the Free Adobe Reader software to populate the form data, you will have to enable "Usage Rights" in Adobe Reader in order for users to save the form with field data intact. This can be found in Acrobat Pro under the "Advanced" menu.

After you've done some testing to make sure you form is working correctly, you can deploy the file to your end users. Soonafter, you should start receiving usage reports in your inbox...

After you've received a batch of forms, save the attachments with unique filenames to a directory.

Now, in Acrobat Pro, choose Forms -> Manage From Data -> Merge Data Files into Spreadsheet. All your data will be copied into a csv file.

Each form element will be represented by a column in the spreadsheet, and each submitted form will be displayed as a row. Add an Excel worksheet to plot your data...

Now you can start to parse out the data in a meaningful way. Want to see what component people are using the most? Want to see what OS your users are running? How about problem encountered with your product cross referenced with certain usage patters? It's all in the data, and depending on your Excel proficiency, you can pull out this data and make these correlations fairly easily.

Interactive forms can be a great addition to your toolbox for gathering user feedback and usage reports from the field. Even if you aren't going to use them directly for customer feedback, they can be used as common templates for trip reports, conference notes, or any situation where you need to unify the framework for reporting data.

Sample files from this post: Usage Report Form Usage Report Spreadsheet

1 Comment  |   Permalink  |  Tag(s): how-to adobe customer-feedback tips product-development  |  Posted:02.24.08

Hello world!

Hello World, this is a sample post.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
9 Comments  |   Permalink  |  Tag(s): sample  |  Posted:02.18.08