Over the past two years, I’ve been building a web app. I designed it. Coded it. And now, two years later, we’re in beta testing. It’s been a long process, mainly because it’s been just me, pushing pixels and stealing a line of code here, a line of code there. It was a long process because it included a lot of learning…the hard way. I’ve made a few (major) mistakes.
I didn’t show people early or often.
As a perfectionist, I’m very protective about my work. I don’t let people see what I’m working on until I’m ready. I want them to see the best version of what I have, best foot forward. —No need for them to give input on something that’s half baked.
The problem with that mentality, though, is I took the project down roads that I never should have gone down. I worked with blinders on. What I did made sense to me. I put my engineer hat on. I thought about the back end and the code and the logic and forgot about the people that would actually be using the system. When I finally did show people, they would (quickly) find problems.
“Why doesn’t it do this? What do I do now?”
“Isn’t that obvious?”
“Well, no.”
I should have showed people early and often. I should have talked to the people that would be using the system and find out what they really needed instead of giving them what I thought they wanted.
Two of the best books out on interface design is Rocket Surgery Made Easy and Don’t Make Me Think, both by Steve Krug.
In Rocket Surgery Made Easy, he talks about corporations that will pay thousands of dollars to have experts analyze their sites. When, really, all you need is Joe Smoe end user. He’s your target audience anyway (not the expert). Simply watch Joe use your site. You’ll learn so much by simply paying attention to where he clicks. Where’s the first place he goes for information? Does he immediately know the purpose of your site? Does the navigation make sense? Joe’s not short on opinions, you just have to be willing to ask and be humble enough to hear what he has to say.
I never gave people a reason to need the system.
When we got ready to beta test, I was invited to a leadership meeting to introduce this new tool I had created. “Here it is! My web app will make your life so much easier. Look at this bell here and that whistle there. Isn’t this great? I’m doing you a favor.”
After that meeting, I kept hearing, “This is great. I’m sure it’s useful, but my pen and paper method worked just fine.”
Really?
I could dismiss it. They’re older. They just don’t understand technology. But, is that a fair assessment?
How does my web app make their life better? The administration understood. They knew it would dramatically cut down on data entry, emails, reminders, and processes. But, I failed to communicate that to Joe Smoe. There was disconnect between their need and my app.
So, how do I close that gap? You tell a story. A good story always has a problem. Then, it works toward a solution. My end user may not know what the problem is. I have to define that for them. Then, hopefully, my product, my web app is their solution. I need them to buy into the system, otherwise it will never get used. It will fail before it even has a chance.
I didn’t mimic a system they already knew.
After a month of testing, I had a beta user that believed in my product. He had a background in Internet Technology and was willing to sit down for coffee and walk through my app, discussing points for improvement.
One of the first things he did was pull out a folder with a print out. “This is the system we know. Flawed? Maybe, but we’re used to it.” Then, he pulled up my web application. The two looked nothing alike. — which is fine, except for one thing. It didn’t give my users a frame of reference. They needed something to go off.
Let’s look at Apple as an example of doing it right. Address Book in Lion looks just like an address book I could pick up at Office Max. Notepad on my iPad looks just a yellow legal pad. Why? Because these are systems I’m familiar with. There’s something about translating the physical world to the digital that gives the user a sense of comfort. I know how it works in the physical world, therefore those metaphors must carry over.
These lessons are hard when you’ve put in time and energy. But, now I know.
What are some lessons you’ve learned the hard way in web development?
