User Experience in Agile

User Experience (UE) is probably one of the least understood fields in todays software creation community. Yet it is arguably the most important thing we humans look for in an application. One of the companies that understands UE is Google. That’s one of the reasons they are building a religious user base. Truly yours is a fan of their applications including Reader and Maps and although they seem to have blooped with Desktop Search, they are still topping my and many other users’ most likable applications lists. In fact it is not a coincidence that many of us have come to expect the next cool technology or cool app to come from no one else, but Google. So, how does Google do its magic? By understanding human behavior and creating human-friendly applications.

Agile methods are particularly well suited for applying good UE principle in your application and achieving Google-like UE designs. I’d like to list ten practical recommendations from my personal experiences that could help better understand where UE fits and how it can be used to add value to the application and make its users feel good (…yes, I feel good every time I use Reader).

Hire the right people

Start with recruiting the right talent for the job. Do not underestimate this step, it is both difficult to locate good people in this fields and also to tell the good from the bad. Look for people with social sciences backgrounds and experience working in fields such as cognitive psychology, interaction design, information systems design, semantic user interface design, context-based interactions. Shy away from engineers and graphic designers [ok, this is sooooo general, that perhaps is worthless] because we tend to be too analytical, systematic and predictable [read:boring]

Make the UE part of the Onsite Customer

Because UE is such an important task it goes hand in hand with the business requirements. Make the Product Manager (PM) and the UE expert share the responsibility of getting the right requirements to the User Interface (UI) team, the business analysts and the programmers. Let the UE participate in the story prioritization and iteration-end demos. Take their feedback seriously and treat is a real business requirement, equal to the ones coming from the PM.

Plan for UE

If you want users to love your software then take UE seriously. Plan for it. Allocate a few points each iteration for UE. Start with the lowest possible unit (point) and find-tune as you go. If your app is UE-centric, you may find yourself spending up to 10% of each iteration on UE. That’s quite normal and it shows you are dedicating enough time for the cool factor, besides the useful stuff. You will find yourself spending those points on clarifications, UE acceptance testing and reworking the UI based on valuable feedback from UE.

Automate the UE testing

UE testing is the activity of making sure that the users have a pleasant time using your application. So if humans and pleasure is involved how can an automated test help? Easy. Concentrate on parameters such as how much time it takes for a particular screen to render and capture that data. Fail the test if it is more than a threshold representing the “patience coefficient” of a user. Look for misaligned elements in your screen and fail the test when they happen. A common failure in AJAX-based systems is the connection and when that happens parts of the screen remain blank for a certain period of time. Try to automate as much as you can using tools such as Selenium and Watir. Make the automated UE testing part of your continuous integration loop and raise hell when it breaks just as you’d do if my JSP fails to compile.

Internal UE releases

When does UE start and end? It does not. It’s there all the time, from beginning until the end. One of the advantages of the Agile methods is that working software is produced at the end of each iteration, so make it a habit to release a working copy to the UE team to play with while the programmers are working on the next set of stories. This will give the UE team a chance to test the application in a more relaxed environment and therefore they can spend more time evaluating its usefulness than the limited demo at the end of each iteration.

Keep UE independent

They are the people who should be able to design and evaluate the software as an outsider, so keep the UE outside of the core team. If this means exclusion from the common team area, do it. Let them stay independent and give them enough time and space to evaluate your interim product on a regular basis. This independence will eventually manifest itself as great features, likable user experience and fresh new ideas. You can occasionally invite them to your parties, that is OK; we all need well-dressed people around us khaki-knowing-and-loving engineers.

UE Acceptance Testing

Make the UE experts the ones who decide whether your iteration was successful in the UE department or you missed the mark. Invite them to the iteration-end demo and let them evaluate the software based on independent evaluation criteria. Do not postpone UE rework as a result of the feedbacks and if possible tackle failed features in the next immediate iteration. Do not allow for the accumulation of UE debt.

UE mockups are not UI mockups

Make sure you and your team understand that what UE creates as UE mockups (wireframes) are not screenshots the future application. That is the UI team’s responsibility which starts by them getting the UE mock and working with the PM and UE to create a UI mockup. UE is said to create low-fidelity wireframes, sometimes drawn by hand, and the UI converts them into high-fidelity screen mockups. This is an important distinction as many team members seem confused about the various artifacts produced. Think of the UE mocks as the principles and the UI mockups as the prototypes that implement those principles.

UE and Architecture go hand in hand

UE works closely with the Agile architect. What will eventually become the domain model starts as an idea in the UE’s brains. UE and Architects should share brainstorming sessions and use whiteboard design, and loose notation [read:non-UML] to capture their artifacts.

Get creative

Just because you have not heard about it does not mean it’s not possible. Get creative and use other disciplines to interact with UE and allow them better means to share their non-technical ideas [and passions too]. For example import the concept of “storyboards” from the movie industry. Treat each screen of your software as a scene from a movie. Sketch your players, mark your cameras and lights and shout “Action”. See what happens. Map the paths a user can traverse to get in and out of the particular screen and try to imagine how he/she feels.

UML has been particularly difficult for non-engineers to understand. Use other, less-formal means to communicate with the creatives of the team. For example use mind maps whenever possible to draft user paths and behaviors. Use the mind maps to work on a domain model. The relaxed notation of the mind map makes it the ideal choice to put UE, PM, business analysts and architects on the same drawing board.