Methodologizing

Methodologizing

A few days ago, Sunil gave me some advice on starting up a business, based on his own experiences in Taiwan. The piece that stuck out was his emphasis on developing a methodology–how the business will get things done, if I understand correctly. This is different from the usual “make a business plan” advice you usually see, and it reflects Sunil’s emphasis on good execution. So I might as well start making stuff up:

As I start to write this, I’m finding that I want to establish some baseline principles about the kind of company culture I want. My gut tells me that this is not the point of this exercise, so I’m going to focus on process.

Ooops, I forgot I didn’t know what kind of company I want! Um, let’s say it’s the Screen Designers Guild, a company that specializes in designing graphical user interfaces (GUIs) for products that are yet to be developed. In other words, a concept design company for screen-based applications. The focus is on developing visual concepts, not hardcore development. For most types of software, the development aspect is fairly trivial compared to getting the design of the application right.

The hypothetical process of doing this kind of work:

  1. Identify areas where an enabling software technology has surged far ahead of good design. These are fertile areas of exploration. Instant Messaging, for example, has been hot for quite some time, with dozens of IM clients being built every year. However, while the feature sets and GUIs have improved considerably, the emergent uses of IM haven’t yet been addressed and defined. The features end up crashing onto themselves in a confused jumble. There are many other such areas: Media Library management, Photo Management, etc. Apple, actually, is doing a good job of clarifying the actual uses of technology, and developing software to that end. This hasn’t happened yet on the PC side, though, so there may be some opportunity in that market.

  2. Brainstorm possible “use models” that apply to the emerging technology hybrids. Clarify the essence behind each movement, and identify what emotional/rational triggers are in play for users.

  3. Keeping the essence of the application in mind, develop a simple, orthogonal set of operators and concepts that will form the basis for the new software tool.

  4. Design something visually kick ass, with a full set of screen mockups suitable for making into a prototype.

  5. Publish, and move on. Optionally find a developer who can flesh out the product.

There are other methodologies that would cover how to deal with client relationships, how to put together a proposal, etc, but I’ll skip those for now. What I want to define first is some background methodology:

  • I want the team to remember how weird GUIs are for most people. A good GUI should be pretty up-front about what does what. The difficulty is that neophyte users have no idea what computers can do in the first place, so it’s something of a catch-22. Developing a GUI concept bible for the company would be necessary.

  • There are some ubiquitous GUI concepts that can nevertheless be refined. Assembling a practical library of these concepts would be useful, along with the supporting code for both Windows and Macintosh.

  • Aesthetically, there may be some rules of thumb that come to dominate the work. I’d want these preserved for future reference, with the rationale behind it.

  • The team should be familar with the breadth of visualization technique, from Tufte to XBox to The Lord of the Rings. The team should also be familiar with trends in ALL media: illustration, graphic design, motion graphics, animation, film, sound design, photography…

  • The team should be familiar with the history of interactive computing, computer languages and graphics libraries.

  • The team should be kickass in computer graphic designers and information architects, consumate craftspeople who push toward improving their skills. They should feel it, man!

<

p>I’m getting sleepy, so I’ll leave off here and pick it up later.

0 Comments