Edge of Chaos | Agile Development Blog

Sketching is not so hard. It is really interesting to sketch something with basic tools. Here is an attempt to sketch a Mind Mapping tool for iPad. It is real fun to sketch for a touch device. In fact, that was our first experience with paper animation and video techniques, but I think the end result is good enough for 6 hours of work (taking into consideration that we’ve learned iMovie on the go).

The application is pretty simple. You can create nodes and connect them, delete and move nodes — all with simple gestures.

The video goes at 2x speed. It is more dynamic this way, but maybe  some details are lost…?

Read first part of the review.

Evaluating Design

There are two important aspects of design process: generative and reductive. We generate a set of alternatives, then we restrict this set based on various criteria. It is impossible to evaluate a solution without its alternatives.

The best way to a good idea is to have lots of ideas — Linus Pauling

I can’t critique just one thing — Richard Sewell

That is one more reason why sketching is so powerful. It helps to generate and evaluate various alternatives. I’ve read in one article that Apple creates a dozen alternative designs for any product. Good enough…

One of the most positive form of criticism is a better idea

Acquiring positive attitude to criticism is a hard change. People don’t like to be criticized in general. You can’t get the correct reaction to criticism out of the box, but should apply every possible effort to make it a part of team’s culture.

People on a design team must be as happy to be wrong as right. If their ideas hold up under strong (but fair) criticism, then great, they can proceed with confidence. If their ideas are rejected with good rationale, then they have learned something. A healthy team is made up of people who have the attitude that it is better to learn something new than to be right

Built to Last

Without appropriate design, yesterday’s success is tomorrow’s failure, since today’s great applications are tomorrow’s legacy systems

Some design decisions live for about 20 years if product is successful. For example, Photoshop has been on the market for 20 years, and some parts of its initial architecture still exist. Can you now imagine how important architectural decisions are? On to entities framework in TargetProcess that was designed 4 years ago. How long will it live? Definitely we did not consider a 20 year time frame back then…

We should assume that technology that is going to have a significant impact over the next 10 years is already 10 years old!

My takeaway lesson is that we should pay more attention to new technologies and think ahead at the same time. This may sound impossible, but it is worth trying.

Learning

Learning is a very important thing. No, I will re-phrase it. Learning is the most important thing in your company. Surprisingly, Bill has given an interesting perspective on learner’s experience levels:

I haven’t seen this concept of levels before, and I like it very much. If we take agile, I am in transition between levels 9 and 10 (I think). In UX, I am between levels 5 and 6. This model is a good guide and may help understand and plan personal or even corporate learning process. Is it possible to apply it to the whole company? Maybe.

Story-telling and Play

A good story is worth thousands of pictures

That one is true. For example, Steve Jobs told 3 stories from his life at Stanford Commencement Speech in 2005. And this speech was remarkable indeed. I remember all the 3 stories, despite the fact that I heard them only once.

Without play imagination dies

and one more:

Stories, and more importantly, story-telling and play, are critical part of design

Ever been on a boring brainstorming session? Fun is an essential part of any creative activity. It should be encouraged, not suppressed.

Design

Finally, some outstanding quotes on design:

Design is a funny word. Some people think design means how it looks. But, of course, if you dig deeper, it’s really how it works. To design something really well, you have to ‘get it.’ You have to really grok [understand] what it’s all about — Steve Jobs

The last thing that you should do when beginning to design an interactive system is write code

The role of design is to find the best design. The role of usability engineering is to help make that design the best.

I purchased this book at UXLX conference in Lisbon. I did not expect too much of it initially. But after several dozen pages it paid off every cent I’d spent and exceeded my expectations in every possible way. This book is for UX designers, yes, but I’d say every executive should read it. There’re so many gems inside.

I can’t resist sharing my takeaway lessons. The ones that impressed me most.

Executive Vision

Everyone knows that Steve Jobs saved Apple after his comeback. But Bill provides a nice and somewhat unexpected perspective on iMac release lessons learned. I highlighted the points that seemed most important to me:

1. Design saved Apple
2. The design innovation was done with the existing team
3. Executive vision was critical to success
4. Momentum was sustained and rapid (the iMac alone did not save the company, repeated improvements did)
5. There were failures (hockey-puck shaped mouse [see image], Power Mac G4 Cube [see image])
6. The failures were key to success (in the long term, safe is far more dangerous than risk)
7. The design that led to success was largely in the realm of styling, bordering on the superficial
8. There was almost no interaction between industrial design and user interface design.

This story re-emphasizes the importance of leadership. People haven’t changed, it was the same team, but with the great leader they managed to create a brilliant product. Which impediment have they had until Steve came into the spotlight? Lack of executive vision. If there’s no vision and you don’t care too much about design, failure is the most expected result of a new product release.

