I have been spending the last few days working on the design for a new social application (still hush-hush project), where I am working with some outside designers.
I recently presented a workshop in Berlin called Building Social Applications, and one section dealt with an approach that I use for designing social applications. The full presentation can be found at slideshare, here. (Wow: just looked at Slideshare to get the link, and the presentation has been viewed 1095 times in the week since I uploaded.)
An Approach To Design
I have a bunch of fairly invariant design principles, that generally hold. For example, simplicity: given two alternatives, the one with fewer 'moving parts' -- ideas, design elements, or whatever -- is likely better. I often don't write these down, but when I am working with large groups of people in the early stages of design, I make them explicit so that we can have a shared language for talking about design and the design process. When I am working with small teams made up of very savvy design folks, that is less necessary. (I wrote recently that small design teams are best: Getting To Design.)
Being a lazy sort of person, I try to use the same techniques over and over in all my projects. I have a fairly consistent approach to design applications, summarized in these slides.
After nattering around for a bit, thinking about the high level notions of the application (like "a social commerce application for fashionistas" or "a social network search application"), I start by trying to capture various key concepts that the inventors (or me) have in our heads, prior to any systematic approach to product concept development. (In the slide, I am displaying the concept of streams and traffic -- as in Twitter or other stream-based applications -- which I am using in several applications right now.)
Some people want to pretend that they start with a totally clean slate at the start of every design, and that the final concepts that emerge from the design process are purely the outcome of user requirements analysis. Bull. I don't try to fool myself or my clients about that. I generally have two or three big chewy ideas prior to doing anything systematic, or my clients do. So I try to capture that.
The next step for me, generally, is to identify a small number of archtypal users: personas. The examples above are from the Social:Learn project with the Open University. The idea is to blanket the social space involved in the use of the application: to identify all the touchpoints where people interact.
The problem is that you don't know if you have enough people, or the right people for the personas until you cycle a bit. You define the personas a bit, and then quickly iterate into small stories about the people interacting, which I call vignettes. Vignettes are ultimately elaborated into scenarios, which are more elaborate versions of the vignettes with specific references to design elements. The first time through the stories, you have no (or very little) design to refer to.
The the magic begins. You need to start to think about the vignettes and concepts, and start devising elements of the design. My best design innovation comes with small teams of other designers, whiteboarding and brainstorming. The slide above shows a horrible sketch I did at a working session a few months ago, and a rendered Omnigraffle wireframe I later made for it.
The process leads you back to the vignettes, recasting them with actual references to the wireframes. After more iterations, the persons become more elaborate, and the vignettes slowly become full scenarios, where every social touchpoint supported by the tool is detailed in terms of design elements in the wireframes and described in the scenarios. The scenarios and wireframes together can be considered, collectively, as the user narrative for the application's conceptual design. It's conceptual since we are not actually designing the software, we are just characterizing the operational contours for the application. (Note the example above is hard to see at the resolution of the image. If you click through, it will take you to the Flickr photo, and you can see it at higher resolution. It's an example from an AOL project I started earlier this year, which was shelved, showing a wireframe and a concise user narrative.)
The final attribution of fine-grained design elements -- like the Ajax edit delete controller highlighted in the graphic above -- completes the development of a full definition of the user experience. This include color schemes, icon design, moving elements around on the pages, etc. While the early wireframes are meant to be functionally useful, the final design are meant to be as close to an implementation as possible or practical.
This is one of the many reasons I want to have other, more user experience oriented designers on my teams, because I am not really gifted in this aspect of design.
Last Thoughts
So, I am slowly elaborating the various parts of the Building Social Applications workshop. I hope this has been helpful. I decided to take the time to write this down today because the same ideas were rattling around in a project I am working on right now, in a meeting this morning. So, I am killing several birds with one stone, here. Again, proof of my consummate laziness!
Sometime next week, I will roll out the Dopplr case study from the workshop presentation in a similar fashion to this post.
Recent Comments