UI DESIGN GUIDE - Web Application Design, Design Examples, Design Lessons » design methods

UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1

uidesigner — Wed, 21 Oct 2009 01:48:05 +0000

When I travel to conferences and speak with people about their agile UX experiences I come across a lot of repeat questions. Most of these pleas for help are about time management, rapid design sketching, traditional usability approaches, group design mentality, lack of support for UI development, and let’s not forget meeting burnout.

Even today UI designers hear the word AGILE and there mind is flooded with demon visualizations straight out of Dante’s Inferno. Why has this methodology caused so many headaches to UI Designers world wide? Why are they terrified? Can we beat them, or should we join them?

Generally speaking 90% of what a UI designer hears about AGILE comes from an AGILE practicing programmer that has succumbed to the second circle of hell and revels in the fact that you must join them. Let’s face it as UI, Usability Specialists, Graphic Designers, etc.. we work in a different creative zone. A zone hard for many developers to understand – Even if they want to understand.

Well, that’s about to change as I finally delve into some secrets of success. Rapid UI Design is not easy, it’s usually far from a “done” state, and even in a perfect world, the time to refine and refactor both your code, interactions, and design is hard to come by. In order to survive and thrive you need to look at practical solutions and solve real problems with the process itself. In order to truly excel you need to replace perfectionism with iterative perfection. You need to find a way to be a time traveler amongst all the chaos. You need to turn hell into paradise.

Cue flashbacks…..

Imagine it’s your first day on as a UI designer in a company. You are super excited to work in this vast field only to have your boss tell you.

Boss ”We work in a 1 week iteration agile development environment. ”

At first you may panic, you may want to quit. You may not even have a clue what Agile means . All you know is that you were hired on your UX skills and your damn awesome portfolio. You are still a bit light in the experience department, but are self-motivated and driven by a passion to create memorable, exciting user experiences. You have spent hundreds of hours refining small personal projects, none of them were quite near finished and you always had more time. Even fresh your college professors gave you a generous amount of time to come up with the perfect solution.

You turn towards your new boss and ask the simple question. “What does being an Agile UX designer mean to me?”

Boss “We try to build something quick and let our 200 users test it in the field, we then iterate and make refinement to the functional and design elements of an application. And by quick, I mean rapid development & rapid design.”

Now the sweat starts to build as you think to yourself? What the hell have I gotten myself into? All you know is that you can create semi-decent sketches of vague application functionality, but over the course of a week or longer. Time is your enemy, speed is your weakness.

Your stress level and blood pressure begins to rise. You start to frantically gasp for air, the questions racing in your mind.

How can I produce something that will immediately be built into a functional application.
What about my training in persona usage, usability testing, card sorting, etc…?
What about multiple sketches for each application path?
What about refinement time?
What about missing user stories or requirements
What about running out of time?
What about failure?

The questions just keep on coming as your pulse races. And then the boss chimes in.

“We know it’s hard work, but we know our audience well. We have daily SCRUM meetings, and have a direct channel open to our clients and customers. Our work flow is continuous. You’ll do just fine.”

As you stand there awestruck you are thinking “No…No I wont.”

Fiction Takes The Form of Reality

The preceding story was not fiction it was true story. Imagine you have 1 day to develop a new major application piece. You need to be able to quickly move from ideation to sketches, to wire-frames, and you have a deadline of tomorrow morning? Add on the fact that a large number of programmers are waiting on you? What do you do? At the most, you may get out two different designs. This my friend is how the fast paced world of Agile UI design works. Don’t fear it, but don’t let the process control you. (I’ll talk about this in another article).

There are several key factors that will help you tame the wild beast. Take a breath and let’s start to look at making the chaos manageable.