Actually, I felt the same about a year ago. That’s why I am paying so much attention to UX: reading books, blogs and articles, visiting conference and, of course, championing UX changes in our company. Bill’s book once again instilled me with passion and with confidence that we are going in the right direction.

“It is important to establish a corporate culture that understands and respects the design plan and objectives…”

New Products

“You can’t milk that cow forever” — this quote relates to old products. Company can’t survive without new products, and here is why.

“As product reaches late maturity, development cost for the next release increases at precisely the same time that the size of the addressable market diminishes.”

This is not the case with TargetProcess so far. Our market is still growing, but development cost indeed gets higher. That is something I don’t like and want to change. There are plenty of technical debts we should pay and features we should remove or re-work to be more simple and consistent. We are already doing that. In several years we should release something new, something different than TargetProcess (frankly, we already have plans for some new products).

Sketches

Sketches are very important for design process. They help to explore alternatives and quickly try them. Without sketches it is really hard to find the best solution. I like sketching and do it often, but Bill provides very good reasons and explanations why and how sketches work.

First, it is interesting to define properties of a sketch:

“Sketches are:

• Quick
• Timely
• Inexpensive
• Disposable
• Clear vocabulary (style signals that it is a sketch)
• Distinct gesture (fluidity that gives sketches openness and freedom)
• Minimal detail (“it is usually helpful if the drawing does not show or suggest answers to questions which are not being asked at the time”)
• Suggest and explore rather than confirm
• Ambiguity (much of their value derives from their being able to be interpreted in different ways, if you need to get the most out of sketch, you need to leave big enough holes)”

Here are the main conclusions I’ve made about sketches:

• Ability to quickly generate many ideas. Sketches stimulate imagination and you may invent something initially unexpected. That’s what’s important. I’ve never thought about sketches this way, I always use them as an ideas evaluation technique, but this side effect is brilliant.
• Sketches are useful to express ideas. They do not interfere with changing and improving the ideas, since they are not “final”.

Another important thing is that “Sketches are not prototypes”.

Read second part of the review

Related Links

Sketching User Experience Book at Amazon

Bill Buxton’s web site

I haven’t attended many conferences in my life. To be honest, agile conferences disappointed me. Agile 2009 was half boring, half OK with just one mind-blowing keynote by Jared Spool. As you probably assume, he talked about UX. In fact, this talk has changed many things in TargetProcess, as we started incorporating UX into the company culture. And this is the only reason why I can give Agile 2009 a “good conference” label.

We decided to visit UX LX in Lisbon to check whether there’s any difference. I am an expert in agile, but novice in UX. Conferences are good places to re-charge batteries and to fuel vision. UX LX fully met my expectations. It. Was. Cool.

So what I’ve learned? What we’ll try to apply at TargetProcess soon?

Brainstorming

Maybe this is a number one and Dan Saffer did a really great job at the workshop. To be honest, brainstorming sessions sometimes were boring at TargetProcess. We used several whiteboards and markers. The process was synchronous. It means one person grabs the marker and writes something on the board. Other people throw out ideas and suggestions. Sometimes it works, but there is a much better way.

It is a very good idea to separate two activities. Brainstorming phase may be asynchronous. It means all people can brainstorm the problem and sketch/write results/ideas. There are several techniques that help. One of my favorite is brainwriting. You have a problem and everyone has a sheet of paper. You have 1 minute to write or sketch anything related to the problem. It may be just few words or a very brief sketch. Then you pass the sheet to the next person and receive a similar sheet from the person at the left hand. You see absolutely new content and have 1 minute to understand it and expand it. Very clever and fun.

Photo by Adaptivepath

Also it is very important to engage everyone. Use wall, sticky notes and paper to break down ideas into groups. Then you may review every idea and decide what to do with it. Group interacts with physical objects and these simple activities boost engagement. Also you may give some simple gifts for really cool ideas. It sounds silly, as Dan said, but this works!

Emotions

During one session I understood that TargetProcess is  (quite) a boring product. It has almost no emotions inside. It should be more emotional and humanish. Out of the box ideas are:

• Use avatars and real people faces
• Use better wording in dialogs, navigation, etc.
• Make it more personalized

Copywriting

Text is important. It is really, really important. If someone looks for information, finds the page, reads the text and has no clue what that mess of words is all about — that’s really bad. You might have a beautifully designed web site, but if the copy was written by a marketer or developer with poor writing skills — it will not be effective.

Eric Reiss ran fantastic workshop on copywriting and showed how poor wording can literarily kill a product.

Visualization

