[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GMG-Devel] Feature design

From: Jef van Schendel
Subject: Re: [GMG-Devel] Feature design
Date: Tue, 6 Nov 2012 01:29:46 +0100

2012/11/5 Christopher Allan Webber <address@hidden>
  - Jef points out that we should "know our audience" and thus we should
   have "personas"... basically prebuilt "users" of our software shown
   in examples.

Well, to nitpick, I didn't say "should". :)

The thing is, I can list a dozen of these design techniques, but I have no idea (and too little experience as a designer) to know how effective they are (if at all!).

I think what's interesting about the design principles I talked about are these two quotes[1]:

"Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole."

"In order to be most effective, however, design principles need to provide teams with a way to gauge design decisions. That is, they should be specific enough to help groups of people choose between different design options."

So they should provide us with a way to check "am I making the right choice here?".

What I think we should do is:

- Describe, at a very high (the highest!) level what we want MediaGoblin to be. Say, a single sentence.
- Then, identify what qualities are most important to the project. For instance: being efficient is a good quality, but should it come at the expense of learnability? These kinds of choices define the type of software we're building. So when we run into a hard decision, we have something to base that decision on. We can look at these and say "look, we decided this is more important to us, therefore we should make this choice".

Then, we get down to individual features. And my hope is that since we've set the things above "in stone", as it were, all features will share a common direction instead of going wildly different ways.

What I think is interesting about the personas example is that it approaches things from a user's perspective instead of a technology perspective. But that's something every decent designer should be doing anyway, so I'm not sure if they are really useful to us. Increased interaction between developers and designers in the project, together with lots of open conversation about (and iteration of) things we are implementing, should help with that.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]