If you are one of the lucky souls that works on a well structured UX team this process becomes a bit easier (future article Architecture of a UX Team), but if you are a UX Team of One. There is a good chance you just messed yourself. It’s hard to imagine adding on even more roles to an already overloaded work schedule? Estimating time management, researching the problem, defining the problem, identifying primary and secondary application functions, sketching rapid paper-prototypes, understand stories (AGILE), Understand complex work flows, Refining the design, Gaining Buy-in, More Sketch refinement, and ultimately the next day ready to program. Wow! If you have ever experienced week AGILE iterations then you too might have felt this pressure.

So let’s take a look at this EXTREME situation first and then in future articles talk about refining the process itself.

Help What Should I Do First?

For this article lets imagine we are building a fictitious site called “babyspace” It’s a place for babies and is used to track developmental growth (I actually will cover this in another article as well from a design perspective.).

Step 1: Ideation & Brainstorming

You want to begin where you excel and that is brainstorming. Use a whiteboard, paper, napkin, toilet paper, whatever you use but make it fast, but also make sure you keep a copy. (I recently purchased a Livescribe pen and keep all my brainstorming sessions in there with recorded notes. It has helped me remeber the most intricate details of a brain storming session and saved lots of time.)

Hopefully, while you are doing this the business or you yourself have gathered up user stories (small chunks of functionality), and prioritized these. From the stories you need to figure out what relates to the user interface. Take notes and jot down tasks where you see a UI component being designed. This is going to help you immensely when you go to a Sprint or Iteration planning meeting. You want to be armed with as much knowledge as possible in both function , form, technology and design ideas.

Step 2: Ask The Right Questions, Who Needs What? Why Do They Need It? How Does This Benefit Our Users?

Do notbe afraid to ask questions. If you need to refine either your user stories or clarify your own UI tasks. Do it! Sometimes it’s easy to miss a crucial detail when you feel the clock is ticking. It’s better to get as close to the right answer before you start, as opposed to after you start. It’s not fun to rip apart a fully designed application or UI because a crucial story element was missing (Keep in mind this is different then actually refining your UI each iteration).

As a UX designer you want to know these questions so you can put yourself in the shoes of your user. If you utilize personas you want to match up your personas to these user needs and desires (preferably several weeks before the project begins). Always, Always, Always ask the following question:

How is this is benefiting our Customer ?

When a team looses sight of this redirect the conversation. I highly recommend asking this same question of your team in different ways.

“Why would a user need to do this?”
“Why would persona A care about this?”
“Is user really going to have a need to do this?”
“Does this make it easier for our customer?”

Restructuring and rephrasing your question helps to get people to notice the different sides of a story or requirements. It helps to draw out those that talk to much in a meeting and those that don’t talk at all. Engaging and intriguing questions will save you time.

Stay tuned over the next few months as I roll out Part 2 of this article. We will continue to cover lots of other tips and techniques, as wella s more of my process. Soon I’ll be able to notify my readers if my panel (core conversation) is choosen for the 2010 SXSW conference.

UI Design Dissection: Google Reader What Makes an Application Great?

uidesigner — Fri, 03 Apr 2009 15:21:40 +0000

There are some applications I never used or expected to use for more then a few days. And in any given week I try out about 10 – 15 new applications. I do this because I love analyzing and predicting new trends, design patterns, and visualizing work-flows. Usually, I end up with using 0 of these applications after a few months.

Google Reader has stood the test of time and now I use it daily and it’s party of my morning, afternoon, routine. Google Reader is one of these applications. It provides me a window into everything interesting to me. It’s information, knowledge, and power on demand. It is a phenomenal application but it has several flaws and annoyances that hinder my user experience.

For those not familiar with Google Reader, it is a RSS aggregation tool. Basically, every blog I keep track of (some 120+ blogs) is added to a list that then goes out grabs my RSS feeds from all my various sites and puts them in one nice window to read. There are two viewing modes. One is the ability to view the entire RSS text, or I can view the title of the post in a quick list. I personally found viewing all the text at once a much better way to get the maximum amount of valuable knowledge crammed into my brain.

What Makes Google Reader Great?

