How do you design your test case? How many steps, and how long is better to execute a test case?

Hi, recently we got feedback on test case quality, some complains on lots of expected results per a test case, that bring a deep discussion on that.
Did you think about the question? What is better for a test case with 5~6 steps and exepected results or just with 1~2 expected results? When you are designing test cases for new features, what should be considered to make sure good quality, easy to maintain, and good coverage, and good productivities to execute them?
I proposed several types of what we meet often, let's check what is the best?
- 5~6 steps Vs 5~6 expected results, each of which should match each step.
Benefits: Can do a completed functionality of a phone, including several interactions, like sending SMS/MMS, or Alarm event, etc;
Weakness: A little complicated, need tester have a full understanding before start to execute, and the coverage is defined from designer's head.

- 3~4 steps Vs 1~2 expected results, just check key points according to requirements, ignoring the common sense points, or minor points to end users.
Benefits: Easy to know the test coverage to requirements, traceable;
Weakness: Didn't deep dive, not enough to check some hidden defects

- 1~2 steps Vs only one exepected result, per my understanding, just check basic functionalities, or sanity test?

Anyway, I personally preferred the 2nd type as main test case model, and sometimes we can use the 3rd type as sanity test in order to quickly go through phone basic functionalities. In most cases, we have to do part regression test after new fixes are built in, or new features are integrated, we can use the 2nd type case with some exploratory test cases.

So what my next question is? How to design an exploratory test case? Any guideline or tips? How to know it meet your expectations? In other words, in black box test, are most of findings from test case executors or from case developers? Why?

Thanks,
Gaochuang