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

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.

Related articles:

1. User Experience Design in an Agile Development Cycle
2. UI Design News: Vote For My Agile UX Panel At SXSW 2010
3. UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1

Agile Why All The Fuss?

Agile development is all the rage, but it has been frequently stated by UI advocates that agile development encompasses design processes that don’t work well together. In some cases I have found this to be true and in others you have to adapt your own design processes to just work better.

In this first article I will outline a few techniques that can help you cope during the pre-project planning stages. My hope is to expand upon this conversation over in the forums as well as in future articles. 

I’ve been wanting to do an article on this for some time and hope this article spurs comments, discussions, and relief. Thousands of designers struggle with this daily and the content on this topic is few and far between.  Let’s begin.

And so Our Story Begins

I’m not going to go into details about methods of Agile Development, for that please reasearch agile here. 

There are numerous articles out there on the Internet about agile from a development (web developer) point of view. However; what is next to impossible to find are articles from the UI designer point of view. This is about to change!

A lot of the varied camps of agile development (lean, xp, etcc.) are focused on the functional aspect and do not account for the usability, or visual aspects of the application. 

It is for this very reason, tension, debates, and arguments among  both developers and designers are vast. Is there a common ground? Is there a place for ui designers to excel? Does building an application too quickly cause it to suffer?

5 Things To Accomplish Before The Project Starts

Long before a project begins there is time to design. This is time that is generally outside of a “normal” agile process. And in many cases way before a story session, a load zero, iteration, sprint etc. This is when the design has time to grow and be defined. This is a time to build paper proto-types like no tomorrow. Here are 5 things you want to accomplish during the first few weeks before a project begins.

1. Prototype and start figuring out your base interactions for your applications

Generally, developers will be hot on your trail and itching to begin code. It’s important to sketch, re-sketch, and then walk through your design(s). At this point you should start isolating your applications primary & secondary functions and any AJAX like interactions etc..

You can do this a number of ways.

You could conduct a paper proto-type session or preferably many with an internal, or external audience.

You could wire-frame or even do some base graphical mocks and test with those. 

Worst case scenario sit down yourself or with the project initiators and walk through the flow. Note problem areas, and then discuss with the team technical or design hurdles as soon as possible. I find interactive PDF’s to be highly valuable during this process.

2. Distribute and publish your designs before hand for the whole team

You want to make sure everyone has a good idea of the designs vision. Make the designs available in as many formats as possible. A great way to do this is to have a bulletin board setup with all the current designed prototypes. This works a lot better if everyone can constantly see the design (shared workspace, etc). Better still make the design available for the end-users. You may have to let them know this is a work in progress and that you really want feedback on anything.

An alternate method would be to give print-outs of your designed wire-frames to all project stakeholders. They can draw, doodle, or do anything they want without fear of meeting criticism.

3. Identify Conflicts

Carefully, start to explore the expected interactions. It is entirely reasonable at this point to start identifying small problems and even technology limitations. Identify any constraints such as technology, speed, usability, accessibility issues, manpower, scope creep, feature bloat, cost, time.

Know your limitations before hand. It is normal in Agile for the business user to have some definition of what they want in the product. Even at this early stage you will find tremendous value by knowing your limitations up front.

For Example: imagine you are building a new mail system. It’s pretty easy to map out a mailbox, but maybe the client wants more social networking tie-ins, like the ability to tie a contact to a network. As you start to explore this option you discover you have no way to organize these potential massive networking groups. Make note of this (on your proto-type). Above all Make sure these problems don’t get lost in all the project noise.

Another Example: You are trying to implement some pretty tricky and database intensive AJAX. By implementing this “new” technology are you going to hinder the perception of speed? If the user has to wait for the data to flow from the DB. Can your database handle these asynchronous calls? Would it be wiser to change the design to limit this type of interaction or the amount of data? 

One More Example: When building a dashboard you quickly discover the business wants to include way too much information for the viewable area. Items need to be paired down to the most important chunks before you can proceed. What new design mechanism do you need? Perhaps, you need to come up with some hidden tab-like structure that appears to make viewable space more.

Conflict is going to slow you down the most and being prepared with a quick solution(s) is going to save you pain, frustration, and anger.

4. Build Flexibility

In an Agile process, one goal is to refine and iterate on the design. If you build your design too rigid you are going to be in for some painful changes. Keep in mind one, two, or even three alternate design patterns for core application function.

When I talk about building flexibility I also mean CSS and  javascript functionality that is too rigid.  Adhering too tightly to a cascade can hurt you later on. Trust me, I’ve been in that situation. Only do enough so as to allow your CSS to do what it was designed to do. You may want a Swiss-army knife when all I really need is a can opener.

Another flexibility issue revolves around the dreaded over design (adding undo complexity).  Never try to force newer design patterns into a box they just weren’t built for. I really like how Robert Hoekman, jr.  describes experimenting with new design patterns. In his book “Designing The Obvious” (great read)

And I paraphrase, “Don’t just re-invent, but elevate“.   That is to say, make a current design pattern obvious, but better than its predecessor.

It’s great if you have a new idea about an existing pattern, but remember to not be so radical as to alienate your users.  (Look for more on this in a future article: Alienating Users With Obtuse Design Patterns).

5. Be Prepared To Change 

It’s going to happen,especially in these first few weeks. Agile focuses on getting things to a done state and sometimes done doesn’t include all of the features that complete the UI. There are may times you will have to adjust course and steer in an entire different direction. This is frustrating and it can drive you mad. I find the hardest part for myself is trying to accept this change. Change becomes even more difficult if you spent many hours going one direction only to have turn around and devise new concepts.

I’ll leave you with some final thoughts:

• Just because the design can rapidly change,  never sacrifice poor UI for the sake of just “getting it done” that is a slippery slope you don’t want to fall down. You need a strong foundation as the base of your UI. Leaving this up to chance is going to bite you in the ass.
• Agile development moves quick, and you have to be quicker, than the quickest developer. (depending on the methodology of course). The ability to multi-task and manage your time is extremely important. Don’t fall behind!
• Embrace the rapid change and have as many people test, break, and find flaws with your design as early as possible. One of agile’s big tenants is to fail fast. Put this methodolgy to work for your design.

Don’t forget to head over to the forums  to continue this discussion.

In the next article I’ll be covering what happens during the actual agile development cycle. This is when you as a UI designer become super human in your ability to manage work flows, tasks, design, and oh so much.

Related articles:

1. User Experience Design in an Agile Development Cycle
2. UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1
3. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?