I never thought this simple application could be so powerful, but I use it every day and in different ways. The application for me has expanded beyond a simple one-sided user experience.

In any given day I may use it for any of these multiple activities:

Discovering new blogs and more content in my field
Locating new and exciting applications
Keeping up with the latest trends
Driving adoption of my own blog
Research
Keeping track of interesting stories
An archive..

One of the greatest features I use all the time is archival tagging. I frequently have about 400 posts+ a day to read. I use the tagging feature to mark research that is relevant to me. For example my tag list contains articles on “CSS Fixes, UX Methods, and my favorite “Web Applications: Category.” I basically identify new exciting or interesting applications and tag it to the category it belongs.

For Example: Application discoveries are tagged as followed: Web applications social, web applications shopping, web applications crm, etc.(see image to right). This is a very valuable tool because I may need to view reference applications for ideas, new patterns, etc. I simply click the tag and BAM! I get to see all blog posts I have ever tagged with this category. Now that is research power in your hands!

What’s Keeping Google Reader From Excellence:

A good IPhone application that will synch seamlessly
Better management to skip through groups of posts. I generally click the “All” button to read through an entire list of my newest posts. If you close your browser, jump into a new window sometimes the application forgets what is “new.” When you have 400+ posts staring back at you this can be overwhelming. I have to click next 40 times to get through what I’ve seen or already categorized. I want a button next to “next” that allows me to choose the number to skip. IE: Skip 20, 40, 60, 100. That way I can get back to truly reading just the newest posts.
The ability to recognize posts that are titled the same and have the same source will eliminate duplicate entries for reading. This generally happens when you subscribe to a RSS blog aggregation site. There tends to be a lot of overlap with blog posts and a way to filter would be awesome.
Better ability to connect with fellow bloggers
Social grouping abilities (I’m not sure what this would be but it may be neat) Consider I spend a lot of time in this tool compared to facebook, myspace, etc…

What Makes An Application Exceptionally Indispensable

In the case of Google Reader it I can sum it up like this: The application allows me to expand usage beyond it’s original design. It allows me to adapt it to my own work-flows, patterns, thoughts, ideas and creativity. The indispensable application allows me to use it how I want, when I want and, where I want.

The indispensable application is the simplest invention that allows for uses beyond it’s intended purpose. The application becomes so ubiquitous that we don’t even think about how it works ,we just know that it does work. You never question the wizard behind the curtain who is pulling the levers. You simply accept its ease of use and hope it never changes. That is the challenge we face when building exceptional UI. The search to find that happy medium is the difference between adoption and failure. It’s a hell of a lot easier to find the failures.

Life In The Fast Lane

I’ll leave you with just one more tidbit of information. If you are a UI designer always ask yourself, no matter what application you are building. Would I use this? It doesn’t matter that the application doesn’t personally apply to you. You can still assess the interactions. Is option A too cumbersome for even you to grasp? Is option B time consuming? Does option C have more steps involved, but causes less confusion? Does option D break accessibility? Does option E completely eliminate future steps? It’s up to you to decide how to drive the experience. After all the user is just along for the ride and they can easily hop a cab, hitch-hike or walk. You you really don’t want them to do that now do you?

Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?

uidesigner — Thu, 26 Mar 2009 01:35:20 +0000

I’ve been banging my head against a wall trying to figure this question out for some time now. Can existing in an agile development cycle truly create the best ui design? I’ve worked in Agile development environments. I’ve worked with structured project management. I’ve worked in locations where I am the project leader. If there is one thing I have discovered it’s that any process can be carried out so far to one end of the spectrum that quality and more importantly usability, and maintainability go right out the window.

How can a process that’s aimed at creating user stories and defining what the user “wants” be so misdirected? What happens when the process comes before the product? Can you really sacrifice usability for more features and rapid development?

What is this Agile You Speak of?

