zenmonkey wrote:eido wrote:I don't know. I don't think it's good, but eh. I tried.
It is good, that's a great description. It's
exactly how design work should go. In design thinking (before it became the next great thing and a buzz word) we go and gather
user stories, which is what you have provided above. Usually, by gathering a few, one can develop a profile, user requirements, process steps ... etc and from there come up with functional needs, design ideas, etc that then make it (or not) into a product.
For example I'll take up two things you mentioned. I'm not criticising these at all, I'd agree but would want to dive in and ask more questions.
1) begin with pronunciation - teach the alphabet. These aren't exactly the same thing - one is the way the language sounds and the other other is how it is represented in the written form. If your audience already knows written English is teaching the alphabet really a focus? Or are we talking about teaching the association of certain written clusters into sound Ximena, Eugenio, Julio, Carmelita xumo, judo, hotel are all representations that Americans would fail to pronounce correctly without instruction. Would it be working on that or more on A, B, C for people that really can't read in Spanish?
2) Having native speakers rate the pronunciation. That would be ideal but is it realistic within an app? it requires getting those speakers, making them available, hosting recordings, etc... so we would add a web sever, web site, etc... Pretty soon that is a big project. Or is there another way of doing this? What is important here, it seems, is that the user get quick feedback on pronunciation? How can we do this with live or automated ways ... (it's something I've been thinking about in another project).
So from these, you can begin to think about a look and feel for this initial part. Still interested? Draw yourself a quick screen of the pronunciation screen as you think it should be -- is it like an Anki card? What does it include...
Now, in terms of a project. Early on you need to ask yourself, "Am I really interested in learning to code?" If yes,
great, there are steps for that. If just maybe or not really, or only if I have to -
great, then there are ways of learning a bit, creating mock ups and seeing how that might evolve either way and finally, if you are in the camp, no way, no interested in coding - well... that's
great too because you can then decide to focus on designing your requirements, other business aspects and finding someone who will do the actual development. And you can change from one camp to the other - but it usually means you've wasted some effort - but it's important to place oneself early on to decide what steps come next in the design process - someone who is doing their own coding needs less formalism in design versus someone who is going to communicate a design to a someone else who is going to execute it.
