Google acquires Docverse

Blog, News on March 9th, 2010 Comments

Google Docverse

Working with Docverse has been one of the highlights of my career. When I reconnected with Shan and Alex after they moved from Seattle to San Francisco, and heard their pitch, I got totally hooked by their vision for the product; what excited me wasn’t just how great their technology was, but how focused they were on providing the most  intuitive and transparent user experience. When I asked them during the kick-off meeting about the limitation of current technology, they both answered - almost at once: “Don’t be limited by what we have. Let’s focus on designing the best user experience, and technology will follow.” And they delivered on every word in that promise. We always refined and picked the best designs to have, no matter how difficult they were to implement. This is the holy grail for any UX designer: to have a carte blanche for envisioning the best thing, knowing that there is a team of wizards who will make it happen.

 

What’s unique about Docverse’s user experience is that it never tried to change the way people did something. Instead, it tapped into people’s existing habits and workflows to provide them with easier, faster, and more secure way to share and collaborate on their documents. We carefully observed how people already used email attachments, how they changed and saved documents, and how they previewed and merged each other’s changes. And we brainstormed for days at a time about how to make every part of that workflow better, without forcing users to do anything different, and sometimes without asking them to do anything at all. The best user experience was to have no user experience: the more transparent the product became, the more users were focused on the main task: editing a document together. It was the document, not the product, that’s always been the center of the universe.

 

Docverse just works.

 

I am grateful for having the opportunity to work with this amazing team, and being part of that great journey that started less than 18 months ago with a spreadsheet of ideas, to sketches and designs hanging all over the green walls of their Howard street office, to a functional product, and finally, to a successful acquisition. It’s been a true rollercoaster ride through a unique and inspiring Silicon Valley success story.

I blame Docverse for raising my expectations for what I will be expecting from technology teams to make a user experience, no matter how challenging, come to life.

Just moved!

News on December 4th, 2009 Comments

I decided to move all design-related thoughts and stories to my blog.
Please direct your RSS subscription to http://feeds.feedburner.com/AmirKhella, where I will be sharing stories and thoughts about design, business and life.

Don’t violate fundamental design laws - even if you’re Apple

Design, News on November 3rd, 2009 Comments

When the iPhone O/S update brought a voice recording feature to the device, I was happily surprised because I love using recorders to take voice notes on the go then transcribe them later on.

When I started using the application, I liked the visual skin of the application but was frustrated by its usability: the application, as shown below, dedicated the largest screen real-estate to a giant microphone icon, and placed the functional buttons of the app in the two bottom corners, occupying less than 5% of the screen space.

voice-recorder_flat1

What’s wrong with this?

One of the fundamental laws of interaction design is called Fitts’ law, which states that the degree of difficulty to reach a target depends on the size of the target and the distance. This means that further and smaller targets are harder to reach than closer and larger ones. In the voice recorder example, the most frequent target is the record/pause/stop function, which should be the largest and closest one.

This becomes very important in contexts where it’s important to build good muscle memory for that frequent action so that one doesn’t need to look at the device to perform that function. With the voice recorder application, I typically need to look to locate the button, and look again after tapping it to see if I hit the right target and can start speaking. And that’s not safe.

What’s the fix?

Make the microphone clickable. When clicked once, it should record, clicked again it should pause/stop. When recording, the microphone should glow a saturated color that shows with a quick glance the state of the application.

I remember my first Human Computer Interaction quiz, we were asked to redesign the Windows start button to make it work best according to Fitts’ law. Given that there were no other requirements to the design, the winning solution was to make the button occupy 100% of the screen. This way, the degree of difficulty in reaching that button is zero.

Note that this is not the first time Apple violates this law. The tiny close/minimize/maximize icons on the top left corner of each application are good examples of tiny buttons that are responsible for frequent tasks, and that require precision to hit.

picture-311

Next time you’re designing a button, please make sure it Fitts.

If you love something, give it away

inspiration on October 31st, 2009 Comments

There is very little for me to say after watching this.

D3 - Designing with Clients

Design, News on October 10th, 2009 Comments

Few months ago, we started experimenting with a new Design workflow that we called D3. D3 stands for Deep Dive Design. Prior to D3, we used a communication-intensive process where we involve clients and users in the input and output of each design iteration: vision, usability metrics, stories, tasks, requirements, brainstorming, sketches, wireframes, and visual designs. The earlier and more frequently we communicated, the better quality designs we got, and the happier clients and users were.

We then thought about raising the communication bar further, and wondered what it would be like to have clients as active participant in the design process. So we decided to invite each client to spend a full week on-site with us. During that week, the client brings marketing, business and engineering team members to our offices and we spend 5-6 hours a day together, working on the following:

  • Day 1: Vision and success metrics
  • Day 2: Users and stories
  • Day 3: Tasks and flow
  • Day 4: Ideation and brainstorming
  • Day 5: Requirements and sketches

 

