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.
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:
- Design saved Apple
- The design innovation was done with the existing team
- Executive vision was critical to success
- Momentum was sustained and rapid (the iMac alone did not save the company, repeated improvements did)
- There were failures (hockey-puck shaped mouse [see image], Power Mac G4 Cube [see image])
- The failures were key to success (in the long term, safe is far more dangerous than risk)
- The design that led to success was largely in the realm of styling, bordering on the superficial
- 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…”
“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 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:
- 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
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?
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!
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
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.
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.
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.
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.
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.
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:
- One-level menu for quick system navigation.
- Configurable tabs order.
- Quick access to all pages grouped logically in “More” pull-down menu.
- Easy-to-use advanced tuning mode.
The second navigation concept:
- Two-level menu.
- Configurable tabs with the possibility to re-group links.
- 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:
- 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.
- 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
||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: