Designing the Experience

One of the criticisms of Agile by designers is, "We need to be able to design the entire application from front to back to ensure a consistent user experience." I have noticed the over use of the term 'experience' over the past few years. A solid experience doesn't come from the iterative design process; it comes from a solid vision of how the user feels when they are using the application. Much like a brand, there's a bunch of intangibles that come up and explaining them can be the hardest part.

I like working through the nitty-gritty of the user experience of one small component at a time. It can open up some cool things that can be used in other places and reveal some what-not-to-do's right out of the gate. A little bit of focused trial and error on a small piece is always easier to change than finding something out way down stream and having to change the whole thing. Sort of like painting a small section of a room with the wall color and the trim color and seeing how it looks with rug, before busting out the rollers and going to town.

Design and Business – it’s all about the love.

In many Agile projects, we hear about the ‘truth’. In many big corporations that means the Business Sponsor. I have found that the interaction I have with the ‘truth’ is what makes the engine really move. I have come to find that the role of designer becomes the role of idea generator.

Designers tend to feel an obligation to question every single business rule, and I’m no different. I have found the mini-brainstorms I have with my ‘truth’ put us on the same page, gives me insight as what’s going on in their head and opens a dialogue that is truly invaluable. Business Rules become shared ideas.

So much of Agile is in the talking to your teammates. When business and design show a united thinking, things really fly. I have yet to meet a business sponsor who doesn’t like to talk about ‘the idea’. Any chance to make the idea better is a win for all. I would much rather have a hand in creating the rules than spending my time questioning them.

All for one…

A great part of Agile is the blurred lines between roles and cube walls. Hands down, my favorite part about Agile is co-location. Walking over to a developer's or business analyst’s desk for a quick chat is invaluable. Impromptu brainstorming coupled with reality checks, you can't beat it! I’m not 'just' a designer – I'm a teammate. If I see a gap I can fill, I fill it.

Recently on a project we had a pretty big, new feature set coming into an iteration. I couldn’t do a whole lot design wise on it – it was almost all back-end and middle tier work, and it was going to take the whole team to get it going. I saw something I thought I could do myself, so I did. In a waterfall process there's no way a designer gets to look under the covers of the code base, much less alter code and check it in. In Agile that's exactly what we allow ourselves to do. It may have taken me a lot more time than an experienced developer, but it got done and tested. In prior iterations I was able to sit with the developers and tweak look and feel as needed with them, so I had some idea of what was going on and I wanted to learn, so I did just that.

The QA testers on my team have done the same with me. They come with a print out of the design and we sit down and write test cases together, based on the interaction designs. If I want something to fade in, it's marked a bug if it doesn't happen. If the application doesn’t look like the design, it's marked as a bug. After I learned how to change some of the look and feel issues in the app myself, those bugs were assigned directly to me.

It is my personal feeling that the days of the single disciplined mindset are over. You have to be able to do more than one thing to make it. Here's my favorite example: Troy Brown of The New England Patriots. This man has played Wide Receiver, Defensive Back and Kick Returner, in the same game, for entire seasons. He is truly versatile and unselfish. He is a true teammate... and he has three Super Bowl rings to show for it.

Can an application have a narrative? It must.

As accessibility becomes a bigger interest of mine, it is becoming clearer to me that the issues are not in the functionality or code needed to create accessible apps. It'’s in the design of these apps. As a visual designer I must stop designing visually. I must learn to design 'narratively'.

How can I read you an interface? How do my app designs tell stories? Can I tell a great story with my design without any visual aid?

The shift lives in how we think about interface design and application concept.

Normally we think of our customers in a persona or scenario or a use case. We personify these made up customers with great ease because we have the voice of the user, by means of; feedback, interview, focus group, the list goes on. Then what is the voice of the app? Who is the app?

This is the mission. Personify the application. Breathe life into an experience in the same way that we breathe life into the users of the application. We do this by building a strong story, with beginning, middle and end. In the telling of that story, we have what I think is missing from 'accessibility design'.

We build our apps to be as visually pleasing and functionally solid as possible. We often focus so hard on this that the accessibility portion becomes afterthought. Something that must be retro fitted or hacked or rushed. I believe that by flipping the order of that we will not only have built a solid, usable, accessible app, but a visually stimulating and emotionally engaging experience.