The truth is that visualization is hard, but if applied well may lead to unexpected boost of satisfaction. There is a lot of data in TargetProcess, but visualization is not so good. Many areas can be improved. We should pay attention to data visualization all the time.

Source: Swarm

Async Usability Testing

We tried synchronous usability testing on new navigation. It works perfect, but there are less intrusive methods to gather interesting statistic via async usability testing. For example, we can try daily notes or true intent studies. I clearly see how daily notes can be used for installation experience. We just ask a person to install TargetProcess and write everything during this activity (emotions, thoughts, problems). True intent studies may be context-dependent and it is a quick way to gather some interesting data in just a few minutes.

The conference was very good. I feel refreshed and full of new ideas. Also, I feel that in general we are on the right track about User Experience at TargetProcess, but some tactics should be changed.

Since I started to work for TargetProcess and use the product for my daily working routine, I’ve experienced some problems. One of these problems was  navigation. All the links were grouped under sections in primary navigation level or administration level at the top. It took quite long to learn which group of links  should I select  to find some specific page.

The mind map of old navigation

Later I grew up to an experienced TargetProcess user as I’ve been testing new features or build every day but I still was mistaking the groups almost every time  (e.g. trying ‘Tracking’ instead of ‘Planning’ group when looking for Builds list).

Since navigation was the common pain we started to think how we can revamp its look and feel. We wanted it to be flat, customizable, easy to use and quick.

Wireframes

Complaints and requests from other TP users have been considered as we’ve been generating ideas for first wireframes:

We’ve been thinking if we should hide or show the whole group of links as on the screen below:

…and ended up with the concept of customization by links as we enabled users either to pin each single link to primary nav tab or to keep the link in ‘More’ group, create their own groups and rename the links:

All these wireframes emerged after long meetings, hot debates and multiple changes.

Concepts

As a result, by mid-January ‘10 we’ve had two different navigation concepts ready to be shown to some customers, members of TargetProcess UX group. We asked the customers to review two navigation concepts implemented as dynamic and static PDF and give us their feedback on both.

Here’s the first navigation concept:

1. One-level menu for quick system navigation.
2. Configurable tabs order.
3. Quick access to all pages grouped logically in “More” pull-down menu.
4. Easy-to-use advanced tuning mode.

The second navigation concept:

1. Two-level menu.
2. Configurable tabs with the possibility to re-group links.
3. Easy-to-use advanced tuning mode.

Most of our customers-UXers voted for the first concept and we went along with this design. Development of dynamic prototype was started simultaneously with the nav coding so we had usability test results available by the end of implementation.

Dynamic Prototype and Usability Tests

We wanted to run a usability test with our customers as early as we could and the interactive dynamic prototype for navigation was ready in a week (with IxEdit). The prototype replicated TargetProcess tool and was available on the web. Not like in the real web app, there were just screenshots with static pages:

In this proto users were able to navigate from page to page and to customize links selection for their primary nav menu. The only major thing at that time was re-ordering of pinned tabs which didn’t work in the proto.

Test scenarios were rather simple:

1. As we drastically changed the layout and re-grouped some links, we wanted to check if users will find particular pages easily with new navigation . So the first scenario was about simple pages browsing.
2. The second scenario was related to the customization of primary navigation level.

We asked our customers from the UX community to take part in the usability testing of new navigation, and four of them agreed. The testing was done via GoTo meeting.

Usability Tests Results

Based on the results of this testing, we’ve become aware of some areas in the navigation where users slowed down.

Most of the users who saw the nav for the first time tried to drag and drop links right away and guessed slowly that tuning and re-ordering tabs works in customization mode only. After customization was done, they forgot to switch customization mode off. Also we noticed that [Reset to default] button appeared uncalled, so it was removed in the final version.

That’s why we went on and tried to emphasize with different styles when navigation is in customization mode and when not.

Now the highlighted menu background under the button [Customize] shows that the button should be pressed to start tuning (customization).

That’s what one can see in the tuning mode (check the screen below):

• [Customize] button disappears; yellow background rolls up to the primary nav level where [Done] button appears.
• Only the primary nav level and  ‘More’ menu are active, content of the page is grayed out and disabled.
• Links selected for relocation in ‘More’ change their background from white to solid blue; mouse cursor changes shape to cross.

We believe that it’s hardly possible to mess up with the navigation modes now. The navigation is quick, one-level and simple for personal customization.

And - what’s most important - people like it as well. Out of many feedbacks, here’s just one from Igor France:

I have just installed the latest version of Target Process with the intention to start using it on my own projects (the company I worked for at the time didn’t adopt it) and I am again really enjoying using it! Apart from the positive things already mentioned, the main navigation itself in the meantime not only stopped being confusing but is now fully customizable as well!

