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.

Forsaken World: War of the Ancients Basic Guide

Updated: 7 Jan 2013 - Katze's comments incorporated - Please read them too, they are very helpful!

If this is your first time in WotA, you'll only be able to pick from 2 kinds of 'mob' that you can be. As you gain more ranks, you'll be able to pick from more types of mobs.

At rank 2, the Flagbearer becomes available. The Flagbearer is a melee attacker with a speed boost.

At rank 3, the Conjurer becomes available. The Conjurer is a ranged attacker with a debuff that increases damage done to the target.

At rank 4, the ??? becomes available. The ??? is a melee attacker with a debuff that massively slows a target.


If you only have Warrior and Wizard, pick 'Wizard' - ranged DPS
The Wizard's advantage over the melee 'Warrior' is that it has a much greater range. Especially on boss mobs that come out at every 5th round, this is crucial.

It's advisable to rebind the 2 skills given to you to your normal 1 & 2 hotkeys on your skillbar.

After you pick a mob, you'll be ported into the centre of the instance.

Katze-licious advice:

It's easy to get turned around and lose your way in WA because everything looks the same. Move your toon close to the north entrance and swing your cam appropriately- you can see which way you're facing by looking at the minimap. 

 

How It Works
WotA is basically a tower defence game. Your character's class does not matter, only the mob you pick.

Large purple arrows point towards the direction of the portal mobs waddle gamely towards. Your goal is to kill them all before they get there.

You start off with 30 'Seals'. Every monster that reaches the portal will reduce the Seals by 1. It doesn't matter if the monster is weak, strong, or elite. The exceptions are the Bosses that waddle out every 5 rounds. Each boss does 15 points worth of damage to the Seals.

When your Seals reach 0 (or negative), the instance ends.

As more and more mobs load, what tends to work better is to prioritise killing off the weak mobs. Elites and strongs take much longer to kill, but still do the same amount of damage to the Seals as weak mobs (i.e. 1).

Round 1-4
An instance announcement will be displayed:
E.g. "Alarm: [South] The rift is changing, monsters will appear soon."

This means that monsters are appearing to the south, and going in the directions of the purple arrows towards the portal they want to reach.

Ideally, ranged DPS should be positioned as shown here. This positioning gives you maximum range both on the portal, and if you spin around, on the mobs as they trundle past you, should you fail to kill them all before they walk past.

 

Round 5 onwards

Mobs will now head towards the end portal from 2 directions. An instance announcement will be displayed:
E.g. "Alarm: [Northeast] [Northwest] The rift is changing, monsters will appear soon."

You will need to split your party to deal with the 2 portals. There are 2 possible kinds of splits.

Short Roads to Portal
No purple arrows visible at centre.
Both sets of purple arrows are headed directly towards the Portal, without crossing the centre of the instance.

Strategy
Split into 2 teams of 3 members each. One team will take the first location, the other will take the second.

 


Long & Short Roads to Portal

Purple arrows visible at centre.
Long Road: One set of purple arrows is headed towards the Portal, crossing the centre of the instance.
Short Road: One set of purple arrows is headed directly towards the Portal, without crossing the centre of the instance.

Strategy

  • Split into 2 teams
  • The Short Road team:  4 members, because a shorter road to the Portal means less time to kill.
  • The Long Road team should have 2 members, since they have more time to kill the mobs
  • After the Short Road team is done with their mobs, they should double back to see if the Long Road team needs help

In the screenshot:
Monsters heading from the Northwest to the Southeast are taking the Long Road.
Monsters are heading from the South to the Southeast are taking the Short Road.

 

After round 5's spawns are cleared, the round 5 boss will appear. It is extremely important that everyone be waiting at the gate where he spawns, so that DPS can start immediately.

Use your 2nd skill as much as possible. When you have to run to keep up with the boss, which you eventually will, run while the 2nd skill is on CD. Stop when it's almost off CD so you can fire it off again, pelt him with 1 as much as you can, and repeat.

The round 5 boss is doable with 6 wizards - you don't need anyone rank 2 and above, though of course, it helps. ;)

Rewards
  • Round 5 and 10 bosses each award 10 soul leaves when killed. 
  • Round 5 boss awards an Anima: Shelter (claimable from NPC outside the instance, in Bloodskull camp). 
  • Round 10 boss awards a quest that lets you exchange 30 valor tokens for an Anima: Shelter upgrade item.
  • Round 15 and 20 bosses each award 20 soul leaves when killed. 
  • Round 15 boss awards a quest that lets you exchange 50 valor tokens for an Anima: Shelter upgrade item.
  • Achievement for Round 15: Stand Fast
  • Achievement for Round 20: The Good Fight

 

 

... and that's about it!

Note that each subsequent boss gets harder to kill, and the Round 10 boss miiiiiight be possible with just Wizards, but it's unlikely.

As you get more ranks, and unlock more mob roles, you'll be able to kill more than the Round 5 boss. That goes a bit beyond the basics though, so I won't detail it here.

This is where the group I took all these screenies from ended. =)


Happy hunting!

Forsaken World: They're just so good at ridiculous tartiness.

Before I get people up in arms, that's not equipment - that's fashion, and all of us have chosen to wear it. XD

(The toon on the left is mine.)

Funnily enough, especially as you get to higher levels, the female equipment models in FW tend to cover more skin than the 'epic plate armor'  models in many other MMOs.

So of course, we then have to wear ridiculously silly tarty fashion. Ahem. XD

This author should really go Lorem Ipsum herself.

For those who would argue that it's impossible to evaluate designs without real content, let me ask this: why then, is it okay to evaluate content out of context of the designs? To review copy decks devoid of color, typography, layout, and styling means that readers are missing out on the important signals communicated by design-cues to priority, weight, and hierarchy of information, but also emotional and aesthetic appeal. If content strategists want to ask designers to stop using Lorem Ipsum, maybe designers should insist that content strategists add style sheets to their copy decks that match the proposed design direction.
via uie.com; emphasis mine

Why?

Because, you utter failure as both designer and writer, good writing should be powerful even if it's untidily but legibly written on 100 sheets of onionskin.

P.S. I agree that Lorem Ipsum can be used in the correct context, and is a valid tool. But the paragraph above is an incredibly annoying straw man argument. Oh, and she's also missed that design supports content; the reverse is called art.

Common-sense rules-of-the-thumb for designing software that makes sense

Excerpts from a JIRA article I wrote at work.

Make system status and feedback clear and visible
Use status mechanisms to keep users aware and informed via appropriate feedback, and within a reasonable timeframe. Status information should be up-to-date and easy to spot.

Present information with meaningful aids to interpretation
Use words, phrases and concepts familiar to users - don't use 'programmer speak'. Use everyday terms, or familiar frameworks.    

Help users recognise, diagnose and recover from or resolve errors
Give users a "way out" when they make mistakes (e.g. cancel). Where Undo/Redo is not possible or viable, present users with solutions.
E.g. The supplier record could not be deleted because transactions have been made against it. <Deactivate Supplier Record> <Cancel>

Use clear, consistent language, and names/labels that are conceptually related to their functions
Standardise language across your platform. If 'Cancel' means 'Exit without implementing any changes' in one context, it should mean that in all contexts. Whenever possible, button labels should be specific, rather than generic. (e.g. 'Save & Exit' vs 'Okay').   

Help users not to make mistakes
Present users with a confirmation before they commit to an action with serious and/or irrevocable consequences. In such cases, it's a good idea to place the Commit and Cancel buttons far apart to prevent users clicking the wrong buttons by mistake. If keyboard controls are in play, require the users to either click the (far apart) buttons, or to commit by pressing a specific key or key combination, rather than tab-Entering.

Display only the information a user needs to complete a discrete task at a given time
Don't make users remember information from one part of the dialogue to another, and don't pepper them with information irrelevant to the task at hand.

Make the right things invisible
Automate and/or hide tasks/functions users have no control over, but that the platform requires to work.  

Group information consistently and meaningfully
Don't make users search and mix-n-match information from all over your page if what they're looking for falls into an identifiable group. (E.g. Address, Mobile, Fax..)   

Reduce user workload & set meaningful defaults
Pre-populate standard fields whenever possible and/or helpful. Base defaults on choices that the majority of users would make. Default settings should make things easier on the standard user, not harder.

Notes:
This list was based on Jakob Nielsen's heuristics as published in Usability Engineering, Jill Gerhardt-Powals' work in Human Computer Interaction (paid link), and Bruce Tognazzini's First Principles of Interaction Design.

Poor Glitch. :( 9th December 2012, R.I.P.

Sad Glitch Girl

A Sad Announcement from Tiny Speck

This is a horrible day. This is a horrible thing to have to say: Glitch is closing. The live game/world will be closed on December 9th at 8pm Pacific time (see when this is in your time zone). The website and forums will remain available until the end of the year, so players can still communicate and find each other. Glitch HQ, the Glitch API and third party applications which rely on the Glitch API will become unavailable at the same time as the website closure.

Automatic refunds for recent purchases will begin immediately. Refunds for older transactions will need to be done manually and will be processed as quickly as possible, from most recent to oldest. For details on your payments, to request a refund, or to see the status of your refund, please visit the refund information page.

Unfortunately, Glitch has not attracted an audience large enough to sustain itself and based on a long period of experimentation and our best estimates, it seems unlikely that it ever would. And, given the prevailing technological trends — the movement towards mobile and especially the continued decline of the Flash platform on which Glitch was built — it was unlikely to do so before its time was up. Glitch was very ambitious and pushed the limits of what could be done in a browser-based game ... and then those limits pushed back.

For many of us at Tiny Speck, the creation of something like Glitch was a long-held dream. There's no better word than "heartbreaking" to describe what it feels like to have to do this. And we know that for many of you who poured your creativity, energy and imagination into Glitch and the community, it will be heartbreaking as well. We are sorry to have let you down.

We are grateful to have had the opportunity to play with you. The game was absolutely preposterous. And yet, we kind of liked it.

I had an amazing amount of fun in Glitch - far, far more than I thought I could have in an MMO without killing.

Everything about Glitch was charming, and almost all of it went beyond charming to brilliant. The only problem is, I couldn't understand how the Glitch model could make them money, and apparently, it couldn't.

I was one of the initial subscribers, and when the game launched, TinySpeck did the amazing thing of allowing initial subscribers to cancel and be refunded - because, they said, they had the money they needed to launch. I was amazed by the generosity they showed there, and even more impressed by how they're handling the refunds now.

Glitch was a brilliant, crazy, beautiful, polished but unsustainable experiment, and the world will be the poorer for its loss. :(

"I savor my chocolate with the zeal of a lion taking down a zebra."

You know those Dove Chocolate commercials? The ones in which the girl takes a bite so small it probably requires her six bites total to eat one tiny square?  She always eats in slow motion.  What are the people in the chocolate business trying to tell us?  Eating in slow-mo somehow means you’re savoring this cocoa luxury more than you would if you ate it in real time?  Um, I disagree.  I savor my chocolate with the zeal of a lion taking down a zebra.  I think that means my love is true love.  It also means I could never be in a chocolate commercial.

XD I'm pretty neutral about chocolate (which is a bit odd considering all the chocolate things I've made / am making / am planning to make), but that description is just wonderfully hilarious.