What drives a nugget along, in her little 20 piece box!

I've finally started poking around LinkedIn because it seems, unlike all the other social networks out there, to actually have a point. XD (I'm really REALLY not big on social networks, I tend to avoid them like the plague).

Soooo.. 'Write a profile, nugget, write a profile!' quoth LinkedIn. And verily (wearily) I did.

I started with a cut/paste one from my Web Design and UX Portfolio... which somehow turned into a rant worth reading.

And so without further ado here we go!

While I've picked up a rather eclectic design skillset over the course of my career, including (but not limited to), web design, copywriting, packaging, animation, and front-end development, there's a single passion that unites all these things.

Improving people's lives by giving them kinder, saner tools.

Yup. Cliched. Corny as Hell. Still true.

I'm not talking world-shaking, changing-the-course-of-history improvements.

I'm talking small, everyday improvements. Improvements that make someone's day just a little bit better, preferably over an extended period of time. An easy, concrete example? Search with autocomplete. And there are so many, many more.

I believe that the tools we use should give us feelings of delight or mastery - or at very least, not make us feel like idiots. Kinder, saner software (because software is a product and a tool, as well as a service) isn't just good for customers, it's good for software companies too.

These kinder, saner tools are the ones that

...we vote for with our wallets.

...help us do things more quickly, more easily, more painlessly, and sometimes, even more enjoyably.

...allow us to go home after a hard day's work with the satisfaction of a job well done - and not the frustration of having spent a day fighting the very software that's supposed to help us.

And if, at the end of the day, I get to make these tools look sexy - that's a bonus. ;)

Unusual And Alternative Prosthetic Limbs Designed To Stand Out

I've posted something similar before, but where the other one was elegant, this is quirky. Both are wonderfully crafted, and I think it's beautiful, needed work - changing a source of potential social awkwardness to a unique and lovely talking point and source of pride.

Can't help wondering what it would have been like if scoliosis braces like this had been available in my day.

Don't confuse poor analysis with a lack of need for any analysis

You've taken the prevalence of bad analysis and design practices as evidence that they simply don't work. Doing it correctly requires a deep understanding of the problem domain, of the people who will use the product, and what technology can do. Yes, most practitioners are terrible, but it's brazen ignorance to state that analysis and design (requirements being the output thereof) are bullshit.

My experience with developers (and I include myself when I was one) has been that they are good at building things right, and not so good at building the right thing, except in the narrow space of products that programmers use. They can build what they want, and they can build what a customer says they want, but they are not effective at listening to what a customer says they need and figuring out what that actually means.

Because most clients, if you ask them directly what they want, will describe a solution based on their own flawed assumptions about technology, and they often don't understand their own problem very well.

If your sales force is saying they need a new order entry application because the one they have is slow, and you take them at their word and start building one, that's just plain stupid. Maybe it is simply difficult for them to use. (They are sales people, after all, and they use the system infrequently.) Why the fuck are the sales people entering orders anyway? Is that something customer service can do? Can the customers enter their own orders? Your going in assumption should be that whatever solutions your clients propose are at best illustrations of some of their concerns and not the actual requirement. You have to look at their business, at what they do, at the people and processes surrounding it, at the larger context in which it all happens. Otherwise you're just wasting time.

My experience has been that people who can do this well are rare and they aren't programmers at the same time they are analysts. Many were programmers, and some may go back and forth, and on small projects it doesn't matter so much, but for complex requirements it is damn near impossible to keep both models in your head at the same time and retain the necessary objectivity. If you're thinking about the code, you're going to gravitate to solutions you want to build and not the solution best suited to the problem at hand. You need to be grounded in an understanding of what is technically possible/feasible, but at the same time you need to forget about that and pretend you have magic fairy dust and anything is possible. This paradoxical thinking tend to hurt your brain and the end result has to be something doable, but it allows you to explore a solution space much larger than a "what can we build" mindset will afford. There are some developers who can do both, but you don't get many opportunities to hire them.

In the consumer space, it is the same, just fucking harder still because consumers haven't got a clue what they actually want or what technology can do and if you only target those products that developers would use and understand, then you're severely limiting your target market.

Look at a company that does this for a living well and you'll see that it can be useful. Apple gets it. How their process works exactly I don't know, but I promise that someone is doing "business requirements" in the sense of thinking deeply about what problems they are actually trying to solve for who, and how the product will actually be used in real life. When I saw the iPhone for the first time, my immediate reaction was "Apple is going to make a big pile of money" because they were the first company to really nail the requirements in the cell phone market. Everyone else previously was just building what their developers thought would be doable/cool or under the sway of designers who didn't know what they were about.

Or if you want a more generic example of someone who at least has a chance of getting it right, look at Cooper design. They have some concept designs posted on their website that are, in my opinion, examples of what a "business requirement" should look like. Note that while the designs could be built, there's nothing in the requirements about how they should be built and there are some interesting business and technological challenges that would need to be overcome. I would suggest that many or most successful technology products (iPhone, again, for example) are the result of solving such interesting challenges and therefore one benefit of good requirements is that they can direct our attention to the problems worthy of solving if we want a successful product. Too often we invest time in optimizing or creating features that nobody actually cares about.

Anyway, aside from being completely wrongheaded and misinformed, nice post.

Comment from a long rant, "Stevey's Blog Rants: Business Requirements are Bullshit".

The rant is nonsense. It does what my title says - confuses poor analysis with a lack of need for any analysis.

The rant-comment though, is epic. ;)

Requirements gathering and the analysis that has to be done to come up with those requirements isn't the same as simply gathering data.

Data are the dots in an (unnumbered) connect-the-dots painting.
Analysis is drawing the lines that connect those dots into a bigger picture of a plan.
Good analysis means that the plan you've just come up with has a good chance of leading to phat lootz.