Design Discussions Matter!

Consider this scenario:
You have a box of Lego blocks, you have 10 people in a group. You are the moderator and you have an idea. You start by piecing something using just 5 blocks. You have to pass the block around to each individual in your group and you give them 1 instruction : "You can add 2 pieces to the assembly any more and you have to remove 1 for each additional piece. You cannot remove pieces such that the structural integrity of the assembly is comprised."

If you assess the iteration after every round you will begin to notice a pattern. At a particular point an idea is injected and as the evolution progresses the idea is transferred for person giving it to the person receiving it. At the end of a 10 person iteration you will notice a dramatic change to your initial assembly.

The key is perspective. If you super-impose this process on interface or software design you get concept of User Feedback. But most of us are used to testing what we conceived as an intuitive user interface and interaction work-flow against what a user feels about it. But what I'm trying to get to is far earlier than you've even shipped something off the drawing board. The decisions and trade-off made when you first start sketching .

That seems like a rather long preface to what I'm actually going to get into, but I felt it would be nice to add some flavor to a rather interesting design discussion at my work place.

3 Designers (User experience and Interface designers) and 1 Design pattern - Wizard flows.

What is the main objective of a Wizard Flow and what are some of the best implementations and some shortcomings in them. We got into a room, hooked the clunky Think Pad T500 to the projector, stacked up on some caffeine and started talking.

What we ended up doing is first a competitive analysis of different wizard implementations and then a rational implementation of a wizard flow for our application.

We analyzed EBay's search model, Amazon shopping model, Apple and Dell's Store purchase wizard, Geico's insurance quote system and Turbo Tax's tax filing work flow.

What did we deduce? Actually it was a series of questions.

• What are you selling?


• What are you promoting with a sale?


• How aggressively do you intend to promote the sale?


• What is your users objective?


• Do you know enough about your user to make that sale?


• How informed is the user at the end for the sale?

Lot of questions but who's going to answer them? That's precisely the challenge an experience design should address. I'm going to skip the gory details and get to the point, "What did I consider in implementing my design"

My first decision is that for a wizard flow to be successful I need to make sure that the user is actually interacting with a smart software.

I need contextual and suggestive help.

For that to be successful I need to make sure that I have enough information about the user I'm dealing with.

I need User Data Input.

I need to understand if I'm dealing with someone who is casually looking around or with some one who is serious about it. Users hate filling out forms or registering for the service just to find out what you have to offer. Based on that I need to decide when to prompt him to provide the data that I need.

I need to inject subtle data gathering at intermediate stages of the flow.

If its a large sale process that may involve 4 or more stages, I need to ensure that I retain the users attention and keep him motivated to complete the wizard.

I need to provide progress indication, state saves and casual contextual text to motivate the user to move ahead.

I had to create a sense of empowerment to the user. Allowing the user to make the decisions, be informed about how much its going to cost and at any-point feel free to leave.

I need a clear and visible affordance to provide information about items purchased, discounts applied and ensure that the progress is saved.Something like a mini-cart.

After all that I was motivated enough to actually hit the drawing board and create this Frankenstein work-flow that I think will best suit the bill.

I created a flow with 5 stages (in a crude nutshell)

• Stage 1 :- Allow user to select from a set defined list of package bundles. Then buy it or customize it.


• Stage 2 :- Get the basic data about the user is a short form that had the high-5 for my wizard to actually help customize the sale. Then buy or continue customizing.


• Stage 3 :- Inform the user that the system need just a little more information to help understand what to suggest. The user can fill out the information to see additional suggestions to understand the nature of the sale and then decide to buy.


• Stage 4 :- Entice the user to buy additional package that may add a discount at the same time suggest only what the user may need. User can skip or look for discounts.
  Stage 5 :- Get the rest of the payment information, ask if they would like to create an account and make the sale!
  
  If the user decided not to create an id and consider it as a one-off purchase, auto generate a temporary id that the user can use to if they return. The next sale will be so much easier!

Bottom line:Peers aren't around adding mass to office space. As a designer you need perspectives, some you may never even think of. It's easier to collaborate and reap the benefits than spend all those dollars on 4 rounds of iterative user testing, because you dint catch something earlier on.

