Agile and the UI/UX Debate

June 29, 2014 Back to home

Agile and UI/UX debate always is a hot topic at every Agile conference I have attended.

How can they do the UI/UX work in the sprint if the developers needs that IN the same sprint

I see many approaches to solving that -

A rough sketch with little specifics during sprint planning
A spike task that allows the UI/UX to design
UI/UX feed into the next sprint in a staggered approach

The last one is what I have seen to work the best, but Agile Fanatics will shoot me as that leans towards a waterfall concept. I think the problem is this...

We follow a process without knowing what we are trying to solve

Agile is awesome, talk to anyone who knows me, but it is NOT for everyone. There is a saying a picture is worth a thousand words, so a sketch should be very valuable as part of a story. As it states, "Working software over comprehensive documentation". Here is what I have noticed that we follow a process because we feel we need to. Sometimes stopping and identifying what you are solving with a process is more important. The process is there to help, not hinder.

I stated earlier that Agile is not for everyone. That is a truth I have come to believe over years. I thought everyone would see the benefits of Agile, the quick turnaround, the ability to change to improve, the less documentation and more working code, the collaboration concept rather than 12 hour meetings, but that is not the case. I have found out why too. Some people don't like visibility into their work. They don't like to be known that they are not as strong as they think they are. They don't want help because they think the don't need it, regardless if the team wants to help. Agile is for those who want to deliver great products, improve their own skills, and truly deliver things as a team.

UI/UX has come to the forefront in recent years as a critical part of developing good software/products. It is sad that is only "in recent years". I could create the most amazing product but if a user can't figure it out or doesn't like the way it looks, it will fail. I can use example after example of what is good... But the first thing that I learned about UI/UX is simple is better. Google is the best example of that. If you go back, google did one thing... they had a text box with a button. That was it. I don't care who you are, you would figure out how to search using that. Later they added images, filters, etc... but that was an iteration. The UI was a textbox and a button.

They were not the first to market with a web search, talk to alta vista about that. They did it better. Apple was not the first to bring music to the web, but they integrated it better, personally I still don't like iTunes and miss my winamp playlists. So with all of that being said, UI/UX has to come first. It is what drives the EXPERIENCE. IT IS IN THE NAME - User EXPERIENCE. There is not a user feature requirement team, we call that development. Do you want to deliver features or an amazing experience? I think it is an amazing experience.

I have gone off on tangents, talked about product development, teams, and things like that... but I want to get back my one point for this article.

UI/UX must come first to deliver the best experience, not just the best feature

I guess I have one more point about this... UI/UX developers need to do more than just photoshop mockups, they should be able to create html/css sites that have click-through experiences so the clients can see it early. It does not have to have data, it does not have to have real functionality, static HTML works fine for proof of concept. You want a good story to give to a developer, "Make it look like this and tie into the real codebase". Questions are over, because they already proved it.

The problem with that is the "artists" of the graphic world will say that is a developers job to create that. I disagree. I think a UI/UX Developer/Designer should be able to do it all and then deliver that mockup to a development team. A WORKING mockup, not just Photoshop/InDesign files. That would make it so much easier and clearer. Yes, I am putting more work on the designers, and less on the product owners, but the product owners can work with UI/UX people to make sure it is delivering the right business value, by having working sessions with clients before it even reaches a development scrum team.

Imagine reducing your rework by asking your client group, what do you think of this? And correct before you ever step into sprint grooming?

I think that is the direction Agile is going and how that debate can end quickly. I know I'm a little spoiled having some amazing UI/UX developers and great developers putting all of that together, but I think if you hire the right people, teach the right skills, and implement just enough process, you will have the happiest place to work on earth. I'll talk more about creating a happy workplace in another blog...

Thanks for stopping by.