Kai Gilb started a series of posts that challenge Agile Software Development. Part 2 is about creativity and “how well” focus in software development. While I agree with the problem, I strongly disagree with the solution. Kai recommends to write requirements (the format he uses doesn’t allow me to call it “user stories”) in a form that does not contain solution:

As a buyer, I want to place a book in the shopping cart

vs.

It is required that a buyer, by next Feb, can complete a book order of three books, in 1 min. If by next Feb. it takes more than 6 min., this project is a complete disaster. On the website it is replacing, it takes 10 min. Our main competitor has a system, where it takes 7 min. And after last sprint (if Scrum) we measured our latest version to 6 min.

Developers Are Not Product Owners

Then developers should creatively find the ways to implement this requirement, to invent the solution and to solve the “how well” puzzle. We’ve got a huge problem here indeed. Most developers can’t invent solutions at this high level. They can create beautiful architecture and build the quality in. They can write tests upfront and use powerful tools to speed up development. They can do many things, but often they can’t invent a “how well” solution that will make customers happy. Why?

1. Most developers know nothing about User Experience (and don’t care).
2. Most developers can’t create usable design.
3. Many developers barely know a problem domain and in any case don’t want to dig into much details here.

In short, most developers are engineers (so far?), so what Kai proposes will not help. It is just a theoretical solution to “how well” problem. It’s the same like trying to grow 4 hands and 2 heads to double your productivity (well, sacrificing beauty maybe…)

In Scrum Product Owner is responsible for writing User Stories. It means he should invent solutions and care about “how well” thing.  I don’t see a significant problem here. Of course, it’s great if developers are interested in requirements handling and solutions investigation process, but if they are not, Product Owner can do that alone or with special people who care. Who they can be?

Those people are UX specialists. They know how to solve “how well” problems effectively. They know many things about design patterns and all new trends in interfaces. They like to explore problem domain and talk to customers. If you have such people among developers — you are SO lucky! But often this is not the case.

We, at TargetProcess, try to instill UX culture into development process. We started in August, now it’s February and I can’t say we’ve had much success. Sure there are significant improvements, but to be honest most developers are not so interested in UX staff, they like BDD, DDD, C# and SOA more. I expect it will be a long process that will take years. And our company is quite small. I can’t even imagine an effort for such a radical shift in a huge company.

Broad Requirements Are Not Testable

I wonder how you can write BDD scenarios for broad requirements as Kai suggests. How the hell can you test anything, if you don’t have any clue on how it should work? So broad requirements can’t replace user stories obviously. They can live in backlog, but developers should deal with concrete requirements that are testable right away.

I can agree that you can split backlog in 2 parts. The first small part contains detailed stories that can be put to development asap. The second large part contains broad requirements without solutions. That might be a good idea. But we should clearly separate UX phase and Development phase. During UX phase we should solve “how well/how cool” problems, and during development phase we should solve technical problems only (with some corrections in “how well” for sure if required).

P.S. Kai, I hate gray text on gray background in your blog. It is not user friendly.

• Interesting post from Joel Spolsky The Duct Tape Programmer and even better reply from Uncle Bob. Uncle Bob’s hottest phrase is “I want you to ship, but I don’t want you to ship shit.” I personally like it very much. It is a paramount of software development.
• 10 Useful Usability Findings and Guidelines. Very good list of practical UI advices. For example, do you know that the ideal search box should be 27-characters wide?
• Two posts about how to inject User Experience into Agile development: Twelve emerging best practices for adding UX work to Agile development and Agile + UX: six strategies for more agile user experience. “Unfortunately, the iteration cycle, “agile”, and phrases like “team velocity” were confused with “fast”. The biggest problem with lots of user experience methods is that they’re not necessarily fast. They’re not necessarily slow, but they do take time.”

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…

TargetProcess v.2.6 released today! We were targeting better user experience in the latest release. We took time to polish things and enhance the user interface by making it cleaner and easier to navigate. New iteration planning concept is just great, we are very excited about it! It visualizes the most important parameters of user stories and bugs such as effort and priority, thus providing real enjoyment during iteration planning sessions. You really feel user story effort and business value when making a decision about the assignment to iteration.

Inline editing in lists is an outstanding productivity feature. Double click on a row, change required info and simply hit Enter. No page reloads, no waiting! TargetProcess in many aspects is getting closer to usual desktop applications, which is far from reality in most of the web based apps out there.

There are many other smaller features that makes life easier like new filters, customizable inner lists, new chart, etc. We are continuing to improve TargetProcess usability to make it as easy to use as possible.