PS : I had 2 rounds of user testing and the highest success rate of all the work models I've designed and tested! :)

iPhone Unified Alerts Project - 2

After spending some time I've finally managed to complete the proof of concept for the iOS Unified Alerts.

1. Unified alerts/messaging affordance on lock screen
2. System settings panel for configuring unified alerts/messaging
3. Unobtrusive Alert Prompts

You will find the URL to download the entire prototype at the end of the post. Give it a spin and let me know what you feel.




Screen Shots




Thanks for looking! Do leave comments!

DOWNLOAD PROTOTYPE

iPhone Wireframing Template

I read a blog post by a designer named Morten and loved his experiment to create a stencil to design using Google Drawings! I was inspired to create one for the iPhone. It's an ongoing process and I'm going to update the template as I make progress on another project that I'm working on.

I traditionally use Adobe Fireworks to create wireframes, I hate Visio and not too much experience with Omnigraffle, but this is a very nice alternative.

Some observations after using it:

• Copy and paste is still flaky and am hoping Google will address some of that soon.
• It could also use gradient support but in all its got some robust controls to create wireframes.
• I hope Google includes locking, sometime its painful when selecting objects!
  

The template is sectioned into 3 major sections

1. Parts and Controls
2. The Drawing Board
3. Interaction Indicators

Hope you like the template! If you've got some suggestions, do post! It's a ThinkTank project and I'd like to collaborate!

Original post : A Wireframe kit for Google Drawings

My template : Source

iPhone Unified Alerts Project - 1

Objective

To create a simple consolidated view for alerts and messaging on the iPhone lock screen

Description

The iPhone is a revolutionary device. It has a splendid user interface and user experience model. It is the probably the smartest phone with the best app store and user base. Over the last 3 year Apple has created and innovated the iOS platform into a solid, productive environment for designers and developers alike.

But in my opinion I did notice that the system has a limitation in terms of messaging and alerts. Today they work by means of badge alerts and dismissible alert prompts. Remember the times when you phone is sitting on your desk and you went into a meeting and got back just to see if someone called or if you’ve received any alerts or mails and you hit the lock button?

Today if you’ve received a series of calls or voice mails, you get a list on your lock screen.

If you’ve received a series of calendar alerts, they show up in chronological order, one at a time.

If you’ve received any emails, badge alerts, etc; You will have to unlock to view.

What I’m trying to address is a common consolidated messaging system that shows up on the lock screen, that shows you a list of recent events that have occurred when you were away from your phone.

Main features

1 - Unified alerts/messaging affordance on lock screen

2 - System settings panel for configuring unified alerts/messaging

Disclaimer : I am doing this purely for my own pleasure! I do not work for Apple Inc. I do not work for any employee of Apple Inc. If Apple is developing something similar to this under wraps, at-least I share the same thought process with Apple designers! :) I’m a big time apple Fanboy! :)

Over the next few days I'm going to be working on conceptualizing and designing the interaction and work-flow model required to illustrate an Unified Alert System for the Apple iOS platform.

Version 1

I've created some high level flow charts that I will use to wireframe my design. There are 3 major scenarios that I will consider for my design.

• The iPhone in locked state
• When in an application
• When a call is in progress

Scenario 1
This is my primary use case and the driving point for my project.
Scenario 2
When you are using an application and you get an alert.
Scenario 3
When a call is in progress and you receive an alert.

So now that I have the main scenarios sketched out, I'm going to start creating wire-frames. Check back soon!

What is my design philosophy?

Its been about 7+ years in the Internet and Media industry. I've worked on so many different kinds of projects. Small websites to full featured applications. Yet I keep getting a question from peers "What is your design philosophy?".

Lets get some background information so you can relate to my career profile. I'm not educated in design, I've not been taught how to design, I've not been accredited by any institution in design! Yet I find my self doing what I do for the last 7 years. My passion in arts as a kid resonated into my decision to become a Graphic artist/Visual designer. That how I started my career!

Today I work as a User Experience Designer, blending the science of interactive media and user psychology with my skills in creative design. But that is vague right! I create usable interfaces and products that users will eventually use.

