Coming up with a great idea is only half the battle. Persuading the people that matter is the other half. Here are some good tips for presenting not just wireframes, but any idea or project to decision-makers for maximum impact with minimal friction: Tips for Presenting Your Wireframes via Balsamiq UX Blog
Your ability to be thoughtful about a problem and articulate any solution is more important than your ability to design the perfect solution every time.
– Tom Greever
If a picture is worth 1000 words, a prototype is worth 1000 meetings.
Tom & David Kelley, Creative Brothers at IDEO
UX is a process. Like a science. You must experiment with it. You must practice it. Yes, like a science.
As a Business Analyst (BA) on an agile team, user stories and acceptance criteria are my bread-and-butter. But when I first left the comfort of elaborate requirements to embrace the simplicity of user stories and acceptance criteria, I found the concept flexible yet challenging. This article by Sandy Mamoli helped clear out the cobwebs.
Yes, they are different things! Here is everything you need to know about user stories and use cases.
Business Analysis is not the right profession for you if you:
- Like doing the same things day-in and day-out, rinse and repeat
- Never wonder why things work the way they do
- Are afraid of looking dumb (mostly in public)
- Are afraid of asking questions
- Hate steep learning curves
- Don’t like change
- Can’t handle confrontations
- Can’t stick your neck out for the team in bad times
- Enjoy living in a sane world with reasonable expectations!
There has been much written about the role of a Business Analyst on agile teams recently. Some gently “question” the need for a BA. Others are outright hostile calling a BA “an additional monkey that’ll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work”.
I try to keep an open-mind when it comes to debates (I do love a good debate! Probably more than I should). But when I read such articles, try as I might, I come to the same conclusions. Either:
- They have a narrow view of what “agile” is
- They don’t really “get” what a BA does
I can list a number of reasons why a BA is essential to the success of a project, be it in an agile or waterfall environment. But there are others, far more eloquent and knowledgeable than I, who have written about it:
The Agile Manifesto itself seems to be taking a direct swipe at Business Analysts when it talks about valuing “working software over comprehensive documentation”and “customer collaboration over contract negotiation.” Somehow, Business Analysts have ended up as a proxy for everything bad about the “Waterfall” development method…