This summer, I read several blogs and books by former Microsoft employees. One of the first names that stood out was Joel Spolsky. He joined Microsoft when the company was still relatively small and worked on major projects like Excel VBA. While reading his early blog posts, I realized just how much I still had to learn.
Another key figure was Jeff Atwood, the creator of the Coding Horror blog. He and Joel co-founded Stack Overflow in 2008. Both are brilliant minds in the field.
Lastly, I came across Kraig Brockschmidt, a developer whose calculator app was included in early versions of Windows. I’m quite sure today’s version is still based on his original work. He’s also the author of several books, including Mystic Microsoft, which immediately earned him a place on my follow list.
🧠 Software Design Principles for Real Users
I came across some key principles and personal advice on software design in one of these books or blog posts. Though I don’t recall exactly where, the ideas stuck with me.
Two core ideas were emphasized:
Users don’t read manuals.
Even if they could, they wouldn’t want to.
These may not be completely true, but assuming they are helps us design better software. Designing this way is called "Respecting the User." In reality, it often means not relying on the user at all.
One way to measure ease of use is to check how many real users can complete a task within a fixed amount of time. For example, say your program converts photos into web albums. Give 100 people a computer with your software and see how many succeed. The more people can use it with minimal instruction, the better your design.
Most real-world users aren’t experts. They may not be tech-savvy. They may also be surrounded by distractions. That alone is enough reason to expect some users to fail or take too long. It doesn’t mean they’re not smart—it just means they’d rather not spend their brainpower on your software.
📘 Nobody Reads Manuals
Most software doesn’t even include a printed manual. Even if it did, people wouldn’t keep it nearby. And if they did, they wouldn’t read it unless absolutely necessary. People expect to get their tasks done right away. Reading feels like a waste of time. So your software should not rely on manuals to function.
👀 People Don’t Read Anything
This is something you quickly notice during testing. A user might ask how to do something simple, even though there’s already a clear instruction on the screen. The longer your message is, the fewer people will read it.
Experienced users don’t read because they think they already know.
New users click "Next" or "OK" without reading anything.
A small group reads the screen but might get even more confused.
When your software throws a warning, it usually means the user is about to make a mistake. Yet vague or annoying prompts—like "Are you sure you want to quit without saving?"—may only confuse or irritate users, causing them to click the wrong button.
🧠 Don’t Ask What the Computer Can Remember
This is a big one. One of the best ways to improve usability is to let the computer remember what the user shouldn’t have to. Auto-complete is a great example. Microsoft Office uses it extensively, and Google search has mastered it.
Also, limit the use of pop-up messages. Message boxes interrupt users and break their flow. Only use them when absolutely necessary.
🧪 Test Often, Really Test
Alan Cooper, considered the father of Visual Basic, once said:
Writing a Windows app is like Microsoft giving you the periodic table and asking you to make broccoli.
It’s not easy. That’s why testing is essential.
🧱 How Microsoft Structures Development
In Mystic Microsoft, Kraig explains that Microsoft’s development process has three key roles:
Program Managers imagine features users can’t live without.
Software Engineers turn those ideas into working code.
Testers make sure everything works as intended.
Testers play a critical role. You should appreciate them, but you’ll probably hate them too—because they’re good at what they do.
Say you give them a shiny new vehicle meant for military transport. They won’t just look at it—they’ll throw it onto a battlefield. When it breaks, they hand back the wreck and say, "It failed." As a developer, your job isn’t just to fix the problem but to figure out why it happened.
You’ll then hand it back to them. And they’ll test it again. This cycle continues until they’re satisfied.
✅ Final Thought
Designing software for real users means designing for people who are tired, distracted, impatient, or unfamiliar with technology. If your software works for them, it will work for everyone.