Since August, I’ve been working on a project in an office on the 4th floor. I sit in front of a 30” LCD screen working on wireframes and product roadmaps for the majority of the day.
People walk by and comment on the screen “holy @#$%, that’s the biggest screen ever!” — “You are kinda like OZ controlling the world in front of that huge thing”. Right. The project I’m working on is the commercial spinoff of the MacArthur funded “Electronic Learning Record,” an extension of the Schools in the Digital Age project started in 2007. Through lots of research and time poured into thinking about the user experience, design of a brand, and cycling through learning metaphors, we’ve arrived at the design of a consumer internet site called Bettr@, or http://bettr.at (yes, we used the top level domain name hack for Austria like delicious did when they first started). The site is focused on helping anyone who is motivated to improve themselves get better at the things they are passionate about. This ranged from hobbies that people do in their spare time, to their career, and to classes that people take. More on the project later (or in the Bettr@ blog, to be launched soon). For now, I want to tell you about a simple technique I’ve been using to help develop the site that may help some of you get Bettr@InternetStartups like it helped me (although I might argue that it works for getting Bettr@DesignPlanning. When you’re developing a consumer internet site (especially one that you hope will become a destination site), you have to really be thoughtful about every single pixel that you have control over. Originally when we were doing these wireframes, we thought long and hard about all aspects of the experience— from all perspectives. We tried to translate research into criteria and combined with design principles to guide us into what we were building. Recently, being in implementation mode, I’ve learned that this level of fuzziness isn’t good enough. Our current process in defining a certain wireframe goes something like this: 1- Take two tabloid sheets of paper. At the top of one, put “What does the user want on the _____ page of the site?” At the top of the other, we write “What does Bettr@ (as a commercial entity) want on the _____ page of the site?” 2. We enumerate through a list of criteria that we think matters on each list. 3. Then we start designing the site with these criteria in mind. Each new feature, no matter how small, has to either be something which contributes to either creating user value or helping the business capture value. The list and the two sheets aren’t earth shattering— but the idea of assigning a designer to be the user advocate and assigning a product manager to be the business advocate is really effective. It formalizes the process of making tradeoffs. I suspect (and hope) that this process makes the site extremely easy and useful for users, while at the same time be able to harvest revenue (in our case from multiple streams). This idea of role playing has been effective in software development for a long time under the name “Extreme programming.” But why not try out “Extreme designing” when you’re trying to solve a problem for a company that you’re consulting with? It’s easier to role play and stay within the role of user advocate (designer) or business advocate (product manager) than keep switching off as you go along.