I’ve found a nice metaphor: the living system. Any system should respond to user actions as a living being.
Normally, web apps are emotionless. Their work is too straightforward, at times they ignore user actions and/or respond very selectively. In general, they are very much like robots. A good system should create an impression of the life within. It should signal if it feels good or bad, gets angry, annoyed; have fun, relax — just show its (or her?) emotions.
I think there are 2 levels of designing apps.
The Trivial Level (Elementary)
This is about an adequate response to user actions. The system should show what you can do with it. Buttons should look like buttons and tremble, quiver or flicker for mouseovers. The animation should be fairly smooth and natural, exposing the dynamics of a living being. Let’s take a closer look at the drag and drop behaviour.
Mouseover: pulse/enlarge effect
Drag: the object changes its color, rises against the background (the shadow effect) and turns over
Move: nothing happens
Hover to the drop destination: destination gets highlighted, the element changes its color
Drop: the element changes its color and slowly returns to normal.
These small things create a deeper sense of engagement, making you feel like you work with a real, tangible system.
Quite many apps are designed on the trivial level.
The Level of Emotional Empathy (Advanced)
This one is far more complex. If you can implement it, your web app acquires its own personality. The main trick here is to keep the integrity of your solution. How does your system react to errors? How does it tell users what should be done next? How does it acknowledge successful actions?
There are bugs and tasks in our system. Sometimes — too idealistic — there are no bugs and tasks. No bugs — life’s good. The app should be happy and say: “Wow! I found no bugs!” If there are no tasks, it can cheer you up: “You’re done for the day! Now you could take some time to read news on TechCrunch”. Or it can troll you: “You’ve got nothing to do? Are you sure? Do you want to add new work?” “add new work” opens up the new task creation screen.
Another example, the system shows 500 open bugs and mocks at you: “Aha… 500 open bugs!”
You want to assign a task to John. But somehow he’s already working on 19 tasks. The system can take mercy on this guy: “Poor John is struggling with his 19 tasks, and he’d hardly get them all done soon. Should we re-assign John’s tasks to someone else?” There goes the link to John’s dashboard with tasks.
To make the system behave this way, one should understand every small turn of user scenarios and strongly empathize with end users. To my regret, we’ve got “0 items found” responses all over TargetProcess. That’s so excruciatingly boring.
Siri is a cool example of a nice living system. Well, it’s got voice interface, etc. Nevertheless, I’m sure we can breathe life into TargetProcess. Just like Pygmalion gave life to the statue he created. That’s what we’re going to do in TargetProcess v.3.
How does a great design differ from a good or mediocre design? Often the difference is just in the smallest details. These details shape user experience and greatly affect the way we feel about a product. The product may look great, but people remain cold using it. They don’t feel it is designed for them.
Views functionality in TargetProcess is not a rocket science. There are thousands of applications with views. View is such a boring page to work with usually .
New Views in TargetProcess are crafted with great attention to details. Every single detail is thought out. Every single decision was debated. Let’s dig into details. I will show and explain all of them.
Inline Edit
Inline edit (edit-in-place) is a huge thing. It allows you to edit everything very quickly. These two words are important: everything and quickly. In our new View you can indeed edit everything and do that really quick. But this is not all. Watch these two very short videos.
Inline edit in JIRA
Now compare it with inline edit in TargetProcess
The difference is clear. When you are editing something in JIRA, the effort value jumps back and forth. It is somewhat confusing and unpleasant. Effort in TargetProcess stands stone still as you edit it. This produces a totally different feeling. When everything is still you feel that things are under control. The jumps, on the contrary, are quite distracting, and you feel that something is not good (but often can’t say what exactly).
People assignments
People assignments component has all the small details that make it just awesome. Avatars enable quick recognition. You may think that avatars are not important, but with time you’re so used to them that you identify a person in a split second. Humans recognize image patterns much faster than words. With first and last names only you have to read. With avatars you just scan.
Quick filter is the fastest way to find someone if you have a large development team.
Popular actions are available on the top. Quite often you want to assign work to yourself or un-assign work. It is always a good idea to put popular actions to a visible place.
Moreover, potentially dangerous actions are marked red on mouseover, which secures them from accidental clicks. Also, the red mark builds up quick memory for actions. For Unassign, you will point mouse cursor and click quickly if the button is red without reading.
Links and Actions
There are two types of links: some links represent actions and some links are usual links. There should be a clear distinction between the two types of links, thus action links have a different underline style (dotted):
If you can perform an action (like edit), you miss an opportunity to jump to entity. This problem was resolved by adding a tiny icon. The icon is an idiomatic pattern to navigate away from the current page.
When a property is empty, it is not clear if you can edit it or not. You point cursor to an empty row and think something like “Hmm, is it possible to edit something here?” Then you click, and it appears that it is indeed possible to edit this value. But why make people think? The clear message is shown in an empty row when you move mouse over it:
Hidden Stuff
It is a good idea to show only relevant details. For example, you want to change release or iteration. Releases and iterations have end date, you have many releases and iterations that are already done. Most likely you don’t want to assign a user story to an old release. Thus, old releases are hidden by default.
Mouse over pattern is everywhere. So, all actions are hidden by default. You need to move a mouse cursor over a comment to edit or delete it. Thus interface is clean and not burdened with repeated buttons. There is one disadvantage in this approach: available actions are invisible by default for new users, and they might not be actually aware that they can edit something. But we consider this a good trade-off. We don’t design for new users, we mainly design for people who continuously use our product.
Multi-attach
How often you do you need to upload several files, one by one? It is intolerable in a modern web application. People should be able to upload all the files at once:
Layout
The general layout is pretty straightforward. You have a content area with title, tags, description, attachments and comments on the left, and more details area with miscellaneous information on the right. This separation is logical.
The layout of the area on the right is beautiful. The most important information is on top. For example, status of a user story and its progress. Then you see all assigned people with estimated effort. Everything is lined-up and there are no unclear labels or weird information. Only relevant information is visible. You can also hide information blocks if you want to.
This is it. New views are in beta and more improvements are coming. Stay tuned and give us your feedback. We live by it.
4 people from TargetProcess attended London UX Conference this year. It was a decent event and here are mine “take-aways”.
UX + Agile
Alan Cooper read a solid visionary lecture about UX future and adoption. The main trend is to mix agile software development practices with user experience teams. There is a new initiative called Balanced Team. He did not spend much time on this topic, but that is something I am curious about. We’ve been adopting UX + Agile at TargetProcess since 2009 and definitely want to do that efficiently.
It was nice to be reassured that we are going in the right direction as a company. We already do many things Alan mentioned in his speech.
Visual Meetings
Our meetings might be better. Sometimes they are too long. Sometimes too boring. Sometimes there is no clear outcome. Quite many workshops and sessions at London UX 2011 were dedicated to better, more productive and more fun meetings. Sunni Brown ran a fantastic workshop: The Art of Graphic facilitation (a.k.a. “How to Run A Workshop with Pictures”). It was very funny and useful. We had several short creative meetings and drew a lot of sketches. I highly recommend her Gamestorming book.
Kate Rutter’s session Design Patterns for Fantabulous Collaborations was very informative and I’ve learned new ways of running efficient meetings, but the practical part was a bit boring and out of context. Overall, after this conference I have a clear understanding how we can improve our meetings which is good. Best Practices for Facilitation looks like a “must read” book, but it seems you can barely purchase it.
We often do ad-hoc meetings, without any preparation. We go like “Let’s discuss this user story with filters”. However, such meetings should be planned. All attendees should be prepared. There should be a right balance of order and chaos. Our meetings are on the chaotic end, so we have a huge space to improve.
Sketching, Sketching, Sketching
Everybody should be able to sketch. It means we should train people to not be afraid to draw something and express information with words AND pictures. Adults often prefer to write and don’t like to draw their thoughts. Mostly because they’re wary of looking “unprofessional” and “ridiculous”. We should break this prejudice. Sketching is a very powerful technique that allows people to try and express ideas blazingly fast. Bill Buxton wrote an incredible book Sketching User Experience. Read it and you will understand why sketching is so cool.
Humans receive 95% of information through visual perception. We spend countless hours staring into laptops reading, analyzing, interpreting and feeling information flows. I think visualization is something we lack in many disciplines and project management is not a lucky exception.
Interestingly, latest trends in agile project management do care about visualization. Kanban success heavily depends on great visualization. Everybody loves Task Boards and Burn Down charts in Scrum. As you can see, there is some progress, but I think it is not systematic, just a side effect of other activities. It would be fascinating to create an orthogonal movement in agile project management community that focuses on visualization, I call it Visual Project Management.
There is only one really important rule about visualization:
Visualization should reveal problems, states and trends
Sure, we can add more rules, but they’d be secondary. Imagine you can see a Backlog and diagnose a disease right away:
too large
contains too many old user stories and
grows too quickly
Imagine you see a Board, and at the same instant you grasp all the bottlenecks:
overloaded people
problematic stories
quality problems and
overall development speed
I can’t provide quick visual solutions right away, but I think this approach will change the way teams make decisions and improve their development process.
I wonder why we still have no good visualization tools for project management. I think the answer is that project managers are not strong in design, and designers are not strong in project management. Separation of responsibilities leads to basic, trivial decisions. PM should learn design and data visualization techniques to really invent new visualization. Designer should learn PM domain to invent new visualization. The ideal mix is a team where PM knows design and Designer knows project management.
Let’s review some examples to get a basic feeling of how visualization re-define things.
Why Kanban Board is a Great Step Forward
Information presentation really affects the ways we run projects. Here are two screenshots that contain exactly the same information. You can easily say which one is better.
This is a simple list of user stories taken from TargetProcess (I am working at TargetProcess, so forgive me biased screenshots). It contains quite many data about user stories like state, assigned people, effort, etc. However, this data is hidden. To make some decisions, you need to dig and put some effort into it. It means you have a higher cognitive load. It means you’ll miss some details and sometimes make a wrong decision.
Next screenshot is a simple Kanban Board. While it is not the best example of Kanban Board, still it is good enough to reveal the difference. You see the same user stories on this screen. However, you can quickly identify there’re too many user stories in In Progress state, but it is not critical, since there are no holes in development flow. You can somehow feel that most likely the team is doing pretty good. In some cases you can’t even quickly explain why you think so, you’ll need to analyze your own feelings to provide logical answers.
But the truth is that you have arrived to some conclusion with enough accuracy, really quickly. That is why visualization is so important in any discipline, including project management.
I believe we can have something much better than a simple Kanban Board. Kanban Board visualizes development flow, but misses other important things like people load, local problems, overall progress for all projects etc.
What happens if we have several teams and want to see their work on Kanban Board? Definitely, the board above will not show that. So far, I haven’t seen good solutions to such problems. Software products are not good in presenting large amount of data in an interesting, meaningful manner. This should be changed.
Why Gantt Chart is Misused All The Time
Gantt Chart is a great tool as well. It is heavily used in traditional project management, but often with poor results.
Most of the project charts look the same and make the same mistakes: analytically thin, bureaucratic grid prison, not annotated, little quantitative data.
E. Tufte
This Gantt Chart is quite good and useful:
This Gantt Chart is bad and useless:
Stop. Think a little bit. Can you define the difference? Can you say why I’ve made such a conclusion?
First chart shows quite large project phases. Second chart shows very granular tasks. Gantt Chart is not a good tool to handle granularity. It works best to visualize long project phases, like releases or iterations. It just plain fails to visualize 500+ tasks in a project.
Gantt Chart has a large white space, it lacks information density. Thus it should be used carefully to visualize important information, not everything you have.
I think the frustration with Gantt charts arises more because of tool issues. People’s contexts of use may require information that is obscured by a Gantt chart. But Gantt charts are the dominant (sometimes only) visualization in many tools, and it’s difficult to impossible to extract and present the data in other forms.
Brian de Alwis
These were just two examples of visualization in project management. I believe we can be more creative to provide better tools and concepts, invent new ways to present project information and improve transparency. We definitely can do better. And we should.
I will post more about visual project management. This topic is really intriguing and promising to me.
