There are many ways to attack the challenges you bring up. In my opinion, you're correct to want to both (a) avoid too much procedural stuff, but also (b) introduce a way to create some more communication between team members (and perhaps add consistency and thoroughness?) in your test design process. Kate has already mentioned a lot of great points. To offer an additional perspective,
From a "how much detail is appropriate?" standpoint,
One of the key things to get right is not bogging your tests down with too much unnecessary detail. I like using this 2x2 grid to explain useful considerations when determining how much detail is appropriate point:
From a "which approach should I use to manage my test cases as they're designed and documented?" standpoint,
I would advocate a fairly light-weight approach that appropriately balances clarity (so anyone looking at the documentation can QUICKLY understand what is being covered) and flexibility (so people on the team can make changes quickly). I gave a presentation last year on a variety of successful approaches that some teams have used, below (including mind maps and kan ban board-like solutions). For you, I'd recommend taking a look at Paul Holland's approach and the approach used by the team at Mozilla / via Marlena Compton. The slides from the presentation are available here:
From the dual considerations of "how can I make each of my tests cover as much as possible without repeating things that have already been tested (and make it easy for each group to see what other groups are already testing)?" and "how can I avoid the common problem of creating a system that leads to an ever-increasing set of regression tests that take ever-longer to test with each iteration?",
Disclosure: I created the Hexawise test case generating tool.
I would suggest considering using a test case generating tool like Hexawise or AllPairs that would allow you to quickly create (and/or quickly modify and re-generate) tests with the push of a button at the "model" level as opposed to developing a test design approach that requires you and your teammates to make changes at an individual test level because: (a) making changes to individual tests would take a lot more time, (b) a Hexawise-generated tests approach is more suitable for Agile settings like yours where tests will need to be regularly updated, and (c) a Hexawise type of test-generation approach could prevent your set of regression tests from expanding much because generating tests with Hexawise could allow you to test a growing list of new features by building most of the feature-related functional tests into an existing set of tests (e.g., scenarios exercised in existing tests can get more varied and hit new functionality vs. the more common approach of testing new functionality via adding an ever-larger list of tests).