What do you think about user experience? Is it something that makes the application pretty? Or is it something that is required for a final, shippable product?
I'm a UX professional, so I'm a little biased as to it's value. In my ideal world, if I compare an application to a meal, then the database and codebase is the meat and potatoes and honestly - the UX is the broccoli. It's not the gravy - gravy is good documentation. QA is a process - so that's not counted. It is just too important and holds the application together. Further, gravy is optional for a meal and is there mainly for taste and not really nutrition (I know I'll be debated on that by some friends). Help manuals, well, we can consider that to be dessert.
If you show an application to your users, guess what they notice first? Not the perfect database structure. Not the clean, simple code. They notice the UI - the colors, the fonts, the words on the screen, how the system works. And yes, looks matter. They matter a LOT. Often users will leave a poorly designed interface because they just don't find it appealing.
UX is like broccoli - you may not like to eat it, but fresh green broccoli is good for your health and makes you strong.
Depending on the UX team and how it's managed, sometimes it's considered to be a nice to have (less on words and more on actions based on a how a project is managed). We sometimes choose the CSS colors, fonts, and styles at the end of the project, as if the application were a coloring book. Don't get me wrong - I went along with this plan for a long time. I wanted to make sure the flow and general architecture was there and figured we'd make it pretty later. The UI work was done at the end during one of the development breaks - we'd clean up the interface and get it "pretty."
But I was wrong. It was a bad idea.
How can you review a story about functionality without it looking close to final? Or styled? How do we know that it works as expected? A visual designer may not be able to apply a look/feel for the page while it's being developed, but could a visual designer come up with some general visual elements to apply to a page? How about some kinda/sorta finished copy from a copywriter?
All that is a yes. Especially if the goal of Agile is shippable product at the end of every iteration.
By adding the visual design and content at the end of a project, we are adding icing on the cake. It's not even part of the main course because it moves the UI to the end as an almost optional step - it doesn't get the time or attention it deserves. And further - when you review stories with the business, are you getting even a close result of what the UI could be? And what is the business and owner really approving anyway?
Now, if we include users as a stakeholder group in a project this makes the UX more like broccoli. Now you can have meat and potatoes - the main application - without broccoli, but there are some implications of that (and this isn't a digestive blog so I'm going to drop this quickly). You can eat broccoli alone, but let's face it - in an hour you will be hungry for another snack. You need the main course and sides to make a balanced meal. The same is true with UX. If you want to review an application with not just the business owner, but a user - you BETTER make sure it is neat to use. I've been in usability tests with a greyscale/wireframe/Greeked copy UX and one with a more complete UX. I like using the rougher UX because it makes it clear that this is a draft and you see where the problems really are. However, throughout the entire test all we heard was feedback on what the users didn't like about the colors (are you really going to use grey?), lack of instructional copy (what does lorem mean?), and similar comments. We learned where the pain points where most definitely - but man, it would have been easier to have a more complete UI to test.
So by waiting until the end of a release for incorporating the UX, what do we risk:
- Prevents iterative usability testing - or rather - user reviews and solid results (see the Usability Hokey Pokey)
- Prevents the business owner from having a real review - they have a partial review and we still need to create stories to fill in the gaps for the UI and possibly additional functionality
- Prevents real QA
- Makes for sloppy coders
The more constraints you put on developers, the tighter they code. Sure, they may need to work with a UI guru, but that's good for pairing and giving someone more experience in the UI area. It's not a bad thing. We all have our focus in work (another topic for another day - what it means to focus on an area in Agile)
So - Why don't we integrate UX development with iterations to get as close as possible to shippable product?
Often don't have the final UI in place the classes ready for the CSS and we aren't sure of the final look/feel
My arguments back:
- You can make up a palette and design early on and do the same with design that you are doing with the features and iterate from there with stories
- Create a structure just for testing or for presentation and add to that over time to keep the shippable product in mind
- Try to draft copy for each iterations as complete as possible
- Target a date for interim testing and get a UX together for that - kinda like the icing approach, but at least it's not left to the end and it focuses on a more complete UX
I think there is a lot of room for work in this area. There is a great book out - User Centered Agile Methods, by Hugh Beyey, which, after reading, I realized I need to revise my views if I continue with Agile, and see my role as a UX consultant as being a representative of the users of a system with users more included in the process in general.