Edge of Chaos | Agile Development Blog

We live in the age of added value. It’s everywhere. Value-added services, value-added products, value-added goods etc. etc. etc.  Actually, so much value has been pumped up in our life, that it’s even strange that this value is not protruding from us like clothes from an overly packed vacation suitcase.

If we take a closer look at the back side of added value, a huge surprise is waiting there. The example I find most notorious is cell phones. What if I want a simplistic cell phone with NO Internet, no camera, even no voice mail, just live calls and SMS?  You’ll never ever find such a phone.

I bet that a phone manufacturer who stops the rush for more new features, would make a fortune in an instant selling the “new frugal” cell phones. In this case, the added value is content which comes from Internet, capabilities to exchange content. Why should someone want a phone without Internet?  My word, very soon we will see such phones on the market. The niche for them is already there. Here’s why:

More content and more various channels to produce and exchange content is now commonly presented as added-value. Hence, a communication device which happens to be a humble phone is supposed to deliver this value. But as we’re oversaturated with content, no buzz is a huge deal. The luxury of focusing on one thing at a time is something that only a few can afford. Besides, it’d be very frugal (frugal is actually the new buzzword :) to buy a phone for a reasonable price, and sell a used iPhone to some geek. Oh, pardon me. It’s all about iPads now :)

There’re plenty of such examples. Another one: the added value of having a car means lack of natural movement, the necessity to pay for gym etc. It actually brings along the whole array of more added value  goods and services that turn out to be not of added value but of less value, since you pay for what you could do naturally.

Take organic products. Now they’re added value. 100 years ago who could have thought that something natural adds value? Now it’s a rollback. What is simple and natural costs more, but has less value compared to the original added value concept for the matter, and the cycle goes on and on.

And we’re nailing it down to our favorite: project management tools. Versatility and too many features now have bounced back to the simplistic Kanban board.

It looks like it’s time to not only practice lean production, but to produce lean products. Gaining focus requires focused tools, one way or another.

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.

Books by Edward Tufte are a piece of art. I’ve been savoring them to myself for a while, and now I decided to share some sketches and criticism inspired by Tufte’s high art visual designs.

Commonly, designers represent visual information by scarce means of 2D realm: screen and paper. Our universe is 3D (if not 5D, 6D or whatever more dimensions), but people got used to squeezing  images into 2D flatland.  Even rock paintings of pre-historic humans have their touch of 2-D abstraction and symbolism.

Our universe is not just 3D. It’s dynamic 3D. Paper is static (paper planes are exceptions). That’s another limitation of 2D.

Limitations are great. They motivate designers to find solutions. The more limitations – the harder it is to find a solution. Good designers love difficult tasks, since they view them as great opportunities to put their brains to use. Bad designers do not want to use their brains – they want to use templates.

The image below is a template solution for a weather map. View from above.  Let alone template thinking, the representation of this template is poor.

The appalling hint of white shade is a helpless attempt to compensate inadequate color selection for numbers.  What do you think of blue numbers on blue background? You hate that, to say the least of it. What’s the message of these pseudo-3D grey circles? Are they some grey moons? Or cavities  in the designer’s brain?

Now let’s take a look at the Euronews channel weather map.  One may think that this map represents the effects of global warming and Australia is completely hidden under water now. Also, what do those bold numbers show? Probably the depth of the ocean in this area. In meters. Or in miles? But the area is still lit by sunshine, which instills some hope.

As a contrast, here’s a weather map from a Japanese daily, beautiful in its simplicity.  This is the same Japan as on the first weather map above, only from the ocean perspective.  This map provides 0°C и 10°C  isotherms.  You see fine clouds on this map. The map shows sun movement.  OMG, it shows stratosphere! And it’s nothing more than just a weather map from a daily newspaper  - but created by a good visual designer.

Of course, Japan is well-suited for such a nice graphical representation. But you gotta have guts to catch and use this ocean perspective, instead of helplessly surrendering to boilerplate view-from-above weather maps imposed by paper sheet or screen limitations.

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

• 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.”