Archive for January, 2012

When an idea is 10+ years ahead of its time

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
CES is happening this week. Since I’m a tech geek, I’ve been avidly following news and blog posts about all the gadgets and technology trends that are being announced.

So far the thing that interests me the most is the connected cars phenomenon. Mercedes-Benz, Audi and Ford each have their own proprietary platform that connects to the internet and allows you to get information from the internet and/or use your mobile phone to check the status of your car. This seems to be an idea whose time has finally come. Here is a video showing the Mercedes-Benz system. (As a former Audi owner I would have loved to show the Audi system instead… but this video is more digestible.)

This is especially interesting to me because some 15 years ago, while I was with a product design consultancy, I was part of a team that worked on an “infotainment car” concept with a cutting edge automobile company that shall remain nameless. We did an ethnography study where we shadowed research subjects for an 8-hour day as they drove around, going about their normal business with us and our videotaping equipment in tow.

We crunched the data, and came up with what we thought people would want to do in the car: get location based information such as nearby restaurants, get turn-by-turn navigation help, get entertainment such as music and video in the car, and get help and support if they get into trouble. We understood that the user’s eyes have to be on the windshield and we thought of wacky ideas like a heads-up display (HUD) superimposed on the windshield, so that critical information may be presented to the driver without requiring them to take their eyes off the road. We called this the “infotainment car” concept.

Considering this was mid 1997, US cellular networks were in the dark ages (GSM/GPRS was not even approved as a standard), and the most advanced connected car technology on the market at the time was General Motors’ OnStar system (equipped with a GPS, an analog cellular uplink and people answering calls), the infotainment car concept was truly a glimpse into the future.

We eventually visited the automotive company’s advanced research lab and saw such a concept car with all the requisite technology. This concept car would have worked from a technology standpoint. Its only problem was that the technology was very expensive and far from mature, and the content and infrastructure was sparse, and in some cases, non-existent. The ideas were wonderful and in hindsight, more than prescient, but the content and technology limitations made it impossible to realize the full richness of the user experience. The concept car stayed in the lab for another 10+ years.

Fast forward to today, and look how far the technology has come. The cellular uplink is now smoking fast – witness the 4G LTE radio integrated into the Audi. This makes it possible to have a really great data download and media streaming experience. Location based information is accurate and plentiful. Many people (myself included) keep large amounts of personal data in the cloud, making it ever more possible to have an excellently consistent connected experience anytime, anywhere. Advanced display technologies are starting to become a reality. Audi is even talking about a heads-up display.

Here is proof that an idea alone isn’t enough to make a successful product or business. Execution alone isn’t, either (the automotive company knew how to make such a car, albeit at a crazy price point). The right external conditions are the third requirement.

I have another case study that supports this observation. Another company I worked with that shall also remain nameless had thought of the exact same core idea as the MakerBot Replicator. Here is a video from the company explaining this incredible 3D desktop printer.

That idea came up well over 10 years ago and remained unactionable until recently, when relatively more cost effective 3D printing technology, better options for the substrate, as well as 3D digital content creation technology caught up with each other.

As a product person, one must stay on top of technology trends and be alert and aware when the conditions arrive that makes a brilliant but previously impractical idea come into its own. Being in the right place and in the right time is a pre-requisite to success.

Want a great interactive meeting? Ban PowerPoint

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
A few months ago I read a Harvard Business Review article by Peter Bregman on how Powerpoint is the #1 killer of meetings.

At the time, I thought, this is all very interesting, but how would anyone be able to keep 30-40 minutes worth of content in his/her head without a slide deck as a framework? I filed the idea away in the back of my head and continued using PowerPoints in my all-hands team meetings.

Some time mid-year, my team and I realized that our team meetings were falling flat. So flat, indeed, that not only were people bored and disengaged, people in the front row were falling asleep on me. The Q&A part at the end was extra awkward, since no one ever had any questions and everybody was always in a hurry to get it over with so they could get out of there.

It certainly didn’t help that we were holding our meetings in a funky space. We are a startup in a relatively small space, and the largest conference room doesn’t comfortably hold the entire team. So we used to hold our meetings in an open area with very high ceilings. The acoustics was appalling – no one could hear anyone else. Once, in desperation, we tried using a microphone. All we achieved was make the whole experience even more surreal. (A microphone in a team meeting at a startup? Seriously?)

Since what we’ve been doing left much to be desired, we decided to try something new as an experiment:

  • We moved the meeting to the largest conference room. We pushed the tables out of the way and liberated chairs from another conference room to create extra seating. Then we packed everybody in. It was tight but we were able to fit everybody.
  • We banned PowerPoint presentations. Our functional leaders took turns providing a verbal update, with physical props where appropriate.

