Agile UI Design Series: UI Design in an Agile Project Cycle Part 1

By  |  2 Comments

Welcome to my three part series (so far), delving into real world UI experiences in relation to  Agile Development Methodologies. In these three parts I will explore solutions, problems, and suggestions for dealing with the various phases of an agile development cycle. More importantly, this will be from the point-of-view of a UI designer.

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.

  • kpinnh

    Intriguing introduction, and very relevant to the project space I’m in now. Would love to see the follow up articles you alluded to…

  • Anonymous

    Never sacrifice poor UI? I’d gladly sacrifice poor UI!