Thursday, February 19, 2009

A Paper Prototyping Testimonial

[Hi Everybody...Chris here. I'm thrilled to present another guest post to you here on Interface Matters. Please welcome Kathy Brown, who recently started blogging over at Kathy's Running Notes. She was inspired to try low-fi prototyping after attending my session with Tom Duff at Lotusphere and I was really happy to hear about her success with it. Below is a post about her experience. Thanks, Kathy! Don't forget to check out her blog...]

I frequently spend many hours in meetings with users, emailing users, instant messaging users and phoning users to determine their requirements. I then spend countless hours developing an application that I think satisfies their requirements. Only to demo the app and have the users point out 50 things they would like to see differently ("that's not what I meant"). And around the wheel we go again. All because it is difficult for users to "see" the finished product before it's, well, finished.

I was lucky enough to attend a session by Chris Blatnick at Lotusphere 2009. [Editor's Note: Flattery will get you everywhere! ;-)] Among other things, he covered Low-Fidelity Prototyping, which he has also covered on his blog. He also calls the technique 'paper prototyping' because it is just that, drawing out on paper what the app is going to look like. Everything. Buttons, views, tables, etc. Check out his blog to see more on how to do it.

I immediately got home from Lotusphere and had to try it out. Luckily, I am in the early stages of a new application and could put this right into action. Oddly, I used it on myself first. I think Chris' intent was to get better feedback from users before beginning coding, but I was able to use it to clarify my OWN thoughts on the application before even speaking to the users. (Woohoo!)

I drew out several of the screens required for the application and immediately saw flaws in the design. Back to the drawing board, literally, and I redesigned several portions. Drew them up again and realized several features that I knew the users would ask for when I showed them. I added those onto the drawing. Now I could bring a much more "developed" application to the users before even getting any of their feedback. I looked like a hero! Additionally, they were better able to envision the finished application, and add their feedback, BEFORE I had coded anything!


LFD from a user session. The red pen is actually from the user's input in the meeting, adding two new sections and a field, while removing an entire column of data they decided was confusing to the users.


I am also working on an in-production application. The users frequently have new requests and features they desire. In the most recent release of the application, a new form was added based on vague user input. (You know how it goes, "Hey we want the form to do this and this, you're the designer, you figure it out."). The users had some pretty negative feedback. The feedback tended to be along the lines of "this sucks" and was not very useful in figuring out a solution. I decided to meet with some key users and had a paper prototype in hand. I offered them some visual suggestions as to how we might change the form. Seeing those suggestions "in real life" enabled them to provide constructive suggestions on what they would actually like to see on the form. They were passing the paper prototype back and forth and drawing on it until they agreed on the new layout and design. Again, all before I coded (okay, re-coded in this instance) even one line of code.

I can't recommend this technique nearly enough. It saves me time as a developer and makes the users happy with an end result they like, as well as making them feel invested in the product. I am looking forward to using this in all of my designs.

About The Author: I've been an application developer in Lotus Notes/Domino for four years. I am currently the lone developer at my company, so like many others, I am overwhelmed and expected to do miracles therefore I love to learn techniques and technologies that will make me more efficient! Prior to working in IT, I've been an Investment Analyst, a temp, and even an actress (long ago and far away).


Labels: ,

permalink | leave a comment

Thursday, November 13, 2008

Flashback: The Low Down On Low-Fidelity Prototyping

Note: This is a repeat of one of my more popular articles. It is reprinted here after several requests. Since I have a lot more readers now than I did when originally posted, I thought it would be a good time to recycle it. :-)

You don't have to be on this site for very long before you'll start picking out some common themes. Two of the topics that I am very passionate about when it comes to the development process are low-fidelity prototyping and usability testing. I truly believe that every developer (no matter what their preferred technology) can reap enormous benefits by adding these two simple techniques to their development methodology.

On the most recent Taking Notes podcast, I mentioned I have some articles about usability testing coming up. Well I do, but I thought it might be a good idea to cover the first of my two 'secret weapons', since usability testing actually follows as a logical extension of low-fidelity prototyping. With that, let's first define what low-fidelity prototyping is about. Due to its RAD nature, most Notes developers are very familiar with the concept of prototyping. In the case of low-fidelity prototyping, the word 'fidelity' refers to the level of detail in the design itself. That is:

Low-Fidelity = Quick & dirty hand drawn screens

High-Fidelity = Polished design or high-quality screenshots/mockups

Another name for low-fidelity prototyping is "paper prototyping" and perhaps this name more fittingly describes what you use in the process. I prefer low-fidelity prototyping because it sounds more impressive, and if I were a consultant, I could probably charge more (haha...OK...only kidding!). The purpose of the low-fidelity prototype is to allow you to design the interface of your application before you focus on anything else. Some developers think I am committing heresy when I say this, but I believe without a doubt that you can design a better application if you build the interface before you write any code!


One of the first benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. I think you'll be surprised at what additional information you uncover so early on. There are several other benefits that low-fidelity prototyping brings to the design process, but first let's take a step back and talk a bit about how you build one.

Perhaps one of the neatest things about low-fi prototyping (that's what the cool kids call it) is that it is so easy to do...and dare I say...a lot of fun. The tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. The low-fidelity prototype is not meant to be polished. It's just a 'rough draft' of your screens. A lot of great work in design and engineering was initially conceived on the 'back of an envelope' and the concept is the same here.

To get the most benefit from this technique, you need to draw out all of your interface elements. This includes screens, menu items, dialog boxes, etc. Place only one element on a page (e.g. if you have 5 dialog boxes, use 5 sheets of paper, one for each dialog). This makes it easier to manage your design, especially as you work through multiple iterations. That's really all there is to it!

As you are beginning the work on your low-fi design, remember that this is the ideal time to 'think outside the box'. Try to forget the constraints of your development platform and instead focus on how you can design an interface that will be clean, efficient and easy to use. If you have the luxury, I think the ideal state is to stay technology agnostic. Design the interface, figure out what functionality is needed and then decide on which tool is the right one for the job. You can temper this with good judgment, of course. If you know you are building an application in Notes, don't design an element that you absolutely know you can't use in the client. However, some of the best interfaces I've made were initially born out of low-fidelity prototyping, followed by an exclamation of "There's no friggin' way I can do that!" A little perseverance and a lot of experimenting in this regard can pay off big time, though, so give it a try. The worst that can happen is that you fail, learn a lot from that, and then move on to plan B.

Once you have completed your first low-fi iteration, schedule some time with your customers to discuss it. See if they can understand the functionality without you explaining it to them. Are there glaring errors that are immediately evident or are they just bringing up subtle points? Make sure to take as many notes as possible, trying to capture everything the user points out or alludes to. You can often find important information in these notes...things the customer initially forgot to tell you, details on how computer savvy the user base is, etc.



So...You've built your prototype, met with your customers and got a couple of suggestions for changes. Time to go write some code, right?! Whoa, there partner...not quite yet. Unless you absolutely nailed it on the first try (probably not), it's time to build another iteration. On average, I'd say you'll build about three low-fi designs in a typical project. Each time, you'll refine and meet with your customer, coming closer to the final interface with each pass.

Let's return to discussing benefits around low-fi prototyping, since this is one of the stages where you really see a payoff. One reason low-fidelity prototyping works so well is due to the psychology of how we perceive quality. A user looking at an actual application on the screen is generally less apt to point out flaws, even if you only invested a little time in it. They think to themselves, "Gosh, he's already got something ready for me. I guess I can live with this, even though it's not exactly what I want." The customers tend to censor themselves, since they think you've invested time and money in the design. At this point, you might be thinking "Not my users...they hate everything and tell me so!", but most people will do this, just to varying degrees. Users generally have no problems, however, when you throw a hastily drawn piece of paper in front of them. When it looks like you had a little kid whip something together, the customer will definitely let you know what they think! :-) In fact, I suggest a little experiment. When you go into your low-fi meeting, strategically place some pens, pencils, crayons, whatever, in an area that the customer can readily access. I'll bet that when you set the prototype in front of them, they reach for one of those implements and start marking away. Let them! This is valuable, as it helps you see what they really want. It also gets the user emotionally invested in the design, which in my experience leads to increased satisfaction at the end of the project.

As developers, we benefit from low-fidelity prototyping as well. It may sound like this process adds time up-front and you're right...it does. However, once your prototype is pretty well finished, you've got a great plan for development. You won't be sitting there staring at a blank canvas, wondering how to start. Instead, the low-fidelity prototype provides great clarity and allows you to concentrate on the next important part of your process, actually writing the code. Also, since we've avoided code until this point, we've probably saved time and money. Often, the choice of interface elements we use dictates the most efficient path we take coding wise. Any time you start development by writing code puts you in danger of having to back track or rewrite in order to address UI concerns. Hopefully, you can see that capturing the specifics of the UI up-front helps mitigate these risks.



The definition, increased communication and clarity that low-fidelity prototyping can bring to a process is highly beneficial by itself, but it becomes infinitely more powerful when combined with our second 'secret weapon', usability testing. That's right...you can actually test your application using the paper prototype (how cool is that?) We'll explore this technique in a future post.

For now, let me leave you with a call to action. Give this process a try on your next project. It's certainly not hard and I think you'll find it very powerful. If your customers (or most likely your boss) look at you a little weird, be honest with them. Explain why you are doing this and the possible benefits (hint when dealing with the PHB* --> "It saves money!!!"). Let them know that it is a new concept for you as well and that you'll learn together. The customers will appreciate your openness and will most likely be willing to give it a go. My guess is that after the project, you'll be doing a lot more low-fi work.

Overall, low-fidelity prototyping is a super technique that I use all the time. I hope you find it as compelling as I do. Good luck!


*PHB

Labels: , ,

permalink | leave a comment

Thursday, November 06, 2008

Balsamiq Mockups...A Very Cool Tool For Building Prototypes

As long-time readers know, I'm somewhat of a zealot when it comes to singing the praises of low-fidelity prototyping. Over time, I've found that it allows me to get to the best possible user interface faster than any other method. While I love breaking out the crayons, markers and paper, I do admit that it sometimes becomes more time consuming than I'd like if I have to keep redoing a certain screen. This is where I see a computer-based tool being very helpful.

In a past post, I introduced you to using electronic tools to build a prototype. Thanks to an e-mail I received from a reader (Cheers, Miguel), I've found another prototyping tool that I think could be *the one*. From what I've seen, it's full featured, very easy to use and allows you to create interface mockups in a flash. It's got a funny name, but the story behind it makes it quite apropos. Check it out...it's called Balsamiq Mockups

Balsamiq Mockups...check it out

I'm not going to go into details on the features here, since the elegantly designed Balsamiq website already does that. I do, however, want to point out some things that make it killer:

* It's got a web UI as well as a desktop counterpart if you want to do offline work.

* The hand-drawn elements are well done and plentiful. There's a control, window or container for almost every UI situation you can think of.

* You can export the end result as a PNG or XML file.

* It just works.

If you've ever considered building low-fidelity prototypes but were put off by the idea of using analog tools, I'd definitely recommend giving Balsamiq Mockups a try. You can use the web interface directly from the site. Hopefully, I'll have the opportunity to test drive the desktop based version soon. If so, I'll be back with an updated review.

OK...so what are you waiting for. Go forth and draw! :-)

