What do we mean by BOTTOM-UP software design? Different software developers/designers/companies probably describe it differently, but for us at Appingo, bottom-up software design means:
Creating a software solution which solves the pain and fulfills the needs of those who will actually be using the software.
I realize this doesn’t sound revolutionary — actually, it sounds pretty obvious. Unfortunately, in reality, it is not a perspective that drives most software development. Most software development is driven from the TOP-DOWN. An executive/C-level guy wants to have more “visibility” into the operations of his business. It makes him uncomfortable that he has to wait for the next staff meeting to understand what’s happening in his business. He or she needs DATA and REPORTS which will drive forward-looking decisions. “Give me a software which gives me reports!” he calls to his troops.
So a software is developed which does just this. It offers great reporting functionality for the executive/managers. The problem is that these fancy reports are based on “DATA” that is generated at the operational level. The executive doesn’t have to do any inputting into the system. Oh no — he/she just logs in and looks at his pretty reports. It’s the people actually doing the work who have to log-in to the system and ENTER THE DATA. And this is an extra step in their daily life. “So not only do I have to do the work, but I have to log-in to some system and tell IT that I did the work?!?! WTF?!?”
So, what happens? The people doing the work forget to log-in and update the software. Or they don’t have time. Or maybe they refuse to — as an “f.u.” to management. So the data in the software is inaccurate at best….completely missing, at worst. So how good are those reports looking now?!?!
That is why we believe in BOTTOM-UP software design. We believe that a software which doesn’t solve the pain(s) of the people who have to USE it will never be effective…at ANY LEVEL. When we designed Appingo — we spent an enormous amount of time researching, watching, interviewing, and working with Production/Editorial Managers and those they employ to MAKE BOOKS. We produced hundreds of books using the system so that we could understand every piece of the process. I guess you could call it our Anthropological Stage (Tom Kelly, founder of IDEO, talks about the role of the Anthropologist in innovation in his book TEN FACES OF INNOVATION). We learned and we built. We solved two frustrations for the Production Manager and watched some more. Then we solved a couple more and watched some more. And on and on it went.
Once we felt like we really solved the pains for the people who had to USE the system on a daily basis, we were happy. And guess what? Because we solved their problems, they used the system — every day, all day. And because they used the system, THE SYSTEM COLLECTED DATA on the operations. Without any extra work for the Production Manager (actually without her even knowing), we are able to produce a slew of very powerful, executive-level reports. And guess what else? These reports are ALWAYS up-to-date and ALWAYS accurate!!
So when I hear a software developer complaining about “adoption rates”, I can’t help but smile. You’ve heard it…
“The problem isn’t the software. The problem is the stupid people at [Company XYZ]. If they used the software, it would work just fine!”
It NEVER occurs to a developer that maybe, just maybe, the problem lies in the software and/or the process under which it was developed.
Think about it. BOTTOM-UP usually wins.
Cheers!
Derek

1 Comment
October 22, 2009 at 6:12 am
Some might do it every day, while others might update every two weeks. ,