What are clear specs, anyway?
Front end and web designers usually take business requirements and turn them into spec-storyboards that everyone uses to define the project. So from the point of view of how business requirements should be presented, most experts might agree that mile-long text should be avoided at all costs. Under normal circumstances, devs hate to read 30-page documents with 10 pt fonts, or PowerPoint slides with 20 bullets per slide.
This limits the options, though. However, a great way to communicate is verbally. Talk about the business problem with the PMs and really understand their point of view. Jolt down your own notes. Why is something important? Where is it going? What is the story that they want to tell the customer? Not user stories in the agile method, but rather customer-facing stories that inspire their imagination and aspirations. Paint a picture, weave a story, get everyone interested.
After those verbal sessions, start to create the storyboards and information architecture and other parts of the UX. The PMs collaborate and make sure that no business requirements are being left out. Notes, callouts and other annotation is used to make sure nothing is missed.
Devs could spend a ton of time writing long text that people skim through, but whats the point? It saves time to dive in and collaborate on the actual design. It’s easier to digest and present. Story telling is one of the best methods to communicate business requirements.