Labels: ,

permalink | leave a comment

Saturday, July 26, 2008

On Why Design Just Might Drive You Crazy

STOP...and take a look!  ;-)

Labels: , ,

permalink | leave a comment

Sunday, June 24, 2007

"Low-Fidelity" Prototyping With Electronic Tools

Do you like the idea of low-fidelity prototyping, but don't relish the idea of dealing with all that paper? It's certainly possible to get the great benefits of the low-fidelity prototype without all those annoying paper cuts by using some creative electronic tools.

One of the ways I sometimes "cheat" in this area is by taking advantage of my Tablet PC. I use Microsoft OneNote as my "blank pad" and create my low-fidelity prototype directly on the screen with my tablet pen. Although I really enjoy working with pencil and paper (and crayons, markers, etc.), I find the tablet solution to be a good one when I'm pressed for time. If I want to make changes, I can simply erase an area of the screen or create a copy of the current page and make the modifications on the new version. Taking advantage of OneNote allows me to group related prototype pages by project, perform searches on keywords, backup my work easily, etc.


Using OneNote on the tablet is also a great help to me when I'm further along in the design process. I can use the program to perform a quick screen capture, then use digital ink to annotate the changes needed directly on a picture of the screen in question. This aids me greatly in remembering what we were doing if I go back to find some details in the future.