Now moving on to the philosophy. Well if your in this industry you've probably heard some of these words throw/phrases at you.

• Simple and intuitive design
• User hand holding
• Optimum real estate usage
• Inconsistent behavior
• Usability results
• Visual clutter
• Hidden or skewed information

The list goes on! Some you probably never heard because your calling it something else! But in essence what your shooting for is a set of guidelines or principles that you can use as the foundation for your design process.

I normally don't tag my design decision with a principle. For example, I try to make sure that in an application the entry path and exit path for a user's operation to search is consistent, creating a consistent experience. I don't call that out but I apply that process of thought when designing.

But the real question is how do you explain that you used that thought process when you started sketching designs? Some designs just work and you know applying that will solve the problem. Shouldn't your designs speak for them selves? Today there are so many successful interaction models for search that if you stray away too far, you can potentially create an painful experience.

Sometimes you work more out of instinct than from a hand book. Ideas and inspirations can resonate from a variety of places. But a big challenge is to paint a pretty picture of your design ideology.

A conventional design process has these basic stages:

• Ideation
• Design
  
• Iteration
• Construction

Every designer is going to see these stages but yet your expected to illustrate something more. It isn't sufficient to present the end result for each of these stages.

I think its more about the process involved between these stages than the stage itself. People want to know what did it take for you to move from Ideation to Design.
What was your interpretation of the requirement?
What did you feel was needed to draw that first line on the drawing board?
What changed from sketch 1 to sketch 2 to sketch 3?

That my friends gives a quantifiable reference to design principles! Unfortunately I've not been in the habit of documenting this process. But I think I'm going to.

Bottom line : I'm not deprived of design philosophy by any means, I just haven't been explaining it correctly!

Its all in the data : How user interface design is driven by information.

As designers it's only natural to re-visit or re-use some design implementations that have worked best for us. At some point in our design careers we have a little cheat-sheet in our pockets that we use to allow for quick solutions. This creates individuality and gives character to our designs. There also comes a point where we append our cheat sheet with principles and methodology that have proven successful by other designers or solutions.

But are you considering the fact that seldom do 2 solutions function identically? If you take a close look at your project history, you may have worked on similar products or you may have worked in sibling products and the oddball case when your asked to re-create based on an existing product. Now whatever may be the case, the end solution will always be different.

The key underlying fact is the data offering. Based to the type and degree of data your, your designs will change. That's a fact. Lets put an example to this.

We are/have designed for 3 products, all solutions in the realm of data reporting. To take a more generic case, data is based on financial information.

1. Product A : Low degree of data, has most of the public information and a little historical data.
2. Product B : Low degree of data, has most of the public information and a little historical data but a more reputable brand name.
3. Product C : Medium degree of data but has a huge database of proprietary information that is not available anywhere.

The Objective
All of the products sell a report that a subscriber will pay to obtain. The cost most certainly will vary, simply because of the quality of data.

Lets look at a hypothetical design for the three reports


Report A : Since most of the information is publicly available, its more about data consolidation and presentation that will be the key selling point for this report. The objective would be to provide the user with a one stop shop instead of doing the whole search and information gathering himself.

Some of the key design considerations

• Present a simple report with formatted data
• Use graphical representation for the information.
  
• Highlight the span or spectrum of sources that has been used to obtain the data.

Report B : Now this company provided the same data but it all tagged with a popular brand name that you can trust. Right from the get-go your under the assumption that people will trust your data and information and the view that you provided which is an advantage.

Some of the key design considerations

• Present a branded report with formatted data
• Provide a different perspective at looking at the information : Graphs, charts, maps, etc.
• Since the report if coming from a brand name that people trust, information source wouldn't be a big factor. Its a design decision.
  

Now you can see that although the both reports proved similar financial information, you will have the 2 reports laid out differently.


Report C : The main selling point its the core data that is proprietary to this company. This information is not available anywhere and emphasizing that information will drive the design.

Some of the key design considerations

• The core data need to be highlighted in the report layout.
  
• Probably section the report as proprietary and public views?
• Use of graphics for the core data may be more useful than for the public data, but that's purely a design call!
• The public data can be formatted or presented as is, another design call you would make.