For those that have not worked in an Agile development environment let me give you a brief summary. Agile is a process that is truly geared towards test driven development. There are many forms of Agile. Some of these methods include, SCRUM, XP, LEAN. XP. While these different versions have slightly different implementation models they all are focused around developing and delivering slices of user stories (features) in an iterative process.

There are many books you can find out there on Agile Methods. Some of the leading industry experts include: Mike Cohen and James Shore. You can find a ton of information on everything from product owners, TDD (test driven development), user stories. What you can’t find is how the UI and the design fits into the process. In fact, in many books on Agile., UI is given 1 page or less.

Great Now Tell Me Where Does the UI Designer Fit in This Process?

This is a tricky question to answer. How can the end user experience be so outright ignored? More importantly in such fast development cycles how can a UI designer stay above the water? Is there someway to apply an iterative Agile design process to the UI development cycle. What are these guru’s of Agile missing?

I’ve read many books on the subject of Agile. My last count was somewhere in the neighborhood of six- seven. And would you believe out of all these books not one of them addresses any processes from a UI, Interaction design perspective. In fact many of the books just give the following worded mantra in some form or fashion “Leave the UI out till the end.”

In my quest to answer these questions I spoke with many prominent UI designers as well as designers within other jobs, corporations, in-house designers. No one can come up with a singular defined method of how a UI designer(s) works in an Agile cycle. There are tips, there are ideas, even some potential “best” practices, and external methodologies. Yet, designers for the most part are not factored into the developmental process. We are left to fend for ourselves. And if we don’t speak up we will be hit by the development bus.

Great Design Just Happens Doesn’t It Regardless of the Process or Technology?

Wait a minute! If you have actually developed software you should know that with PHP, JAVA, and .Net Programming choices made early on can directly effect the UI. In an effort to couple quick templated controls you often are stuck with manipulating the design to the control, include, etc.. You can find this in most every corporate environment, small design shop, etc. This can be especially true with inexperienced teams that don’t surface UI and allow it to be tinkered with as needed. Take .Net 2003, 2005 and more recently 2008. There still tends to be a tight coupling of design to programmatic elements. The point of this development tool is to help a developers quickly slap together something that is passable, rapid to produce and that “look nice.” Of course, looking nice doesn’t mean usable. If you read this blog you probably are well aware of that fact. I’ve had many arguments about the importance of design.

Great design has to be fostered and nurtured in your UI. It has to happen at an early stage, even if it is expected to change rapidly. The trick is having the skills, knowledge, research, methods, and tools at your disposal in the blink of an eye. If your a UI team of one you have to be lightning fast, organized, visual, and quick to think. If you are a UI manager you have to build and align your team strengths to each other and then unify that vision into one cohesive brand.

For now I’m not going to answer the question, but I want you to think. In what ways can a process aimed at produce working software for the users leave out the fundamental parts the users use? And why would some assume slapping a UI on at any point in the process produces anything but a mediocre product?

For those coming from an RSS there is a funny comic below:

Authors Note:

I’ve had this article in draft mode for some time. I wasn’t going to publish it but felt there were a lot of good points and strong arguments and methods to build upon in my two future articles. With that in mind I figured I would let my audience dissect it and provide feedback.

Design Experiences: Don’t Rub Your Product Experience All Over Me.

uidesigner — Thu, 19 Feb 2009 03:29:31 +0000

The other day I was pumping some gas at the gas station only to be accosted by the latest in drive by guerilla marketing. Nowadays, it is quite common to find little kiosks setup outside of major business selling everything from makeup to car polisher. It’s as if the strip mall has come to us. It’s like carnies are part of everyday life now. And this is where my story begins – (cue flashback).

All I wanted was gas, and I was in hurry. I’m pretty sure when I drove up I wasn’t holding a sign asking these kiosks to show me products. Nonetheless, I was molested and ask to partake of a product I had no desire to see.

What was I to do?

A. Say no thank you politely?
B. Hide and hope I wasn’t seen?
C. Say I have already seen the demo?