Another promising tool for quick "low-fidelity" prototyping is the DENIM project. DENIM allows you to create actual working prototypes that maintain the spirit of quick, iterative low-fidelity methods. With this tool, you draw your prototype as you normally would. The cool part is that the system is very smart and can identify common design patters, such as text boxes, labels, radio buttons, etc.


Check out the videos on the project site to see it in action. I think you'll agree it has some merit. I have to admit that I haven't tried DENIM yet, but it's certainly on my to do list. If you check it out, let me know what you think.

I'm sure there are other creative developers out there that use electronic tools to perform quick and dirty prototyping. If you've got some ideas you'd like to share, please post them in the comments. No matter how you go about it, the important thing is that you prototype often and early. This will help you deliver better systems to your users!

--------------------
Wow...just realised as I was saving that this is my 100th post. Didn't think I'd make it this long, especially since I sometime get a bit long-winded! :-D Thanks for sticking around everyone!!!

Labels: , ,

permalink | leave a comment

Tuesday, June 12, 2007

Usability Testing...Uncover The Flaws In Your UI (Part I)

Usability testing is the second of the two incredibly powerful development techniques that I suggest you add to your design arsenal. The first, which we covered in my last big article, is low-fidelity prototyping. Even though they are powerful concepts on their own, if you actually combine these techniques together and use them in conjunction with one another, I guarantee that you'll start delivering higher quality applications to your users, at least as far as the user experience goes. *

