Edge of Chaos | Agile Development Blog

Overall the recent Agile 2009 Conf. in Chicago was a good event. Unfortunately, the first two days were not quite what I expected. Combination of just “OK” sessions and jet lag left me wondering whether the trip was worth it. However, the following two days were much better, but the very last, Jared Spool’s keynote, left no doubts that Agile 2009 was totally worth coming to! An absolute killer presentation on User Experience with an excellent steak on the side (yes, Americans know good steak) – what else could you ask for?  A lightning bolt, a hit, all of the above - I can hardly express how enlightened and inspired I felt walking out of the ballroom where the speech took place. And that’s when reality hit me, and I suddenly understood how bad we suck with our User Experience… I got depressed for about 2 days, but then I started to act.

I read several books about User Experience. I read countless articles, forum threads, blog posts on the same subject and finally started a process of searching for UX specialist to add to our development team (and we hired him already). I’ve dug through all the information about UX, UI, Design and thought about how we could integrate it into our development process.

In one month I came up with a vision. I created interesting presentation and shared my vision with the team and inspired them. They applauded (thank you, folks!). I believe Agile and UX is a great mix. Definitely it is not easy, but I think it is a right path to follow. We want to create the best agile PM software in the world, and it is just impossible without outstanding user experience.

We want to share all the new experience about the journey. I’ll post more about process changes, mindset changes, education and whole team involvement. Here is our first try, see how we are re-designing ToDo list in TargetProcess:

• Personas
• Scenarios
• Wireframes - part I (part II, part III)
• Prototype and Usability testing results
• Improved prototype
• New ToDo list in TargetProcess

Fact: Complexity causes 50% of product returns

Fast and easy-to-use applications are quite rare. Simplicity and Performance are two major properties of any killer software product. We, as software developers, should pay attention to these properties as non-functional requirements, but in real life we often tend to implement more features, more functions, more settings, more, more, more… The race is hard to win with this strategy along the whole way.

I must confess we’ve done almost the same to TargetProcess. We went on with providing more and more features and options. Definitely we tried to keep the application simple and fast, but these goals were secondary. We’ve stopped. And changed.

Now we are focusing on better performance and usability. We think that TargetProcess is a quite feature-rich application that fulfills most needs in agile project management. It is time to stop and find answers to the questions: “Where do people get stuck with our software?”, “What is complex and how it can be simplified?”, “How to make TargetProcess enjoyable to use?”, “How to make TargetProcess the most performant software in our niche?”. The questions are hard to answer and address quickly, but we are looking for the answers.

Steven C. Seow wrote an excellent book about principles that should be taken into consideration for any “performant” application Designing and Engineering Time: The Psychology of Time Perception in Software. I read it and want to share some interesting observations.

Hick–Hyman Law describes the time it takes for a person to make a decision as a result of the possible choices he or she has. Simply speaking, less functions — simpler and faster choice. It leads to several conclusions what we should do as software developers:

• Minimize options. Obviously, if you have 50 elements on the screen, it takes time to choose which action is required. If you have 20, the UI is faster to work with.
• Keep it simple. Well, it is a general principle for all the facets of agile software development.
• Short system messages (10 words max). People don’t have time to read long messages. Delays kill usability.

Some concrete numbers from the book:

• Response time of typical action in the application should be about 2 seconds.
• If response time takes more than 5 seconds, it is required to show a progress indicator. User should know that system is working on the task.
• If system response time is more than 7 seconds, people tend to leave web site or switch to another task. It breaks interaction flow.

Noticeable Performance Improvement

If you are going to improve performance, it should be faster by more than 20%. Otherwise most people will not see the difference (it was shown in some researches that performance difference is noticeable in a range between 10% and 18%). For example, if you are improving search function with 10 seconds response time, it is required to make response time at least 8 seconds (or less).

Flow

Flow is very important for good user experience.

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Our goal is to make the Flow possible. I think it is the hardest thing in software development.

When user opens an application and sees complex UI, it is frustrating for him. Application should match user experience and skills. Simple or Advantage modes, clean and simple UI (Hick–Hyman Law!), balanced options and functionality — this sounds familiar, but hard to develop.

• Distinguishing decorative from meaningful elements in UI design. Ryan from 37signals shows how small decorative elements may influence usability.
• 10 Useful Techniques To Improve Your User Interface Designs. I am not a big fan of articles like “99 advices to web design”, however this article is really useful. I especially like number 3 “Using contrast to manage focus”, number 8 “Custom input focus” and 9 “Hover controls”. We are going to use hover controls in v.3.0 design.
• Konigi.com is a great resource for UI developers. Many very useful links and examples.
• 2008 - The Year In Pictures. Nice photos. Nice atmosphere. Taste the last year as a good wine…

99% of web applications have add forms. Most of them have edit forms as well. It is really hard to imagine how you can add/store something without a form. OK, there are some ways like: import something from CSV file or another format, create something from incoming email/SMS/etc., capture image and create something from this image

Still if you need to add something quickly, in most cases you will use a web form. Obviously, if you need to edit something you will use web form as well. Is it the best solution? Can we get rid of edit forms? I bet we can.

Most applications has View page. It represents information in a more readable and usable format than a form. And to change one property you:

• Click Edit link and wait for new page to load.
• Change the property.
• Find and click Save button.
• Wait for previous View page to load.

That’s quite time consuming process. I think the better way will be:

• Double click property you want to change.
• Type new value.
• Push Enter to save the new value using AJAX.

This way has several advantages. First, you don’t need to create edit forms (ok, but you need to implement inline edit). Second, you provide much better user experience. Third, you get rid of Edit links everywhere, which is good (less complexity and less links is always good). That is something we are going to try in TargetProcess v.3.0.

I’m working on new lists in v.3.0 already and wondering how 37signals managed to create several web applications with no traditional lists. OK, there is one list that shows time records in Basecamp, but as far as I know there are no other such lists. All the other lists are very simple and well formatted. All 37signal’s applications look simple, with fresh air and the first expression is very good.

Typical list in Basecamp:

The only traditional list I found in Basecamp:

Now I wonder why that happened. Maybe data volume in Basecamp is low? Maybe they are just super-smart folks (well, no doubt here)? Also I wonder whether it is possible to get rid of traditional lists in TargetProcess. Is it possible at all when people want to prioritize 300 user stories in the backlog (yes, we have such requests from customers!). Is it possible to get rid of usual lists when you receive dozens of support requests daily?