Since I had seen this demonstration two times already I was in no mood to even speak to the demonstrators. I just kept silent and thought to myself.

“Yes, you have a great product. Awesome, but I’m not interested in your cross-sell.”

Every One Surrender We Have You Surrounded

Here I was as were many other patrons, a captive audience to a product experience. I felt all dirty inside, and almost ashamed for not buying the product. Is this how a user should feel? Should a user experience ever be forced? Are there sometimes when it is forced?

Admit it! You are a user experience pusher. Over the course of many years I have come face to face with applications consisting of three tiers. The front-end (for users), the back end admin (for internal people, employees, etc..), and believe it or not Admin interfaces that admin the admin. In many of these cases the users of the front-end were treated to the golden carpet . The internal people received the tin carpet . The admin of the admins probably had no carpet.

The truth is application design takes time and when your audience is captive we very quickly remove features that improve the experience. This tends to happen much quicker and much easier on the internal side of things then it does for the end-user of an application.

Imagine you are one of those souls forgotten in the internal world. Your pleas for external quality software are often unheard and ignored.

I Hear You Crying but I Don’t Care

Over the course of many, many, years. I’ve heard a lot of horror stories from internal users.

“Why can’t our tool do this like it does for our customers?”
“Why do we have to use x system when it’s so slow?”

In many shops internal users are just not regarded as the highest priority. Typical internal applications developed for these types of groups are shoddy, buggy, poorly constructed, confusing, repetitive, and scattered. They are the Frankenstein brand-child of quick whims, crazy ideas, and unreasonable deadlines.

A Web Application Only by Name

Imagine a cluster of “dissimilar” reports:

These reports track customer information, data gathering, and user retention. Despite the different end results there should still be some commonality among these reports. The problem is the commonality is not properly identified. What happens is a person not trained in usability or any user centric process, has made the decision to lump these all into one system.

Why would such a thing happen? Usually, because it’s fastest way to just put “something” together. They are internal users and not as important right? Wrong, just because a user is internal should you ignore the cries for competent, excellent software?

Hell No! Poor applications can easily slow productivity, especially when an app is directly servicing front end clients.

Oh No You Didn’t Just Tell Us To Build Better Internal Apps

The hardest part about getting the same quality built into internal software as external software is getting buy-in from those in charge. Depending on the company there may be several layers of people involved – Managers, Bosses, Mafia. So what can be done to illustrate the power of providing a superior experience for a captive audience?

Analyze your existing applications and identify existing and expected commonalities – This is especially true when you are presented with the opportunity to build enhancements, features, or even bug fixes to an existing application. How will you know there is a problem unless you can point it out in detail?
Use actual “working” applications and do a side by side comparison of proposed benefits for the new enhancements. Simply put, illustrate by using the current system why it is bad and then turn back around with multiple solutions to fix the “badity” (new word copyrighted).
Cost V.S. Efficiency Improvement. This is a hard one to illustrate, but the suits (managers, mafia, etc) will expect to see predicted numbers. These numbers are most likely going to be way out of alignment with reality. It would be much better to show estimated time for current task completion with the old application process and then follow that up with your best guest estimate of the new functionality.

For example: We don’t have to go back to this 1 tool to generate the immediate on call reports for a customer on the phone. Now we can simply click this button and display all that information in the same interface.

And another example: By isolating all of these commonalities in reports A – Z I’ve determined a logical grouping order and how we can provide one dashboard and a single input to access and run each report.

If none of the above works QUIT, or build out the functionality in your own spare time. We all have pet projects going on in the background and practice makes perfect!

Experience Cleanup Isle 5 Please Come Again

Fortunately, I can change my gas pumping experience by switching brands, stores, etc. Generally, captive audiences don’t have that luxury. It’s your job to make sure the tools used external and internal are bult to exceptional levels of quality. Who else can champion the cause but the User Experience Guru?