We had our first team meeting of the year with these changes. What a difference these changes made! Despite the overcrowding, the team was relaxed and engaged. Everybody paid attention to the status updates. There was a lively discussion at the end about a variety of topics of interest. This was the most interactive all-hands team meeting I’ve been in for a long time. I was blown away with the before-and-after comparison.

It’s amazing how these very simple changes completely changed the dynamics of the meeting and the level of engagement of the participants. Being in an actual conference room somehow helped people feel that they were IN the meeting instead of hovering around the perimeter of the meeting. Just that fact seemed to have drawn people into the content of the meeting instead of sending them off for a nap. Being able to hear people speak definitely helped – and this was particularly apparent during the Q&A when many team members spoke up. And most important of all, not having PowerPoint slides forced people to work on clarifying their message so it is concise and easy to digest and remember – something we often forget to do when we have a slide deck to fall back on. We are most definitely keeping these changes for our next all hands team meeting.

Product Planning Series: Information Architecture, Flowcharts and Wireframes

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the seventh post of my Product Planning Series.

I’ve worked with development teams who were “too busy to generate design documentation”. They say: planning is guessing. They say: a design is useless unless it can be represented in code, therefore you ought to start in code. Many of them then start writing the GUI code one component at a time without having developed an information architecture that provides context to each component.

I say to these friends of mine: action without planning in this case is not so smart if you care about the quality of the outcome. A great user experience comes from a holistic view of the application and an information architecture that accommodates not only the UI needs of components of the application, but the cohesiveness of the user experience as a whole. This is up front work that takes time and effort, but it is absolutely worth it. It saves you from having to do gut rehabs to your GUI to accommodate new features and use cases you haven’t properly anticipated before.

One way to capture the output of this design process is with flow charts and wireframes. A high level flow chart for a web app (or any software application for that matter) explains the functionality of the application and how you get to each part of the application at a glance.

I’m going to use the web site of the Trust Center for MIT Entrepreneurship as an example. Since websites change all the time, here is a screenshot of the home page of this site as of January 2012, featuring my good friend Bill Aulet (the current Managing Director of the Trust Center).
Example Web Site

Somewhere during the design process of this site, a project manager had decided on the content that would be presented to the users. An information architect would have worked closely with the project manager to develop a top level site map, easily depicted in the form of a flow chart. This flow chart shows how major content is organized in different pages, and how a user might get from either the home page or a landing page to their content of choice.

Once this high level view exists, the designer would have come up with a wireframe of each key page in the app. Now what is a wireframe in this context? The Wiki has an excellent explanation:

A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together. The wireframe usually lacks typographic style, color, or graphics, since the main focus lies in functionality, behavior, and priority of content. In other words, it focuses on “what a screen does, not what it looks like.” Wireframes can be pencil drawings or sketches on a whiteboard, or produced by means of a broad array of free or commercial software applications.

Thus, we are NOT talking about wireframes in CAD-speak. We are talking about a fairly specific form of design output.

Continuing the example above, the home page wireframe for the Trust Center website would likely have looked something like this.
Example Wireframe

As you can see, a wireframe is not a graphical design. It is instead a concept for a page layout that contemplates the information to be presented to the user (e.g. title, subtitle) and the actions the user need to be able to take (e.g. subscribe via RSS or email) and arranges things in such a way that a user can accomplish most of the mainstream workflows they came to your site to achieve (e.g. read the latest post).

The wireframe is intentionally very stylized in presentation in order not to confuse the reader with any graphical treatments that may cause him or her to latch on to something irrelevant (e.g. the quality or choice of the banner image), instead of focusing on what is the most important at this stage of development (e.g. the user workflow and use case scenarios). It communicates key technical requirements to both the project manager and the developer and helps them negotiate and plan the development work that implements this design.

Now if someone was to plan out a website in its entirety and inventory all of the screens, they would come up with way too many screens to design in this manner. So how many wireframes are really needed? I believe one should at least make as many wireframes as there are unique templates.

A template is a webpage layout that specifies what content goes where. There can be many pages with different content that uses the same template. Going back to the Trust Center website, you can see that several subpages all have the same layout, but different content within each block of information. For instance, if you were to browse the Trust Center site, you will quickly discover that with the exception of the home page, all the pages accessed with the top navigation bar (e.g. Activities > Curriculum, or News) share the same 2-column template.

Example Template

Since they are all the same, they can be depicted using the same wireframe.

Hopefully this post has helped demystify the front end of web development. The organization of information into different pages is an information architecture exercise; the wireframe design for each unique template starts to pull in interactive design. Once that’s done, graphical design comes next – that will be the topic of another post.



%d bloggers like this: