The feature probably doesn’t matter, but we were introducing what we called the Dashboard to our product. The product was for IT guys to remotely administer networks from their mobile device. At the time, it was BlackBerry devices that were front and centre, but the product worked on Windows Mobile too.
It was a different world back then, which wasn’t that long ago.
The premise of the dashboard was to be proactive, to show the status of systems about which the IT guy was interested.
I was tapped to design and implement the client-side portion: the architecture and what gets displayed: status and two labels. I don’t really remember all the details.
I wrote a brief specification. Those are very old-fashioned, and were at the time, too. We were doing some form of Agile, but that’s no excuse to not plan a little bit. It was a just enough spec.
I described the interface for the feature in text.
We had a meeting about it. I presented the document. I asked for any questions or feedback. Perhaps no one read the spec because no one reads the spec. But I’m pretty sure my boss—our VP—read it. He liked it, he said. This is going to be great feature for us, he said.
I got to work on the feature.
I did it in Windows Mobile first, since I wrote that client. Windows Mobile apps looked pretty boring. I wanted to punch ours up with some pizzazz. That status thing could be expressed as a block of colour: green for good, red for bad. (Let me also point out, pedantically: these are bad colours for status because colour blind folks can’t distinguish between them.)
But that’s not good enough, no. We needed gradients in the whole list item. I wish I had a screenshot to show you.
This is what it looks like now:
We practiced Agile, so at the end of the sprint, I demoed the dashboard. I developed it exactly as I said I would. The demo ended.
My boss paused.
“This is terrible, we can’t ship this,” he said.
I don’t remember the exact objections. We worked through them, whatever they were. The problems were cosmetic, if I recall.
I do remember, as developer a few years out of school at the time, thinking: did he even read the spec??
He did, I reckon. It dawned on me a little while later, maybe after a couple more examples of it: he can’t visualize the descriptions in his mind. This was an epiphany for me.
If you don’t have a specification-like document, your app will suffer for it; that’s the important thing the developer needs. That describes what the screen does; the doc should cover as many cases as you can think of. It doesn’t have to be long; anything written about the main feature implies many other aspects. But if you don’t have a visual representation of it right beside the description, no one will know what you’re talking about.
You need, at least, wireframes. Wireframes just show layout and copy, no colours, no data, no images. Even these aren’t enough usually.
Are you still having a tough time visualizing Kapowski?
You’re probably normal.