Blog Response: IE 6 The Devil Not In Disguise

uidesigner — Thu, 12 Feb 2009 16:46:20 +0000

The other day I came across an interesting article “Stop Developing for Internet Explorer 6” . My initial thought was great I finally can stop developing for IE 6. Of course, that was just a pipedream. On many of my applications I still have a large captive IE 6 audience. Unfortunately, I can’t quite yet yank the rug out from them and force upgrades.

IE 6 gives me headaches beyond belief. Instead of developing standardized code. I sometimes have to bastardize the syntax. Even when using my own modified reset.css style sheet inspired by Eric Meyer there are still issues that pop up that cause additional work.

IE 6 is a demon that still won’t go away. Sadly, I still have to make my time sacrifice to the demon. I can only hope that Google Chrome will solve IE 6 issues sooner so we as experience, web application, and web designers don’t have to suffer through the tortue and pain of a relatively new browser on the scene.

The Most Important Questions to Ask When Building A Web Application UI.

uidesigner — Tue, 10 Feb 2009 06:08:28 +0000

You didn’t think I was going to reveal it so quickly did you? Of course not, I like everyone to learn a little bit before they get the answer. There is nothing wrong with being forced to think a bit.

Let me back up a little and begin there. The other day I was driving home from work and recently started on a new UI project. I was going through my normal routines when presented with a project.
I start to ruminate over all the things I can do and how all the various functions of this new application would tie together. As I pondered this in between paying attention to traffic and driving, one core question popped into my head. A light bulb snapped and thus this article was born. I realized just how many designers, and developers, forget to ask one magic question.
Maybe they are strapped for time, burned out, or whatever the reason might be. You need to ask yourself this question!

Would I use my own application?

Would I use this application. At first glance it is such a simple question but extremely valuable and woven with complexity. By knowing the answer you begin to discover unknown paths, problems, and practical answers to otherwise obtuse solutions.

Frequently, when I’m working on a new application with a development team I have to stop them a minute and get them to think about what we are trying to build. Not from a developer, QA, BA, Interaction Designer, UI Designer, System Architect, SQL Developer, perspective but from the person using the tool.

Walk A Mile In My Application

I like to think of it this way. It’s easy to make a pair of shoes, especially if you don’t have to wear them. Nails can stick out of the heel and the fabric may be torn. I still get an A for effort right? WRONG!

Another comparison would be just like the athlete who advertises how great a product is then turns around and uses another instead. Wouldn’t you as a user / consumer feel cheated in some way?

A true life example recently involved a function and feature for inter-application navigation. The feature was supposed to allow the USER to quickly change between editing different individuals’ information.

“A user could quickly change between various people and edit them rapidly.”

It sounded like a safe idea on the surface, but here is where the problem existed. We started by examining all types of ways to make this feature work and be non-confusing to a USER. I tried chunking the information, grouping it in different ways, larger titles, more prominent text. No matter what was tried in the current framework it was still extremely likely for the USER to get lost and more importantly loose the context of the initial task they were trying to complete.

Should We Design for the Sake of Design?

So I sat back a while and thought about the problem. That is when the answer hit me. Why? Why are we trying to let the user do this? Why were we trying so hard to fit a square peg into a round hole? Of course, every group had their own answers:

Developers – “It would be great if a USER could manipulate the data quickly.”
QA – “It works and does not break functionality. What is the problem?”
Business Analysts – “The user should be able to do this function (but why?)
Interaction Designer – “There must be a solution to this to make it highly usable and fit into the requirements.”

Now let’s back up a second. What about the task itself? Why would a user care about editing multiple individuals quickly? The quick untested assessment was “Users sit down and want to edit multiple people at once.” That was the expected reality but taking a step back and analyzing the task step by step the team discovered that there was absolutely no need for 99% of the users to do this task. They just would not use this system or this feature in the way it was envisioned. If I was editing an individuals information it was because I was either:

A. Talking with a customer recently and discovered changes to this information
B. Made a mistake when entering information and wanted to correct the information.

In either case we had other methods to handle these scenarios. What we didn’t have is a way to mass edit a single individuals information (usability and focus group testing should be conducted to figure out if that is needed). No matter how much everyone wanted this feature we really had no need for it. It was cool but as you read in previous articles that is not enough to justify its importance in an application.

So when you are developing or building a new UI. Ask yourself these questions:

1. Would I use this application (feature)? If not why?
2. What are the tasks the user is trying to complete?
3. Are there too many tasks complicating a single workflow?
4. Does my UI or application framework have enough flexibility to support these new functions?
5. Have I been consistent in my UI framework?

So ask the question and challenge the team to give the “why”. Why are we building this application? Why should we build this application? Will our customers or more importantly will I use this application?

Book Reviews: “Web Form Design Filling in the Blanks”

uidesigner — Thu, 05 Feb 2009 02:34:03 +0000

I highly recommend Luke Wroblewski’s book “Web Form Design Filling in the Blanks.” I first came across this book many months back and since then it has retained a coveted spot on my reference shelf.

An interesting thing happened the other day that made me think of this book. Cue flashback!

The other day I was looking at a registration form built for a development group and it was quite possibly the worst form in the world. It was one continous line of form elements strung together. It was way too obvious that the forms creator only cared about function. It was at that moment I was thinking just how much I would like to undo this crime against web design humanity and mail this Dr Frankenstein a copy of this book. Hell even one page of the book would have provided this “coder” with a semblance of design knowledge.

In the book Luke explores real world application implementations and illustrates how a simple design change in a form can mean the difference between success or failure. The part I liked best about this book is it’s numerous examples. Inside it covers in some shape or fashion all of the following: form errors, required fields, layout, form element grouping, and accessibility issues.

A Word About The Book

After hearing Luke speak at a few events I was immediately excited to read this book. I know what you are thinking it’s a book on forms. How could it get any more boring? Well, this is quite to the contrary. The book has a very light tone and tosses in lots of interesting case studies. For example one study focuses on the different variants of button elements. Should they be colored? Perhaps they should be different shapes? Should the primary function standout from the secondary?

Believe it or not there are a ton of things to think about when designing a form. I recommend you grab a copy of this book. Even if you choose not to read it all the way through having it around for a reference is a smart thing to do.

Did You Know Paper-Prototyping Adds Value If Done Right?

uidesigner — Thu, 14 Feb 2008 14:12:13 +0000

First off let me state it’s been awhile since I have posted. This is mainly because projects have kept me busy.

Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.

The overwhelming response to paper prototypes that I have personally faced is: They don’t seem professional, are hard to read, may be difficult to understand complex web actions. These people need to quiet down and listen. Paper is cheap and easy to modify on the fly. Paper prototyping is more than just showing a piece of paper. It’s about defining, refining, and streamlining the interaction between the user and the proposed widgets, functionality, etc. Paper and markers and traditional means can represent all these concepts with little difficulty. You just have to get a little creative at times, but the new ideas that come from these paper prototyping sessions can point you in a new direction.

Several times I have worked through a prototype with limited customer feedback(not recommended) and discovered core application function that was not identified. By discovering this up front you can better prioritize absolute functions from secondary functions. IE: I need to be able to save my book title, but I also need to give it a custom save descriptions.

Customer: “Wow, we never thought about that. We just wanted them to save the book using the title as the saved name.”

You may even discover larger problems such as entirely missing pieces of functionality.

If at all possible you should involve the end customer of your product. I’ve been trying to get this practice cemented into our process but it’s not an easy one. The general premise is this; everyone feels they are right and specs were translated correctly into business needs. It kind of makes sense that you need the customers input to ultimately test the system? However; this type of input rarely seems to happen at the level required. Focus groups, usability testing, is an afterthought and tends to be reactionary instead of proactive