So...what is usability testing all about? Usability testing, in its simplest form, is all about testing whether the design of your application meets the needs of the users from a UI perspective. This test will uncover if your design is simple and easy to use, if there are glaring errors that prevent the user from accomplishing their work or even the more subtle things that might make the user's job easier or harder. Whereas traditional software testing is used to determine if your application does what it is supposed to do with the data it is given, usability testing is concerned with whether the user can successfully get the data in (or out) in the first place.

Usability testing is quite often relegated to second class status as far as testing goes and many times it is left out of the design process entirely. This is a real shame, since this form is testing is really the most critical. By testing your UI, you'll have the opportunity to find the troublespots that will trip up your users before you let them start using it (i.e. roll it out to production). Remember, the sooner you can find and fix errors, the cheaper it will be. If you can do this before you even write a line of code, you'll be making significant progress in reducing costs and boosting quality. Best of all, you will improve user satisfaction by performing usability tests and this is perhaps the most important metric of all (unless you don't really care about them...in which case you should stop reading and go flick the server on and off several times ;-)

Usability tests can range from really high tech (think two-way mirrors, video cameras, fancy labs) to really simple (e.g. a user & developer meeting in a conference room). Most of is aren't lucky enough to work in a company with a dedicated usability group, so it will fall to us to conduct the tests. I advocate a fairly simple approach and I tend to keep my methodology fairly lightweight. If you try to get too process heavy in this stage, you run the risk of subconsciously making up reasons to skip it ("We don't have enough time!", "There are more important things to work on!"). For a typical Lotus Notes business application, I think you can get some pretty useful data with a handful of users, somewhere on the order of three to five people. Of course, the larger your app and the more users you can test, the better your data set will be. Use your best judgment here. You'll get better with practice.

Once you have some users on board, what do you test? To be effective and to allow you to make logical comparisons with the data sets, usability tests should be task-based. That is, your test users should have a predefined goal to accomplish within the application. By using a defined task, you are setting the boundaries and restricting the users' choices. This helps keep them from ambling around the app without a purpose.

During a usability test, your most important job as a developer is concentrated observation. You should be recording notes on all the action the user is taking as they are working on their task. Pay particular attention to times when the user pauses or looks puzzled. It is perfectly OK to question the user when they perform an action or when they seem confused. The whole purpose of this process is to find errors or difficult aspects of your UI and these notes will serve as the main data you will analyze. Don't be shy about drilling into the user's thought process and let them know that it's OK to be brutally honest. Yes, sometimes the truth hurts, but it's best to hear about likes and dislikes now rather than later.

One important note here: When you are performing a usability test, be sure you make the user feel comfortable and insure them that you are testing the application not their skills. When things go wrong or a user does something you didn't expect, first tell them that it is OK. After all, this is why they are helping you. Then, question them and find out why they did what they did. Some really interesting data usually comes out of the things that are broken or when users try to use elements in ways you did not expect.

In the next article, we'll explore the actual mechanics of the usability test. For now, let's just assume we conducted a test and we have several pages of notes covering the specific task we studied. What do we do now? Now, we pour through the notes and attempt to analyze them. Look for common patters or themes across the various users. You are trying to identify the elements of your application that are broken or that caused significant delays or user frustration. If you did a good job with soliciting the users' thoughts as they carried out their task, you most likely have a good idea of why a particular component didn't work for them or why they got frustrated. The trick now is to take all of this data and fix the troublespots. (You can look for the good things too. If users really liked the way you implemented a certain feature, make sure you find out why and use this knowledge in the future).

Besides fixing the obvious broken stuff, a usability test is valuable in exposing an inefficient or cumbersome UI. As a developer, it is very easy to overlook the complexity we sometimes build into an interface because we are so close to the design. The usability test gives us an opportunity to take a step back and see things through the eyes of our users. Personally, I found this to be very valuable in making me more empathetic about the applications I build. After conducting a few usability tests, you'll begin getting a really good sense for what users find simple and what is difficult or annoying for them. You can leverage this knowledge in your next design and I believe you'll find your skills around designing UIs will start to improve!

Usability testing is most effective when used in an iterative manner as part of your overall development process. Although doing a usability test at the very end of the dev cycle is still better than not doing it at all, the biggest benefit (saving time and money up-front) is lost. The best usability tests uncover the flaws before you enter the coding phase, which is why I find testing with a low-fidelity (i.e. paper) prototype such a powerful development trick.

Testing a low-fidelity prototype is really not much different than testing a real, working prototype. Instead of having a computer to interact with, the users will interact with the individual pieces of paper that represent the screens of your application. In a low-fi usability test, the user will utilize a pencil or pen as their input device, rather than a keyboard and mouse. Instead of a computer providing the necessary prompts and results, this will be carried out by a human participant playing the role of the computer. Other than these relatively minor differences, the end goal is the same...capture notes on the system usability so that you can fix bugs and simplify the UI. The big "bang for the buck" in low-fidelity testing is the fact that you haven't written any code yet, so changes are really easy and really cheap. To redesign an entire screen requires no more than grabbing another sheet of paper and your markers! After you go through two or three iterations of your design and test cycle, you will have a great blueprint for how the application will work and increased clarity on how to move forward (no more staring at a blank screen wondering, "Where do I begin?"). Best of all, you're much more likely to deliver an application that your users will love to work with right out of the gate.

So now you've got an idea about what usability testing is and why you might do it. I hope that you see it is really just a logical component of good UI design and that it can allow you to produce a higher quality product than you might otherwise deliver. Next time, we'll look at some of the specific techniques involved in usability testing. I think you'll find them very simple to do while yielding very important results.

*No actual guarantee is implied, inferred, suggested, etc., etc. You're on your own here, pal! ;-)

Labels: , , ,

permalink | leave a comment

Wednesday, May 30, 2007

The Low-Down On Low-Fidelity Prototyping

(I had a lot of time sitting around the airport after ILUG, so I wrote another of my dissertations...lucky you...hehe ;-)

You don't have to be on this site for very long before you'll start picking out some common themes. Two of the topics that I am very passionate about when it comes to the development process are low-fidelity prototyping and usability testing. I truly believe that every developer (no matter what their preferred technology) can reap enormous benefits by adding these two simple techniques to their development methodology.

On the most recent Taking Notes podcast, I mentioned I have some articles about usability testing coming up. Well I do, but I thought it might be a good idea to cover the first of my two 'secret weapons', since usability testing actually follows as a logical extension of low-fidelity prototyping. With that, let's first define what low-fidelity prototyping is about. Due to its RAD nature, most Notes developers are very familiar with the concept of prototyping. In the case of low-fidelity prototyping, the word 'fidelity' refers to the level of detail in the design itself. That is:

Low-Fidelity = Quick & dirty hand drawn screens

High-Fidelity = Polished design or high-quality screenshots/mockups

Another name for low-fidelity prototyping is "paper prototyping" and perhaps this name more fittingly describes what you use in the process. I prefer low-fidelity prototyping because it sounds more impressive, and if I were a consultant, I could probably charge more (haha...OK...only kidding!). The purpose of the low-fidelity prototype is to allow you to design the interface of your application before you focus on anything else. Some developers think I am committing heresy when I say this, but I believe without a doubt that you can design a better application if you build the interface before you write any code!


One of the first benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. I think you'll be surprised at what additional information you uncover so early on. There are several other benefits that low-fidelity prototyping brings to the design process, but first let's take a step back and talk a bit about how you build one.

Perhaps one of the neatest things about low-fi prototyping (that's what the cool kids call it) is that it is so easy to do...and dare I say...a lot of fun. The tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. The low-fidelity prototype is not meant to be polished. It's just a 'rough draft' of your screens. A lot of great work in design and engineering was initially conceived on the 'back of an envelope' and the concept is the same here.

To get the most benefit from this technique, you need to draw out all of your interface elements. This includes screens, menu items, dialog boxes, etc. Place only one element on a page (e.g. if you have 5 dialog boxes, use 5 sheets of paper, one for each dialog). This makes it easier to manage your design, especially as you work through multiple iterations. That's really all there is to it!

As you are beginning the work on your low-fi design, remember that this is the ideal time to 'think outside the box'. Try to forget the constraints of your development platform and instead focus on how you can design an interface that will be clean, efficient and easy to use. If you have the luxury, I think the ideal state is to stay technology agnostic. Design the interface, figure out what functionality is needed and then decide on which tool is the right one for the job. You can temper this with good judgment, of course. If you know you are building an application in Notes, don't design an element that you absolutely know you can't use in the client. However, some of the best interfaces I've made were initially born out of low-fidelity prototyping, followed by an exclamation of "There's no friggin' way I can do that!" A little perseverance and a lot of experimenting in this regard can pay off big time, though, so give it a try. The worst that can happen is that you fail, learn a lot from that, and then move on to plan B.

Once you have completed your first low-fi iteration, schedule some time with your customers to discuss it. See if they can understand the functionality without you explaining it to them. Are there glaring errors that are immediately evident or are they just bringing up subtle points? Make sure to take as many notes as possible, trying to capture everything the user points out or alludes to. You can often find important information in these notes...things the customer initially forgot to tell you, details on how computer savvy the user base is, etc.



So...You've built your prototype, met with your customers and got a couple of suggestions for changes. Time to go write some code, right?! Whoa, there partner...not quite yet. Unless you absolutely nailed it on the first try (probably not), it's time to build another iteration. On average, I'd say you'll build about three low-fi designs in a typical project. Each time, you'll refine and meet with your customer, coming closer to the final interface with each pass.

Let's return to discussing benefits around low-fi prototyping, since this is one of the stages where you really see a payoff. One reason low-fidelity prototyping works so well is due to the psychology of how we perceive quality. A user looking at an actual application on the screen is generally less apt to point out flaws, even if you only invested a little time in it. They think to themselves, "Gosh, he's already got something ready for me. I guess I can live with this, even though it's not exactly what I want." The customers tend to censor themselves, since they think you've invested time and money in the design. At this point, you might be thinking "Not my users...they hate everything and tell me so!", but most people will do this, just to varying degrees. Users generally have no problems, however, when you throw a hastily drawn piece of paper in front of them. When it looks like you had a little kid whip something together, the customer will definitely let you know what they think! :-) In fact, I suggest a little experiment. When you go into your low-fi meeting, strategically place some pens, pencils, crayons, whatever, in an area that the customer can readily access. I'll bet that when you set the prototype in front of them, they reach for one of those implements and start marking away. Let them! This is valuable, as it helps you see what they really want. It also gets the user emotionally invested in the design, which in my experience leads to increased satisfaction at the end of the project.

As developers, we benefit from low-fidelity prototyping as well. It may sound like this process adds time up-front and you're right...it does. However, once your prototype is pretty well finished, you've got a great plan for development. You won't be sitting there staring at a blank canvas, wondering how to start. Instead, the low-fidelity prototype provides great clarity and allows you to concentrate on the next important part of your process, actually writing the code. Also, since we've avoided code until this point, we've probably saved time and money. Often, the choice of interface elements we use dictates the most efficient path we take coding wise. Any time you start development by writing code puts you in danger of having to back track or rewrite in order to address UI concerns. Hopefully, you can see that capturing the specifics of the UI up-front helps mitigate these risks.



The definition, increased communication and clarity that low-fidelity prototyping can bring to a process is highly beneficial by itself, but it becomes infinitely more powerful when combined with our second 'secret weapon', usability testing. That's right...you can actually test your application using the paper prototype (how cool is that?) We'll explore this technique in a future post.

For now, let me leave you with a call to action. Give this process a try on your next project. It's certainly not hard and I think you'll find it very powerful. If your customers (or most likely your boss) look at you a little weird, be honest with them. Explain why you are doing this and the possible benefits (hint when dealing with the PHB* --> "It saves money!!!"). Let them know that it is a new concept for you as well and that you'll learn together. The customers will appreciate your openness and will most likely be willing to give it a go. My guess is that after the project, you'll be doing a lot more low-fi work.

Overall, low-fidelity prototyping is a super technique that I use all the time. I hope you find it as compelling as I do. Good luck!

*PHB

Labels: ,

permalink | leave a comment