Agile methodologies. Lean Startup. Lean UX. Agile UX. User centered design. Human centered design. Mobile first. Responsive design.
Today’s January 12th, 2015. If you’re reading this a week from now, chances are you’ll be able to add the next buzzword to the list above.
Hype needs names, so that everyone who’s not willing to go the distance and actually learn the thing, at least can adscribe to it and require his colleagues and providers to know it thoroughly. Plus, a certified The-Thing Master course industry can emerge.
Here’s a little secret: no matter which of those practices you’re trying to implement, if you’re not getting user feedback periodically (measured in weeks at most), you’re doing it wrong. So, yeah, you could claim you’re doing agile, but unless you’re actually letting someone who’s not part of the design and development team play with your work at the end of each iteration, it’s just Waterfall thrown to the washing machine.
If you can’t afford a Scrum certified master course, take it easy. Start by sitting down with people and asking about themselves and what they do everyday. Show them what you’ve done and pay attention to their reactions. Let them use it and welcome the WTFs. Take notes of every finding and make sure the rest of the team gets it. Plan on how to follow up on the learnings. Start over.
Fortunately, this is hardly new advice for you, because the industry is maturing and the importance of creating interactive products with constant user involvement is becoming collective knowledge.
So, why do I mind writing this? Remember, there’s hype, which makes everyone ask for certain keywords when contracting a software design or development agency. What do you do when a prospect contacts you for a project and asks you whether you do agile (or UCD, or HCD, etc.)? You say: “Hell yeah!! I’m SO GLAD you asked.”.
Prospect crosses out “Agile” from list, hands shaken, contract signed, toasts ensue.
After that, you meet for the first time, lay out project goals and deadlines, roughly state how you’ll collaborate with each other and head confidently for a great start. Then something goes wrong.
You ask your client for relevant people:
-Could you put me in contact with the folks from your organisation who are supposed to actually use this?
And you get something like:
-Oh, I don’t think that’s possible, because [BUDGET, APPROVAL FROM MANAGERS, VACATIONS AND ACTS OF GOD]. But, hey, I thought you already had all you needed to get the job done after yesterday’s meeting […] So, you need more feedback? […] Hey, no problem, we’re also agile! You can email me anytime you need and I’ll answer any question you may have! Just start working with what you have, because deadlines are crucial, you know.
Off the alarms go.
What went wrong? Nobody took the time to explain your client what agile, or lean, or user centered, or your-next-buzzword means for them. You should have, before actually signing any sort of formal agreement.
What are her rights as a client? What are her duties? What kinds of resources does she need to make available to you so you can produce the great results she’s actually paying for? How often is she supposed to meet with you?
The success of a software project depends on healthy relationships amongst every human being involved: the ones who pay, the ones who design and develop, the ones who use and the list goes on.
In more traditional markets, relationships are a lot simpler: you go to the drugstore, order some meds, the clerk gives you the meds, you give her money, and that’s it. You paid, you got what you wanted, off you go.
In software, it’s a lot trickier. As a provider, it’s your responsibility to clearly state what you expect from a client in order to deliver high quality work. That means you should leave the buzzwords for the PR folks and talk about concrete practices instead: “We expect you to take a look at our progress once a week”, “We expect you to help us meet with future users of this product on a weekly basis”, “We need you to specify the business value this feature compared to that other one. Yes, you'll need to prioritise sometimes. No, ‘all of them’ is not a valid answer”.