Here are some of the reasons why we believe D3 works great:

  • Spending a day hearing clients share their dreams, their vision and their motivation proved to be a great bonding exercise. Being on the same page is the most valuable starting point. We fully get the WHAT and the WHY behind the project, and we become part our client’s story.
  • Our design process becomes fully transparent to the client. They learn our language and they later use the same terminology to communicate feedback and requests.
  • The client returns with a very good idea about how the design vision aligns with the rest of the product, with insights into many of the design detail that will be delivered over the following weeks.
  • Marketing, business and engineering team members provide ideas and feedback on feature design. We found that everyone in the team can be a great design thinker, if they are placed in the right environment and provided with the right tools and vocabulary to express their ideas. They see how easy it is to capture ideas in crude sketch format, and how to express designs visually and effectively.
  • Team members go home with practical design thinking lessons that they continue using as they discuss the product among each other.
  • D3 is ideal for scrum and agile teams as they get to see the big picture while working on the detail. They don’t just remember features, but users and stories as well. Later on, they use personas names and stories to reference the features that they are working on. Many times we had engineers prototyping ideas that we didn’t think about, and showing them to us saying “We thought that Jessica would really enjoy having this feature when she’s picking up her neighbor’s daughter”.
  • The process reduces surprises to a minimum. There are always some new ideas that we will think of when we design the detail, and more requirements that the marketing or business teams will ask us to include, but they are never disruptive to the big picture.
  • At the end of the week, everyone is more excited about getting started with the prototyping process. We started the week on the same page: the problem, and we ended it also on the same page: the solution. We know we hit the jackpot when, at the end of the week, we look each other in the eye and exchange the silent agreement: We’re going to make this happen. Together.

Useful advice from Lao Tzu

Advice, News, startups on September 26th, 2009 Comments

Act without doing;

Think without effort.

Think of the small as large,

and the few as many.

Confront the difficult,

while it’s still easy.

Accomplish the great task,

by a series of small acts.

The Feature is Not The Experience

Blog, Design, News on September 17th, 2009 Comments

Design thinking for startups

Blog, Design, Learning, News, Tools on September 9th, 2009 Comments

During the 2008 web 2.0 expo in San Francisco, I held a round table discussion about design thinking for start-ups. The premise of the discussion was to 1) learn the difference between design (the artifact) and design thinking (the mindset), and 2) to discuss how to integrate best practices for design thinking into the product life-cycle. Start-ups running on shoestring budget cannot typically afford big consulting agencies like IDEO. But that shouldn’t stop them from becoming design-driven, and use the available tools and processes to differentiate through design and user experience. If you’d like to get your company up to speed with design thinking best practices and tools, get in touch with me for an on-site training session.

[Update] This presentation is currently featured on SlideShare’s homepage

[Update 2] I’ve received numerous emails and comments asking about the video for this presentation. I will be delivering a webinar next month that will use this presentation as a guideline to discuss the topics covered, answer the most common questions that I received so far, and dive into some case studies. If you’d like to be notified when the webinar is available, please sign up here.

Client testimonials’ word cloud

Design, News, Tools, review on September 9th, 2009 Comments

During the last startup weekend, a friend pointed me out to a fun tool for creating  typographic word clouds called wordle. Today, I decided to play more with it and I gave it the testimonials that clients left in my LinkedIn profile.

After some tweaking to the fonts and colors, here is what the output looks like:

word-cloud
Click on the image to see it in full resolution.

Delve Networks ranked among the top 50 Most Usable RIAs

Design, News on September 6th, 2009 Comments

Last year I worked with Delve Networks to design their user experience. This week, O’Reilly’s InsideRIA blog mentioned Delve as one of the most usable Rich Internet Applications.

Here is what Theresa Neil thought of the design:

Delve designers realized content creators weren’t interested in navigating through a bunch of screens to accomplish tasks. They have applied the one-screen-per goal philosophy which results in a lot less screens, each with deep interactions. To keep these rich screens from being completely overwhelming they have employed the following patterns: inline editing, dialog overlays, refining search, and progressive disclosure.

This is a very accurate description of our design goals. We were not interested in creating yet another digital asset manager. We studied the tasks that users wanted to perform at every step, and we took a task-centered approach in creating the interface and interaction. One of the unique interaction paradigms in Delve is that each screen contains a component that acts as a bridge to connect it to subsequent screens and tasks. Animated transitions are used to enforce that mental model for the user and keep them in context while taking them to the next part of the interface.

Here is a demo of Delve’s UI in action