Conclusion:
Ok I'm sure at this point you've got a lot of question on some the pointers above, its only an example and a hypothetical design. The point I'm trying to make is how the data will affect your design process and some of the design decisions you will make. To some of us it may be a given during our design stage, some may not realize it but for some who don't it good to understand the data your working with and then work at designing a solution tailored to that data.

A good example would be to quick case study on a product search results page. Different solutions have different meta data information they provide or let you search on and you will notice how the results vary.

Who are you Designing for? - Why designers should ask that question.

Over the years the importance of design principles and philosophy has spread through the very fabric of the software business. More companies are now looking into means of strengthening their offerings with greater usability and intuitive solutions.

So what is a good design? What really works for your consumers? The simple answer is, ask your consumers! Most products are tailored around a specific segment or type of customers. Understanding who they are and what they do would be the first step.

As designers, it's only instinctive to start sketching out designs and prototypes under the assumption that we know what may,will or might work for the product. But that is where the problem starts, the first line we draw is an assumption.

Lets put an example in to set some context. Lets take a very simple and widely used feature: SEARCH. Let's add a little more detail, Search for a e-commerce site. The first thing your going to do is slap in a text box and a button and name it "search".

No harm in that right, but in my perspective,do you really know

1. What you want your users to search?
2. Should they be searching in the first place?
3. How big in reality is your offering?

If your offering is small(say 3 product categories and 100 items in total), a proper information architecture model can resolve the need for search. You have 3 sections, each listing the products available and the user can view and select.

If your offering is larger than that, are you asking the user "Do you know what your looking for?".

This is because you have 2 major classifications of user roles:

• The casual catalog shopper: One who isn't looking for anything in particular and wouldn't mind clicking through to see what you have to offer.
• The serious shopper: One who know exactly what they want and are either looking for a bargain or availability.

If you think about it, as humans that is what we do when we go to the mall or a store.Based on which you can decide how much you need to stress on search. Again don't get me wrong here, I'm not debating if search is really required or not in an offering, I'm stressing on the importance of understanding who your users are.

Now in my opinion this is how I would start with my design process.

Raw materials for an Idea

1. I start by understanding the scope of the offering
2. I try to get a sense of the size of the offering
3. I will start writing up User Persona - one or 2 for each major classification I can think of.
4. I try to give these persona character I can relate to.

Starting with the Idea

1. Now that you know who is going to be using the offering, I then call some assumptions on what are they each going to be doing with the solution. (A good approach would be using post-its on a wall with operations or routes)
2. Soon I have a yellow plastered wall, I start to analyze the information to create use-cases.
3. Now match the use-cases to the different persona and now you have the basis for your offering.

Designing

1. I've started this in different ways. Creating a one size fits all and creating one for each persona and blending them together. Either which way you decide to take it, create more than one end-design variant.
2. SHARE! SHARE! SHARE! Present your designs to a variety of people, go to the extent of maybe asking your Gardner to have a look at your design, you may never know what you may uncover.
3. Soon after a few rounds of iteration you will begin to see how the design has evolved into a workable and usable product(at-least on paper).

User Testing
Now we are back to square one to be honest because what you have designed is a rendition of an idea with a good mix of assumptions and some degree of feedback.

1. I normally built out a prototype for my user testing and I write my test script scenarios based on the persona scoped for the product.
2. Then you find a group of people to test your solution. If i have a prototype, I sometimes include a little quiz that will help identify the best match between your test user and the persona before they get started on the test procedure. This way I know that there is some degree of relevance between my test user and my test scenarios.
3. I like to keep grading very strict to 3 levels : Pass(user understood the objective),Fail(user did not understand the objective) and Help(user was provided with some assistance). How I grade is as follows


• +1 for pass
• -1 for fail
• +1.5 for Help and pass
• -1.5 for help and fail.



4. Do the math and then you will have a good gauge of your designs success or failure.

Over the years I've practiced this for most projects that I work on and you will then begin to understand that there is a clear and definitive trend between the Business offering, the user base and designs that work for them. Soon you'll build up a formidable arsenal of design principles that have worked and you'll be able to quicken the time it takes for the pre-design process.

Please feel free to leave you comments and thanks for reading.