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.

Related articles:

1. UI Design News: Vote For My Agile UX Panel At SXSW 2010
2. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?
3. Agile UI Design Series: UI Design in an Agile Project Cycle Part 1

What are the benefits of Hybrid Prototyping & Mocking?

• More reliable layouts that fit expected content layouts (better predictability)
• Quickly create complex and realistic widgets
• Rapidly develop new HTML controls
• Use each tool (expressions, notepad, Photoshop, illustrator, acrobat) to its strength

Step 1: Build Your Design Library?

When building a new web application, or widget I usually fall back on my base CSS styles for initial mocks. If you do not have a base set of styles. I suggest you build a CSS library. With only a few lines of code you can quickly create many different application widgets and their look. This is especially true if you have a standard corporate or company brand you need to follow. Here is just a quick sample of the table code I use when doing table structures.

/* Used by the other data grids */
TABLE.grid {
 border-collapse: collapse;
 font-size: 13px;
}
TABLE.grid caption {
 font-size: 13px;
 font-weight: bold;
 color: #F6F18D;
 vertical-align: middle;
 text-align: left;
 padding: 5px 0 5px 3px;
 margin-top: 20px;
 background: url(images/header_background.gif) no-repeat center left;
}
TABLE.grid TBODY TR {
 vertical-align: top;
}
TABLE.grid TBODY TR TH {
 font-size: 11px;
 font-weight: bold;
 vertical-align: top;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
 padding-top: 10px;
}
TABLE.grid TBODY TD.alternate {
 background-color: #EEEEEE;
 padding: 2px;
 height: 14px;
}
TABLE.grid TBODY TR TD {
 font-size: 11px;
 padding: 4px;
 height: 18px;
 text-align: left;
 border: 0px 0px 0px 0px;
 border-style: dotted;
 border-color: #B8660B;
}

 The above code is just a small example. The goal is to build out the code enough so you can simply class/id at the top of your table and then let the cascade ripple through the table elements. If I simply removed the <tfoot> or other elements I can quickly make my table look twenty different ways with only the simple class /id  at the top.  Using this same process I would build out divs, legends, fieldsets, and form elements.

I can mock up a drop down in Photoshop in about 10 minutes, or using this method I can do it in about 10 seconds. If I put more widgets to use In this way I can build out custom screens very rapid. Even more to the point I am using my actual library so I may be coding real world code that could easily be used in the final web application.

Step 2: Screen Print Is Your Friend and So is Screen Capture

Now that I have some custom widgets built and displaying on the screen I can capture the screen and begin building out my widget folders in Photoshop. I usually would create new Groups (folders) inside my Photoshop work space.  An example folders structure: Data Examples, Search Bars, Buttons, Grids, etc..
Using our little friend cut and paste I’ll start placing my pieces into the appropriate folders.

The goal is to get frameworks of your widgets. You can then use Photoshop to “spice em up,” or change them into other designs. You could even create some text examples to lay on top of your various frame-worked widgets. I usually end up creating my containers, and supporting images in Photoshop / Illustrator since that is the best tool for this job.

 Step 3: Build It Out and Tie It All Together.

Start building out your new application interface. I’ve found that using both an HTML design tool and Photoshop in tandem I can quickly pull together a design in a matter of hours. The quick benefit of this is that your design nows uses actual sizes and even actual (potentially production) code.

When you have some screens you like save them out as JPG’s. Next your are going to open up your JPG’s inside of Adobe Acrobat. Merge all of your related screens into a new PDF. Now go ahead and go to your first page and look for the interaction point you are looking to simulate. For example clicking a link pulls up an AJAX edit screen. Select the “ARTICLE” tool and draw an area around your interaction destination. Be sure to name it something you will remember. Now you want to go ahead and select the “LINK TOOL” and draw a link area around where you want your interaction to occur. You should see a popup.  Choose the following “CUSTOM LINK > ACTIONS > READ AN ARTICLE > Your named article area. Repeat this process and you now have an Interactive PDF MOCK.

Summary

In this article we looked at why Hybrid prototyping can get you to a visual interactive mock faster. We learned about creating a CSS library to speed up the process of creating these mocks. We learned how to create an interactive PDF.

Related articles:

1. UI Design Software Review: Flair Builder v1.6
2. SXSW 2010: Live Stream Day 2 From SXSW 2010
3. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?

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

Related articles:

1. Which Widget is the Right Widget for My Application Design?
2. When is it the Right Time to Use Icons?
3. Design Experiences: Don’t Rub Your Product Experience All Over Me.