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

During the course of this research I used many front-end UI interfaces and house databases. I came across one such search that was extremely tricky to use. Notice the image below and see that I am required to type in a zip code, but then I am presented with a GIGANTIC list of options in a multi-line text box (some 100+).

So here is the challenge to the community. If you want to participate great. For this particular problem your goal is to come up with a new and better design for the interface presented. If you want you can post a comment that goes to your design illustration etc, or you can simply e-mail me and I’ll be posting some of the entries here along with author and web site link.

There are no prizes. This is strictly for education purposes. There are no right or wrong answers. On To the challenge!

The Challenge:

Area Search OLD WIDGET

My Example:

In my example below I took two routes. One allows the users results to be filtered down to a smaller number by choosing the area in a drop down. The other route I added some interactivity with the mouse. Based upon the 2 filters search type, and area a user could click the “LET ME DRAW IT” and would be presented a zoomed map of the region. Then they can simply draw a box around the region of interest. Click search and then a number of different things could happen. A user could see houses pop up on the map, they could see a directory listing to the right. The point of this challenge is to design something different and hopefully better than the original

My New Design Prototype

Your Design Examples:

Related articles:

1. UI Design Patterns: Exploration of Data and Visual Imagery in Application Design
2. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
3. UI Design Dissection: Google Reader What Makes an Application Great?

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?

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?

1.  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?
2. 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).
3.  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?

Related articles:

1. Blog Response: IE 6 The Devil Not In Disguise
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. The Haves, Have Nots & Feature Bloated User Experience.

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.

Related articles:

1. Blog Response: What’s Your Design Sign?
2. Blog Response: Do You Love Wireframes?
3. Blog Respose: Bowman Leaves Google

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?

Related articles:

1. Corporate Conflicts A Cantakerous Cacophany of Confusion.
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?

Believe me I have seen some crazy ideas about what a “good application looks” and functions like. Next thing you know you and the rest of your team are throwing around generalizations about things such as:

• one color is better than another
• one navigation is better for the users than another
• one feature is more important
• one bug is higher priority
• design is secondary to function
• one technology is better to use than another

That’s just a short list. It’s easy to see how on a daily basis we encounter these conflicts that can disable, disrupt, and derail a development team. If your team is larger then 5 people this can drastically change your time line. How can you eliminate conflict? Well, the short answer is you can’t, but there is good news. You can begin to identify your sources of conflict and the impending arguments and cut them off at the pass.

Now every once in awhile there are members of a team that are not “team players.” They have such passion and zeal for their work that they cannot and will not back down. Even after reprimands, and threats, and warnings. Your final recourse may be to remove the broken wheel from your team. This happens in corporations as well as independent design teams. Sometimes there is just no recourse, and if you are in that situation and have exausted all your other conflict resolution chances, do you have the balls to make the decision to transfer, or remove the problem?

Stay tuned for more on this topic.

Related articles:

1. Features In The Front Usability Get To The Back
2. So what is this corporate thinkers site all about?
3. Blog Respose: Bowman Leaves Google