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?