Requirements, Specifications, and Interface Design

Before anyone writes code, someone has to decide what the program is actually for. That starts with investigation: talking to the people who will use it, watching how they work now, and figuring out what they need the program to do. Those findings get turned into requirements, plain statements like "the app must let a user reset their password" or "the app must work with one hand." Collect and organize all the requirements together and you get a specification: a complete, checkable list of behaviors the finished program must have. Only once that list exists does it make sense to sketch a screen layout, because the layout's job is to make every required behavior reachable and clear.

Writing the specification first feels slow, but it is cheaper than the alternative. A team that skips it tends to build something, discover it is missing behaviors users actually needed, and rebuild. The hours spent writing a clear specification are almost always smaller than the hours saved by not redoing work.

A requirement like "must work one handed on a phone" changes the interface directly: buttons move within thumb's reach, menus collapse instead of spreading across the screen, and actions that needed two hands, like pinch to zoom, need a one handed substitute. Design choices like these trace back to a specific requirement, which is why the specification comes before the layout and not after it. This connects forward to testing: once a specification exists, you can check a program against it item by item, which is exactly how you catch the gap between an interface that looks finished and a program that actually is.