ku酷游体育平台地址

<acronym id="80kyi"></acronym>
<acronym id="80kyi"><optgroup id="80kyi"></optgroup></acronym>
<acronym id="80kyi"><center id="80kyi"></center></acronym>
<rt id="80kyi"></rt>
<acronym id="80kyi"><optgroup id="80kyi"></optgroup></acronym>
<rt id="80kyi"></rt>
<rt id="80kyi"><optgroup id="80kyi"></optgroup></rt>
<acronym id="80kyi"><small id="80kyi"></small></acronym>
<acronym id="80kyi"><center id="80kyi"></center></acronym><acronym id="80kyi"><small id="80kyi"></small></acronym>
<acronym id="80kyi"><small id="80kyi"></small></acronym>
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Wednesday, April 30, 2014

Product Vision: Make A Trailer And Not A Movie


I have worked with many product managers on a product vision exercise. In my observation the place where the product managers get hung up the most is when they confuse product vision for product definition. To use an analogy, product vision is a trailer and product definition is a movie. When you're watching a movie trailer it excites you even though you fully don't know how good or bad the movie will be.

Abstract and unfinished

A trailer is a sequence of shots that are abstract enough not to reveal too much details about the movie but clear enough to give you the dots that your imagination could start connecting. Some of the best visions are also abstract and unfinished that leave plenty of opportunities for imagination. Product visions should focus on "why" and "what" and not on "how" and most importantly should have a narrative to excite people to buy into it and refine it later on. Vision should inspire the definition of a product and not define it.

I am a big believer of raw or low fidelity prototypes because they allow me to get the best possible feedback from an end user. People don't respond well to a finished or a shiny  prototype. I don't want people to tell me, "can you change the color of that button?" I would rather prefer they say, "your scenario seems out of whack but let me tell you this is what would make sense."

Non-linear narratives

Movie trailers are also the best examples of non-linear thinking. They don't follow the same sequence as a movie - they don't have to. Most people, product managers or otherwise, find non-linear thinking a little difficult to practice and comprehend. Good visions are non-linear because they focus on complete narrative organized as non-linear scenarios or journeys to evoke emotion and not to convey how the product will actually work. Clever commercials, such as iPad commercials by Apple, follow the same design principles. They don't describe what an iPad can do feature by feature but instead will show a narrative that help people imagine what it would feel like to use an iPad.

Means to an end

The least understood benefit of a product vision is the ability of using the vision as a tool to drive, define, and refine product requirements. Vision is a living artifact that you can pull out anytime during your product lifecycle and use it to ask questions, gather feedback, and more importantly help people imagine. I encourage product managers not to chase the perfection when it comes to vision and focus on the abstract and non-linear journey because a vision is a means to an end and not an end itself.

Photo courtesy: Flickr 

Friday, February 28, 2014

Recruiting End Users For Enterprise Software Applications

As I work with a few enterprise software start-ups I often get asked about how to find early customers to validate and refine early design prototypes. The answer is surprisingly not that complicated. The following is my response to a recent question on Quora,

Finding a customer and finding end users are quite different. In enterprise software end users are not the buyers and the buyer (customer) may or may not use your software at all. To recruit end users, there are three options:

Friends and families: Use your personal connections through email and social media channels and ask for their time (no more than 30 minutes) to conduct contextual inquiries and get validation on your prototypes. Most people won't say no. Do thank them by giving them a small gift or a gift card.

Find paid end users: This does seem odd but it works. I know of a few start-ups that have used this method effectively. Use Craigslist and other means to recruit people that match your end user role and pay them to participate in feedback sessions. It is worth it.

Guerrilla style: Go to a convention or a conference where you could find enough end users that fit your profile. Camp out at the convention with swag and run guerrilla style recruiting to validate and prototype. Iterate quickly, preferably in front of them, and validate again.

Friday, January 31, 2014

A Design Lesson: Customers Don't Remember Everything They Experience

My brother is an ophthalmologist in a small town in India. In his private practice, patients have two options to see him: either take an appointment or walk in. Most patients don't take an appointment due to a variety of cultural and logistics reasons and prefer to walk in. These patients invariably have to wait anywhere from 15 minutes to an hour and half on a busy day. I always found these patients to be anxious and unhappy that they had to wait, even if they voluntarily chose to do so. When I asked my brother about a possible negative impact due to unhappiness of his patients (customers) he told me what matters is not whether they are unhappy while they wait but whether they are happy or not when they leave. Once these patients get their turns to see my brother for a consultation, which lasts for a very short period of time compared to how much they waited, my brother will have his full attention to them and he will make sure they are happy when they leave. This erases the unpleasant experience from their minds that they just had it a few minutes back.

I was always amused at this fact until I got introduced to the concept of experience side versus memory side by my favorite psychologist Daniel Kahneman, explained in his book Thinking, Fast and Slow and in his TED talk (do watch the TED talk, you won't regret it). While the patients waited the unpleasant experience was the experience side which they didn't remember and the quality time they spent in the doctor's office was the memory side that they did remember.


Airlines, hotels, and other companies in service sectors routinely have to deal with frustrated customers. When customers get upset they won't remember series of past good experiences they had but they would only remember how badly it ended - a cancelled flight, smelly hotel room or production outage resulting in an escalation. Windows users always remember the blue screen of death but when asked they may not necessarily remember anything that went well on a Windows machine prior to a sudden crash resulting into the blue screen of death. The end matters the most and an abrupt and unrecoverable crash is not a good end. If the actual experience matters people will perhaps never go back to a car dealership. However people do remember getting a great deal in the end and forget the misery that the sales rep put them through by all the haggling.

Proactive responses are far better in crisis management than reactive ones but reactive responses do not necessarily have to result in a bad experience. If companies do treat customers well after a bad experience by being truly apologetic, responsive, and offering them rewards such as free upgrades, miles, partial refund, discounts etc. people do tend to forget bad experiences. This is such a simple yet profound concept but companies tend not to invest into providing superior customer support. Unfortunately most companies see customer support as cost instead of an investment.

This is an important lesson in software design for designers and product managers. Design your software for graceful failures and help people when they get stuck. They won't tell you how great your tool is but they will remember how it failed and stopped them from completing a task. Keep the actual user experience minimal, almost invisible. People don't remember or necessary care about the actual experiences as long as they have aggregate positive experience without hiccups to get their work done. As I say, the best interface is no interface at all. Design a series of continuous feedback loops at the end of such minimal experiences—such as the green counter in TurboTax to indicate tax refund amount—to reaffirm positive aspects of user interactions; they are on the memory side and people will remember them.

In enterprise software, some of the best customers could be the ones who had the worst escalations but the vendors ended their experience on a positive note. These customers do forgive vendors. As a vendor, a failed project receives a lot worse publicity than a worst escalation that could have actually cost a customer a lot more than a failed project but it eventually got fixed on a positive note. This is not a get-out-of-jail-free-card to ignore your customers but do pause and think about what customers experience now and what they will remember in future.

Photo courtesy: Derek 

Thursday, January 31, 2013

Empathize Not Sympathize

Many enterprise software vendors sympathize. "We know it's a bad experience" or "We will fix the usability." One of the reasons the software is not usable is because the makers never had any empathy for the end users who would use it. In many cases the makers didn't even know who their end users were; they only knew who would buy the software. As far as enterprise software is concerned people who write checks don't use the software and people who use software don't write checks and have a little or no influence in what gets bought. Though the dynamics are now changing.

Usability is the last step; it's about making software usable for the tasks that it is designed for. It's not useful at all when the software is designed to solve a wrong problem. Perfectly usable software could be completely useless.


It's the job of a product manager, designer, and a developer to assess the end user needs—have empathy for them—and then design software that meets or exceeds their needs in a way that is usable. That way they don't have to sympathize later on.

Design Thinking encourages people to stay in the problem space for a longer duration without jumping to a solution. What problem is being solved—needs—is far more important than how it is solved—usability. Next time you hear someone say software is not usable, ask whether it's the what or how. The how part is relatively easy to fix, what part is not. For fixing the "what" you need to have empathy for your end users and not sympathy.

Tuesday, December 18, 2012

Objectively Inconsistent




During his recent visit to the office of 37 Signals, Jeff Bezos said, "to be consistently objective, one has to be objectively inconsistent." I find this perspective very refreshing that is applicable to all things and all disciplines in life beyond just product design. As a product designer you need to have a series of point of views (POV) that would be inconsistent when seen together but each POV at any given time will be consistently objective. This is what design thinking, especially prototyping is all about. It shifts a subjective conversation between people to an objective conversation about a design artifact.

As I have blogged before I see data scientists as design thinkers. Most data scientists that I know of have knowledge-curse. I would like them to be  consistently objective by going through the journey of analyzing data without any pre-conceived bias. The knowledge-curse makes people commit more mistakes. It also makes them defend their POV instead of looking for new information and have courage to challenge and change it. I am a big fan of work of Daniel Kahneman. I would argue that prototyping helps deal with what Kahneman describers as "cognitive sophistication."
The problem with this introspective approach is that the driving forces behind biases—the root causes of our irrationality—are largely unconscious, which means they remain invisible to self-analysis and impermeable to intelligence.
This very cognitive sophistication works against people who cannot self-analyze themselves and be critical to their own POV. Prototyping brings in objectivity and external validation to eliminate this unconscious-driven irrationality. It's fascinating what happens when you put prototypes in the hands of users. They interact with it in unanticipated ways. These discoveries are not feasible if you hold on to single POV and defend it.

Let it go. Let the prototype speak your design—your product POV—and not your unconscious.

Photo courtesy: New Yorker

Friday, November 30, 2012

Enterprise Software Needs Flow And Not Gamification



I don't believe in gamifying enterprise applications. As I have argued before, the primary drivers behind revenue and valuation of consumer software companies are number of users, traffic (unique views), and engagement (average time spent + conversion). This is why gamification is critical to consumer applications since it is an effort to increase the adoption of an application amongst the users and maintain the stickiness so that the users keep coming back and enjoy using the application. This isn't true for enterprise applications at all. This is not only not true for enterprise applications, but gamifying enterprise applications is couterproductive that makes existing task more complex and creates an artificial carrot that does not quite work.

A design philosophy that we really need for enterprise applications is flow. I am a big fan of Mihaly Csikszentmihalyi and his book "Flow: The Psychology of Optimal Experience." I would highly recommend you to read it. Mihaly describes flow as a series of autotelic experiences as an activity that consumes us and becomes intrinsically rewarding. The core intent of gamification is to make the applications a pleasure to use. What people really want is enjoyment and not just pleasure. They are different. Enjoyment is about moving forward and accomplishing something. Enjoyment happens due to unusual investment of attention. It comes from tasks that you have a chance to complete, has clear goals, provides feedback, and makes you lose your self-consciousness.

All the gamification efforts by new innovative entrants that I see seem to be disproportionately focused on "edge" applications since it's relatively easy for an entrant to break into edge applications to beat an incumbent as opposed to redesigning a core application. But most users I know spend their lives using the core systems. They have no intrinsic or extrinsic motivation to use these systems. Integrate flow in these systems to create intrinsic rewards that creates autotelic experiences. Application designers have traditionally ignored flow since it's a physical element that is external to an application, but life and social status extend beyond the digital life and enterprise applications. You get to be known as that finance guy or that marketing gal who is really awesome at work and helps people with their problems to get work done. Needless to say, helping people and getting work done are intrinsically rewarding. Help these people with their core activities and make non-core activities as minimum or transparent as possible. If I am hiking, make my drive to the trail head as easy as possible but make my hike as rewarding as possible. That should be the design principle of how you integrate flow into enterprise applications. Also, focus on perpetual intermediaries; design applications to reduce or eliminate learning curve but introduce users to advanced features as they make progress to increase their productivity on performing repeated tasks. This helps create an intrinsic reward of having learned and mastered a system. As people learn new things they become more complex and unique human beings, and believe it or not, you can influence that in your design of your enterprise software that they spend their lives using it.

Photo Courtesy: Mark Chadwick

Wednesday, March 21, 2012

Learning From Elevators To Design Dynamic Systems


Elevators suck. They are not smart enough to know which floor you might want to go. They aren't designed to avoid crowding in single elevator. And they make people press buttons twice, once to call an elevator and then to let it know which floor you want to go to. This all changed during my recent trip to Brazil when I saw the newer kind of elevators.

These elevators have a common button panel outside in the lobby area of a high rise building. All people are required to enter their respective floor numbers and the machine will display a specific elevator number that they should get into. Once you enter into an elevator you don't press any numbers. In fact the elevators have no buttons at all. The elevator would highlight the floor numbers that it would stop at. That's it! I love this redesigned experience of elevators. It solves a numbers of problems. The old style elevators could not predict the demand. Now the system exactly knows how many people are waiting at what floors wanting to go where. This allows the system to optimize the elevator experience based on several variables and criteria such as speed, priority, even distribution, power conservation etc. This also means an opportunity to write interesting algorithms for these elevators.

This is how I want ALL the systems to be - smart, adaptive, and dynamic. Just like this elevator I would like to see the systems, especially the cloud and the analytics, to anticipate the needs of the end users as opposed to following their commands. The context is the key to the success of delivering what users would expect. If the systems are designed to inquire about the context — directly or indirectly, just like asking people to push buttons before they get into an elevator — they would perform more intelligently. Some location-based systems have started to explore this idea, but it's just the beginning. This also has significant impact on designing collaborative recommendation systems that could help the end users find the right signal in the ever increasing noise of social media.

The very idea of the cloud started with the mission to help users with elasticity of the commodity resources without having users to learn a different interface by giving them a unified abstraction. If you had two elevators in a lobby, you wouldn't use this. But, for a high rise with a few elevators, the opportunities are in abundance to optimize the system to use the available resources to provide the best experience to the people, the end users.

Self-configuring and self-healing dynamic systems have been a fantasy, but as the cloud becomes more mature, dynamic capabilities to anticipate the needs of an application and its users are not far fetched. Computing and storage are commodity on the cloud. I see them as resources just like elevators. Instead of people pushing buttons at the eleventh hour I would prefer the cloud take a driver's seat and becomes much smarter at anticipating and managing applications, platforms, and mixed workload. I want the cloud to take this experience to the next level by helping developers develop such adaptive and dynamic applications. I almost see it as a scale issue, at system as well as at human level. If the cloud does promise scale I expect it to go beyond the commodity computing. This is why PaaS excites me more than anything else. That's a real deal to make a difference.

Wednesday, December 14, 2011

Design thinking: A New Approach To Fight Complexity And Failure


Photo credit: String Theory by Michael Krigsman

The endless succession of failed projects forces one to question why success is elusive, with an extraordinary number of projects tangling themselves in knots. These projects are like a child’s string game run amok: a large, tangled mess that becomes more convoluted and complex by the minute.

IT projects fail all the time. Business blames IT, IT blames the system integrator (SI), who then blames the software vendor. After all this blaming and shaming, everyone goes back to work on another project without examining the project management methods and processes that caused the failure. And, so, they fail again.

There’s no one definition of design thinking. It’s a mindset and set of values that applies both analytical and creative thinking towards solving a specific problem. Design thinking is about how you think and not what you know; it is about the journey and not the destination.

Having followed Michael Krigsman’s analysis of IT project failures, it became evident that design thinking can play an important role in improving enterprise software development and implementation. 
The design thinking approach offers a means to address the underlying causes of many project failures — poor communication, rigid thinking, propensity toward tunnel vision, and information silos.

I have distilled important lessons from design thinking into six principles that can help stop project failures. Along the way, we will draw comparisons with Agile development, since that distinction is often a source of confusion when discussing design thinking.

These six principles, based on design thinking, can help any project team operate more successfully.

1. Put a multi-disciplinary team in charge

You can’t pin down project failure on one person or one topic and yet we continue to use a person-centric method to manage projects. No one on a project team wants to fail. If you collectively put responsibility of the failure or success on the shoulders of the team and get them trained and motivated to think and behave differently you will mitigate much failure.

Multidisciplinary teams champion the user, business, and technology aspects of a project in a more comprehensive manner than would otherwise be possible. Typically, an IT team talks to business stakeholders who then talk to end users, which creates communication gaps, delays, and inefficiency. Far better to create a single team that includes participants from all areas, creating a single unit that includes multiple perspectives.

Try to staff your project team with “T-shaped” people, who possess a broad understanding and empathy for all the IT functions, but who also have deep expertise in one domain to champion that perspective. This approach can ensure that your solution is economically viable, technologically feasible, and delights the end users. A more balanced team also humanizes the project and its approach. Stay small and resist the temptation to set up very large teams. If you believe the “two-large-pizza-team” rule, those projects are team-driven and tend to be more successful. Start-ups can build something quicker because they are always short on people. As your group get bigger and bigger, other people tell you what to do and team members feel less connected to their work as it relates to the outcome.

2. Prepare for failure in the beginning

I recommend kicking off the project with a “pre-mortem workshop.” Visualize all the things that could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them. I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that’s true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation.

3. Be both vision- and task-driven

Design thinking emphasizes storytelling, shared vision, and empathy towards all stakeholders involved in a project. On many projects, participants focus exclusively on their own individual tasks, thus becoming disconnected from the big picture.

While design thinking strives to connect participants to the larger vision, Agile development can be very task-driven. Everyone gets a task without necessarily understanding the big picture, or vision, or even seeing the connection between his or her tasks and the final outcome. In this situation, a project can fail and people may not understand their role, thinking they failed due to someone else’s work. If participants don’t realize their tasks contributed to a failure, they won’t try to learn and change.

On the other hand, vision-driven approaches are very powerful. People perform their tasks, but the story and vision persist throughout the project; the same story gets told by different people throughout the lifecycle of the project to avoid that big picture fading away. All the tasks have a bigger purpose beyond their successful execution. Even good project managers miss this point. At review meetings, it is important to evaluate what the team did right but also revisit the vision and examine how recent outcomes fit the overall story.

4. Fail and correct then fail again

Design thinking contradicts other methodologies that focus only on success. In design thinking, failing is not necessarily a bad idea at all; however, we fail early and fail often, and then correct the course. In many projects, people chase success without knowing what it looks like or expecting to fail; therefore, they do not learn from the process.

One of the challenges with traditional project management is the need to pick one alternate and run with it. Turns out that you don’t know everything about that alternative and when it fails, due to the irreversible decision that you made, you can’t go back. Far better to iterate on a number of alternatives as fast as you can before deciding which one will work. This approach requires a different way of thinking and planning your project.

5. Make tangible prototypes

Agile proposed creating unstructured documentation as opposed to making structured requirement documents. But, unfortunately, that is not enough to solve many problems. One of the core characteristics of design thinking is to prototype everything, to make a tangible artifact and learn from it. The explorative process of making prototypes makes people think deeply and ask the right kind of questions. It’s said that “computers will never give a wrong answer but it will respond to a wrong question.” The prototypes encourage people to focus on what I want to know as opposed to what I want to say. This is very important during the initial design phase of the project.

One of the biggest misconceptions about prototypes is that people think they are too complex to make and are overhead or a waste of time. This isn’t true at all. Prototypes can be as simple as a hand-drawn sketch on a paper or as complex as fully functional interactive interface. The fidelity of a prototype is based on what kind of questions you want answered. People tend to fill in gaps when they see something raw or incomplete whereas hi-fidelity prototypes can be too complete to solicit meaningful feedback. As I already mentioned, most people respond better to an artifact as opposed to an abstract document. Prototypes also make the conversation product-centric and not person-centric. They also help to get team members on the same page with a shared vision.

6. Embrace ambiguity

One of the problems with traditional project management methodologies is that they make people spend more time in executing the solution and less time on defining the problem. Design thinking encourages people to stay in the problem space as long as they can. This invariably results in ambiguity, which is actually a good thing.

Ambiguity fosters abductive thinking — a mindset that allows people to explore what is probable with the limited information on their hands without concerns about proving or concluding that it actually works. It helps people define a problem in many different ways, eventually letting them get to the right problem they eventually should focus on.

This also supports the emergent approach that design thinking advocates as opposed to a hypothesis-driven approach. In a hypothesis-driven environment, people tend to focus on proving a premise created by a small group people. Rushing to a solution without defining the problem, and having no emergent framework in place to include the insights gained during later parts of the project, certainly contributes to failure.

ORGANIZATIONAL BARRIERS TO SUCCESS

Even the best methodology requires organizational commitment to success. For design thinking to work, it is also necessary to address these common organizational issues, each of which can impede progress and limit successful outcomes.

Lack of C-level commitment: Although design thinking is applicable at all levels in an organization, executive management must bless it by publicly embracing and practicing design thinking. Top down initiatives and training only go so far.

When the employees see their leaders practice design thinking they are more likely to embrace and practice it themselves. The same is true with adoption of social media and collaborative tools inside an organization. The best signal to your employees is by showing them a firm belief in the method by practicing it firsthand and sharing positive outcome.

Resistance to change: People in any organization are usually fundamentally against change, even if they believe it’s a good thing. They don’t want to get out of their comfort zone and therefore practice the same methods that have resulted in multiple failures in the past. Changing behavior is difficult but fortunately design thinking can help.

One of the ways I have taught design thinking is by taking people away from their primary domain and have them solve a very different kind of problem such as redesigning a ticket vending machine or a fast food restaurant. My team was hugely successful since it was a completely different domain and it didn’t interfere with their preconceived notion of how a project should be executed. People’s reservations are tied to their domain; they are willing to adopt a new method and new way of thinking if you coach them outside of their domain and then encourage to practice it in their comfort zone.

Lack of industry backing: Despite being informal, undocumented, and non-standards-based methodology, Agile experienced widespread adoption. I would attribute this success to two things: a well-defined manifesto by lead industry figures and organizations publicly committing to adopt the methodology. Design thinking lacks these attributes.

Even though industrial design companies such as IDEO has evangelized this approach, there’s still confusion around what design thinking actually means. This also makes it difficult to explain design thinking to a wider audience. If a few organizations publicly endorse design thinking, create a manifesto, and share the best practices to gain momentum, many of the adoption hurdles will go away.

Lack of key performance indicator (KPI) frameworks: Design thinking faces the same challenge that most Enterprise 2.0 tools face: lack of measurable KPIs.

For number-driven leaders, lack of a quantifiable framework to measure and monitor the impact of a new methodology is a challenge. Some leaders are good at adopting new ways of doing things and others are not. In these cases, isolate a project that you can’t measure and start small. Contain the risk but pick a project that has significant upside, to keep people engaged and motivated. You may still fail, or not achieve a desired outcome, but that’s what the design thinking is all about.

It’s worth noting that Agile, as a software project methodology, has well defined quality and reliability KPIs such as beta defects, rejected stories during a scrum cycle, and the delta between committed and delivered stories.

Fail early and course correct the next time. Remember that adoption and specific practice need correction and not the method itself. Don’t give up.

FINAL THOUGHTS

During my extensive work on design thinking - practicing, coaching, and analyzing — I often talk with people who believe that design thinking is merely a methodology or approach for “visual design.” This view is a false perception. Design thinking comprises a set of principles one can apply during any stage of the enterprise project lifecycle along with other project management methodologies. This approach is valid for the CEO and executive management all the way to the grass roots.

Another common point of confusion is the distinction between design thinking and Agile methods of software development. The primary difference is that Agile offers a specific set of prescriptive processes while design thinking encapsulates a set of guidelines and general principles. Although not the same, the two approaches are highly complementary (even on the same project), because both recognize the benefits of using iterative work cycles to pursue customer-centric goals.

Always remember that real people work on every project. The best methodologies are inherently people-centric and help participants anticipate likely causes of failure. Visualizing failure early in a project is an excellent means to prevent it from occurring. We’re all human and may make mistakes but certainly no one wants to fail.

Design thinking can make potential failure a learning tool and not a final outcome.
_______

I had originally published this post as a guest blog post on Michael Krigsman's IT Project Failures blog

Sunday, April 10, 2011

Taking The Quotes Out Of "Design Thinking"

Bruce Nussbaum, a design thinking thought leader and a professor of Innovation and Design at Parsons The New School of Design, recently wrote that Design Thinking Is A Failed Experiment.

He claims that:

"Design Thinking has given the design profession and society at large all the benefits it has to offer and is beginning to ossify and actually do harm."

Rubbish.

I would argue otherwise. Design thinking is not a catchphrase anymore, and that perhaps is an issue for someone like Bruce who wants to invent a new catchphrase to sell his book. When I tweeted his post, Enric Gili - a friend, co-worker, and a design thinker whom I respect - had to say this:


I couldn't agree anymore. I have learned, practiced, and taught design thinking, for living. I have worked with folks from IDEO, closely, very closely. I have mentored students at Stanford d.school and I live and breathe design thinking. I don't think of it as a method that goes out of fashion. For me, it's a religion, a set of values, and an approach that I apply to all things that I do on daily basis.

I have taken the quotes out of "design thinking".

Just as I don't get excited by the rounded corners and gradients of Web 2.0 I don't think of design thinking as voodoo dolls. To some, this appears to be a failure of design thinking. Design thinking has gone mainstream; it is not dead. What is dead is a belief that it's a process framework that can fix anything and can even cook dinner for you. Design thinking is an approach that codifies a set of values. Design thinking is not an innate skill. It can be taught, gained, and practiced.

"I place CQ within the intellectual space of gaming, scenario planning, systems thinking and, of course, design thinking. It is a sociological approach in which creativity emerges from group activity, not a psychological approach of development stages and individual genius."

Design thinking is ambidextrous; it advocates abductive as well as deductive thinking. The "design" in design thinking is an integrative discipline. As my boss used to tell me, you can't have Ph.D in design. Unless you're a smartypants clever clogs, it doesn't make sense. If CQ is a sociological-only approach, it fundamentally defies the inclusive and integrative values of design, which is a vital driver for creativity.

"It’s 2020 and my godchild Zoe is applying to Stanford, Cambridge, and Tsinghua universities. The admissions offices in each of these top schools asks for proof of literacies in math, literature, and creativity. They check her SAT scores, her essays, her IQ, and her CQ."

It's 2020 and IDEO has gone out of business and so is d.school. I am applying for a new job and they measure my CQ. I miserably fail at this CQ thing, perhaps. Do I care? Absolutely not. I have got my design thinking value system that may not be catchy to sell a book, but good enough to get my job done, spectacularly.

Creative Quotient? Give me a break.

Tuesday, July 28, 2009

Designing An Innovation Incubator To Prevail Over Innovator's Dilemma

The large scale software companies often deal with the tension between incremental and revolutionary innovation. They know that if they only keep listening to their customers' requests the very same customers will put them out of the business. Clayton Christensen has captured this phenomenon in The Innovator's Dilemma. Over a period of time these companies have managed to execute the incremental innovation really well to deliver the same software release after release and occasionally introduce new products. However most of these companies struggle to incubate revolutionary innovation inside the company since it is fundamentally a different beast. The executives are often torn between funding the revolutionary initiatives to ride the next big wave and funding the incremental innovation that the current customers and the market expects. It is absolutely imperative for the executive management to differentiate between these two equally important but very different types of innovation opportunities. Many companies have set up in-house incubators to bring revolutionary innovation to the market but in most cases the incubators are set up as yet another department inside the company that shares the same legacy and bureaucracy. Following are some suggestions on setting up and running an incubator to avoid the innovation disappear down the rat hole:

6x6 cubicle in Iowa won't cut it: There is nothing wrong with Iowa but I won't build an incubator there. Pick a location that emanates entrepreneurial spirit, attracts talent, and is surrounded by good colleges. Scout for a location that has good work-life characteristics where people feel the energy and have social outlets - pubs, hiking trails, good restaurants etc. San Francisco and Palo Alto in the Silicon Valley are a couple of examples of such locations.

I cannot overemphasize the impact of an inspirational physical space that fosters innovation and drives people with insane urge to be creative and build something disruptive. Ditch Steelcase and shop at IKEA. Have a loft-like set-up with open seating, project rooms instead of conference rooms, and have all the furniture on the wheels. Can you write on all the walls? Have alternate comfortable seating all over the places - bean bags, red couches, chairs and coffee tables with tall bar stools. Innovation does not happen in a cubicle. Have an entire team paint the loft with bright colors as a team-building exercise. Pay a mandatory visit to IDEO and d.school in Palo Alto if you haven't already been there.

No process is the new process: The incubator should not inherit your organization's legacy processes. You cannot expect your employees to behave differently to solve a problem if they are restricted by the same process overhead. Throw your application policing process out of the window and let people experiment with whatever works well for them. One of the main reasons why incubators fail because they rely on the organization's product roadmap and capabilities. Don't pick up any dependencies instead simply consider your organization's capabilities as one more source that you can evaluate for your needs. Use open source as much as you can, build your own partner relationships, and OEM whatever you can.

Pizza-size multidisciplinary teams: Can your entire product team be fed on two large pizzas? Smaller and tighter teams reduce the communication overhead, churn, and produce amazing results. Don't follow your corporate headcount calculations. Go for smaller teams. Hire I-shaped and T-shaped people to form a multidisciplinary team. Have a good mix of internal people who understand the business that you are into and the external people that are entrepreneurs or have worked in incubators. Get help from the external recruiters to find the right people since the internal recruiters may or may not have expertise to find and hire the kind of people that you are looking for.

Be agile and design think everything: Design thinking and agile methodology empower the teams to apply an ambidextrous and iterative approach to take on the revolutionary ideas in highly ambiguous environment. Encourage wild ideas, defer judgment, and be iterative. Be visual in storytelling, stay close to your customers and end-users, and have persuasive, catalysts, and performance design. Focus on useful over usable. Have a good-enough mindset and ship often to get continuous feedback to keep improving. Iterate as fast as you can and keep your sprint cycles small.

Seed, Round A, and Round B: This is where many organizations get hung up on an upfront $200M business case to qualify the business opportunity as incubation-worthy. If all the start-ups required to have a detailed upfront business model we would not have had Twitter, Facebook, Google, Craigslist etc. The same incremental business case mindset simply won't work for revolutionary innovation. The disruptive innovation has characteristics that many people haven't seen their in their lifetimes. The organization need to adopt the VC model and embrace the high risk high reward business environment. There will be plenty of failures before you hit a jackpot but that's the fundamental premise of VC funding. Have a separate budget and an investment decision process that provides autonomy to an incubator to make their own decisions without going through a long chain of command. Have multiple rounds of funding to ensure that you are tracking the potential of the innovation right from the seed to the maturity.

Explore all exit strategies: Don't expect to go-to-market with everything that comes out of an incubator. The mainstream product teams in your organization may or may not embrace and support the innovation citing the reasons "not invented here" or "too radical". Focus on your customers and success stories. If you are successful people will come to you instead of you selling the outcome to the organization. Be courageous and kill the products that are not working out and experiment with other exit strategies such as spin-offs, outright sale etc. Try to keep the product portfolio moving. High volume and turnover is a good thing for an incubator. Financial success is not the only success that counts; happy customers, re-invigorated organization, and global visibility as an innovation player are equally important KPI.

Reward high risk behavior: People work for uncertain and highly ambiguous projects for two reasons - higher reward for higher risk and passion to build something new. Design your compensation structure that is fundamentally different than your corporate title-driven compensation and includes a generous equity option. The titles don't mean much when it comes to an incubator. What really matters is the skills, attitude, and the knowledge that people bring to the table. The career path in an incubator is very different than a conventional corporate ladder. Make sure that all the people that are part of an incubator truly understand what they are signing up for and are passionate for the work rather than simply waiting to be a "Chief Innovation Officer".

Friday, April 10, 2009

Amazon's Re-designed Review System Generates More Revenue But Has Plenty Of Untapped Potential

Amazon's design tweaks to its review system has resulted into $2.7 billion of new revenue argues Jared Spool. Other people have also picked up this story with their analysis. I am wary of absolute revenue numbers tied to a feature to derive lost opportunity cost since a variety of other things could have driven the sale. It is wrong to assume that people would not have bought the products had the feature not existed. However I do believe it is a great step in the direction of making the review system more useful and drive more clickthroughs and conversions. Simply the presence of the reviews, magic number 20 in this case, motivates consumers to drill down into the details of a product and its reviews.

Amazon has made significant progress in collaborative filtering through their review system and it is an exemplary of a long tail business model. It has helped consumers to gain transparency and has also helped expose issues with the products. This is not enough. As an e-commerce market leader I would want Amazon to continue innovating around their review system. This is what I specifically would like to see in Amazon's review system:

Mining social media channels: Amazon.com is not the only place where consumers talk about the products. Consumers discuss product features and frustrations on Facebook, Twitter, and other social media outlets. Amazon has an opportunity to provide unified product review experience, a tool similar to ConvoTrack, by tapping into these social media channels for all the product conversations.

Tag cloud as a visual filter: One of the ways to make sense out of large number of reviews is to generate a tag cloud from the raw text of the reviews. A tag cloud acts as a great visual filter to narrow down the reviews that the consumers are looking for e.g looking only at rebooting issues and not anything else while buying a router.

Provide diverse search options: I want to search for the routers that have 4 or 5 stars ratings in the last 6 months. I cannot do that today. This search criteria makes sense. Manufacturers fix defects via firmware updates and models tend to improve as they mature. If the item had many negative reviews early on there is no way to find out without reading the other positive reviews whether the issues have been fixed or not. Higher recent ratings tend to correlate with mature product and satisfied customers.

Re-think one-size-fits-all format: All the products sold on Amazon ranging from a book to a TV has the exact same review format. It does not have to be that way. The book reviews tend to be more subjective and philosophical where the gadget reviews are generally more fact-based e.g watch out this monitor does not come with a DVI cable. Re-thinking the format for the types of products being sold make sense e.g pros and cons section for the gadgets, similar books to the one that I am reviewing etc.

Incentivise people to write reviews: Few days after consumers receive a product ask them whether they are satisfied with their purchase or not. Incentivize them to write reviews on the product; not only this helps generating more reviews per product but it also brings people back to Amazon to make more purchases. Make promotional email personal and relevant e.g.

How are you liking the "Tipping Point"? Malcom Gladwell has authored his latest book called "Outliers" and we are positive you will enjoy that as well. Would you mind writing a brief review of "Tipping Point" and we will discount the Outliers for you by 5%.


Closed-loop feedback channel: The current comments structure does not allow the manufacturers, authors, and the publishers to identify themselves and clarify the features, issues, and respond to consumers' concerns. The reviews are a great platform and a closed-loop feedback channel for the vendors to converse with the consumers. Amazon could certainly extend the review system to help create a dialogue between the consumers and the manufacturers.

Thursday, December 4, 2008

Incomplete Framework Of Some Different Approaches To Making Stuff

Steve Portigal sent me an article that he wrote in the Interactions magazine asking for my feedback. Unfortunately the magazine is behind a walled garden and would require a subscription but if you reach out to Steve he should be able to share the article with you. In the absence of the original article I will take liberty to summarize it. Steve has described how companies generally go about making stuff in his “incomplete” framework:

  • Be a Genius and Get It Right: One-person show to get it right such as a vacuum cleaner by James Dyson.
  • Be a Genius and Get It Wrong: One-person show to get it wrong such as Dean Kamen’s Segway.
  • Don’t Ask Customers If This Is What They Want: NBA changing the basketball design from leather to synthetic microfiber without asking the players
  • Do Whatever Any Customer Asks: Implementing the changes as requested by the customers exactly as is without understanding the real needs.
  • Understand Needs and Design to Them: Discovery of the fact that women shovel more than men and designing a snow shovel for women.
I fully agree with Steve on his framework and since this is proposed as an incomplete framework let me add few things on my own:

Know who your real customer is:

For enterprise software the customer who writes the check does not necessarily use the software and most of the time the real end users who use the software have no say in the purchase or adoption process. Designing for such demographics is quite challenging since the customers’ needs are very different than user needs. For instance the CIO may want privacy, security, and control where as the end users may want flexibility and autonomy and to design software that is autonomous yet controlled and secured yet flexible is quite a challenge. As a designer pleasing CIO for his or her lower TCO goals and at the same time delighting end users gets tricky.

Designing for children as end users and parents as customers also has similar challenges.

Look beyond the problem space and preserve ambiguity:

Hypothesis-driven user research alone would not help discover the real insights. Many times the good design emerges out of looking beyond your problem space.

If Apple were to ask people what they would want in their phones people might have said they want a smart phone with a better stylus and they do not expect their phone to tell them where they should eat their dinner tonight. We wouldn’t have had a multimodal interface on iPhone that could run Urbanspoon.

Embracing and preserving the ambiguity as long as you can during the design process would help unearth some of the behaviors that could lead to great design. Ambiguity does make people uncomfortable but recognizing that fact that “making stuff” is fundamentally a generative process allows people to diverge and preserve ambiguity before they converge.

Friday, September 12, 2008

Google Chrome Design Principles

Many of you would have read the Google Chrome comic-strip and also would have test driven the browser. I have been following few blog posts that have been discussing the technical and business impact but let's take a moment and look at some of the fundamental architectural design principles behind this browser and its impact on the ecosystem of web developers.
  • Embrace uncertainty and chaos: Google does not expect people to play nice. There are billions of pages with unique code and rendering all of them perfectly is not what Google is after. Instead Chrome puts people in charge of shutting down pages (applications) that do not behave. Empowering people to pick what they want and allow them to filter out the bad experience is a great design approach.
  • Support the journey from pages to applications to the cloud: Google embraced the fact that the web is transitioning from pages to applications. Google took an application-centric approach to design the core architecture of Chrome and turned it into a gateway to the cloud and yet maintained the tab metaphor to help users transition through this journey.
  • Scale through parallelism: Chrome's architecture makes each application a separate process. This architecture would allow Chrome to better tap into the multi-core architecture if it gets enough help from an underlying operating system. Not choosing a multi-threaded architecture reinforces the fact that parallelism on the multi-core is the only way to scale. I see an opportunity in designing a multi-core adaptation layer for Chrome to improve process-context switching since it still relies on a scheduler to get access to a CPU core.
  • Don't change developers' behavior: JavaScript still dominates the web design. Instead of asking developers to code differently Google actually accelerated Javascript via their V8 virtual machine. One of the major adoption challenges of parallel computing is to compose applications to utilize the multi-core architecture. This composition requires developers to acquire and apply new skill set to write code differently.
  • Practice traditional wisdom: Java introduced a really good garbage collector that was part of the core language from day one and did not require developers to explicitly manage memory. Java also had a sandbox model for the Applets (client-side runtime) that made Applets secured. Google recognized this traditional wisdom and applied the same concepts to Javascript to make Chrome secured and memory-efficient.
  • Growing up as an organization: The Chrome team collaborated with Android to pick up webkit and did not build one on their own (actually this is not a common thing at Google). They used their existing search infrastructure to find the most relevant pages and tested Chrome against them. This makes it a good 80-20 browser (80% of the people always visit the same 20% of the pages). This approach demonstrates a high degree of cross-pollination. Google is growing up as an organization!

Saturday, July 12, 2008

Make to think and think to make - Design thinking helps a start-up radio show compete with NPR's Morning Edition

The upstart radio show Takeaway's producers worked with the d.school at Stanford to apply design thinking approach to their show that competes with NPR's Morning Edition. It is quite an interesting story about how a legacy media industry can discard a traditional approach and embrace design thinking to rapidly iterate on the design of a radio show.

"A three-day crash course taught the producers the basic steps of d.school innovation: observe, brainstorm, prototype, and implement; repeat as necessary."


"The program's central idea is a daily question that audiences are asked to riff upon, either by calling in or by emailing. Their responses are then woven into the rest of the show's programming."

Not spelled out in so many words in the story but this is a good example of user-centered and participatory design with a crowdsourcing twist to it.

"But recognizing shortcomings and criticism and iterating quickly is one of the design process's core principles. The students in a d.school course called Design + Media, who are using the show as a class project, are helping producers generate ideas and track online response. For example, they're following Twitter streams to find out which questions and other parts of the broadcast are producing the strongest reactions."


Once again this story reinforces that design is an ongoing process and design thinking is not about talking but making and generating more ideas while making to change what you just made.

Tuesday, March 25, 2008

Alaska Airlines expedites the check-in process through design-led-innovation

Southwest airlines is known to have cracked the problem of how to effectively board the aircraft and Disney specializes in managing the crowd and long lines. Add one more to this list, Alaska Airlines. Fast Company is running a story on how Alaska Airlines has been designing the check-in area to reduce the average check-in time at the Anchorage airport . This is a textbook example of design-led-innovation and has all the design thinking and user-centered design elements - need finding, ethnography, brainstorming, rapid prototyping, and end user validation. Alaska Airlines visited various different places to learn how others manage crowd and applied those learnings in the context of their problem supported by contextual inquiry of the check-in agents. They built low fidelity prototypes and refined them based on early validation.

The story also discusses that Delta is trying a similar approach at Atlanta terminal. Passengers see where they're going. The mental rehearsal or mental imagery aspects of cognitive psychology have been successfully applied to improve athletic performance. There have been some experiments in the non-sports domain, but this is a very good example. Imagine an airport layout where a security check-in process is visible from a check-in line. This could make people mentally rehearse a security check while they wait for their boarding passes so that they are more likely to complete the actual security check much faster.

What makes this story even more compelling that they managed to satisfy customers by reducing the average wait-time and yet saved the cost and proved that saving money and improving customer experience are not mutually exclusive. The innovation does not have to be complicated. They also had a holistic focus on the experience design where a customer's experience starts on the the web and ends at the airport. Some people suggest airplane-shaped boarding areas to expedite the boarding. This is an intriguing thought and this is exactly the kind of thinking we need to break out of traditional mindset and apply the design-thinking approach to champion the solution. I am all in for the innovations to speed up the check-in and boarding as long as I don't have to wear one of those bracelets that could give people debilitating shocks!

Thursday, February 28, 2008

Business model innovation opportunities in designing SaaS channels

The business model challenges are far more complex and brutal than the technology or architectural challenges for SaaS and they get compounded when selling to an SMB. It has been argued that the success of complex to implement enterprise software in marketplace is attributed to the channels, ISVs and VARs, to a certain extent since they step in and do the dirty job and it is a very lucrative business for them. If the VARs are not selling it, customers won't probably buy as much. This has serious implications on the SaaS as a delivery model. The fundamental benefits of SaaS such as pay-as-you-go type subscription models, try before buy, personalize against customize, and no physical box are some of the factors that work against the SaaS vendor since there aren't enough incentives for the indirect channels with the current business model.

If a vendor believes that a product is so good that it does not need any (value add) channels, the vendor can use web as platform for volume sell. Google recently slashed down the price of Postini by 90% and it is a move to get rid of the channels since it was an artificial cost barrier. Google believes that now it has much better shot at getting to the right customers at the right price. This move has upset some VARs but it is all about your supplier being smarter than you.

This is the business model innovation that the vendors should be paying attention to. Many enterprise software vendors have never sold over the web and they relied on their direct sales force driving around in their BMWs and selling to the customers. They also relied on the partners heavily. When these vendors move towards SaaS delivery model for volume selling to the SMBs, they have an option to build new infrastructure or use an existing infrastructure to volume sell to the customers. I also see the benefits of web as a volume selling platform to sell anything and not just the software. I can imagine Amazon’s e-commerce platform as a SaaS sales platform and it is also not farfetched for a software company into the business of providing platform via SaaS delivery to sell SaaS software.

Many SaaS solutions originally designed for SMBs do get subscriptions from large enterprises as well since in some cases the IT is fragmented into many departmental solutions for a large enterprise. These departments do not want to deal with the IT and would rather go for a SaaS delivery model even if it means a limited functionality and no integration capability with other departments. This decentralized strategy is a nightmare for many CIOs but in some cases loose integration could also mean higher productivity and a CIO is willing to make that compromise. There are also behavioral issues that a vendor will have to deal with on how to approach customers and whether a customer is comfortable making software purchase over the web where they relied on the partners in the past.

This is an interesting trend that SaaS vendors should be watching for since it simply changes the definition of an SMB. More and more knowledge workers are inclined to bypass IT if they have an access to better and easy-to-use solution. One of the new features of Google Apps is targeted towards this behavior. If you are a Google Apps consumer in one department, you can see who else has signed up for Google Apps (based on the domain name) and can collaborate with those people. This is what I would call it loose integration.

In a way, selling to small businesses is similar to a selling to a set of individual consumers and not to a business since a lot of these small businesses behave as individual consumers. Turbotax is a good example to compare channels for on-premise and SaaS delivery models. Intuit has separate sales and marketing channels to sell TurboTax. Intuit partners with financial institutions such as Fidelity, Vanguard, and Bank Of America to offer discount on the online offering and also distributes coupons for the on-premise offering at brick-and-mortar discount stores such as Costco.

SaaS delivery model, for an SMB or a large enterprise, has many channel challenges and the concept and definition of these channels are likely to be redefined as the SaaS adoption continues.

Saturday, February 2, 2008

Monetizing social networks and preserving privacy - an oxymoron?

How do social networks monetize their core platform and applications? It's more than a billion dollar question, figuratively and literally. The social network companies such as Facebook does recognize the potential of an open platform for participation and developer-friendly attitude to let the community sip the champagne of the social network data. There is a plethora of applications built on Facebook platform and and this might be the key towards monetization. The other key players have also been experimenting with their platforms and business models but there is no killer business model, at least not yet.

Monetizing efforts do ruffle some feathers on the way since it is intertwined with other factors such as privacy, data portability, and experience design. The Facebook's experience design keeps applications' users inside of Facebook but at the same time provide the necessary, or sometimes unnecessary, access to user's data to the application providers. This has set off some debates around privacy concerns. Access to user's data and open architecture is a key to increased adoption that can potentially lead to monetization, but Facebook needs to be careful here not to piss of the users. Compare this with Google few years back where Google made a conscious decision to keep the search results rank clean (do no evil) and that strategy paid off when Google started monetizing via AdSense.

Marketers argue that the spending power of the current demographics of Facebook is not high, so why bother? This is true but don't forget that when these millennial grow up to buy that 60" plasma TV, some companies do want to make sure that they have a brand tattooed in their heads from their previous branding experience on such social networks. As pointed out by many studies, the millennial are not brand loyal and that makes it even more difficult for the marketers . The Facebook is a great strategic brand platform to infuse the brand loyalty into these kids.

Data portability is part of longer term vision for any social network. The applications are constrained inside a social network, but an ability to take the data out in a standard format and mesh it up with an application outside of Facebook has plenty of potential. Leading social and professional network providers have joined the Data Portability Group. Imagine to be able to link your Facebook friends with your LinkedIn contacts and provide a value add on top of that. There are plentiful opportunities for the social network providers to build the partner ecosystem and have the partners access to the data and services in the process of co-innovation. LinkedIn for the longest time resisted providing any APIs and relied on their paid subscription services. LinkedIn has tremendous potential in the data that they posses and standardizing the formats and providing the services has many monetization opportunities. It is good to see that LinkedIn has also joined the Data Portability Group and has also promised to open up APIs. Google's OpenSocial effort, partially opening up Orkut as a sandbox, and social network visualization APIs are also the steps in the right direction.

What I can conclude that the growth of such social networks is in two directions, platform and verticals. As platform becomes more open we can anticipate more participation, larger ecosystem, and service innovation. This should help companies monetize (no, no one has figured out how). The growth in vertical will help spur networks for specific verticals such as employment, classifieds, auction - who knows?

Monetization, experience design, and privacy cannot be separated from one another and few wrong strategic decisions could cause significant damage to the social network providers and their users.

Wednesday, January 9, 2008

Long Nose of Innovation

Innovation is an ongoing process. Bill Buxton likes to call it The Long Nose of Innovation. He describes the phenomenon as the bulk of innovation behind the latest "wow" moment (multi-touch on the iPhone, for example) is also low-amplitude and takes place over a long period—but well before the "new" idea has become generally known, much less reached the tipping point. He has given quite few examples in his post emphasizing that it is all about idea refinement and innovating around the existing technology. It is naive to throw away an idea just because it is old or not "new enough". Few other bloggers have also picked up the story and Techdirt makes an argument that innovation is not a burst of inspiration but merely a process.

Google search and Gmail are the examples that reinforces this phenomenon. When Google launched the search, people said "what, one more search engine?" Gmail was quite late in the email game, but it forced other web-based email providers to shell out extra storage space. Gmail gained significant market share based on the large storage feature and by providing better customer experience.

AJAX is also an example in this direction. The technology support in the browser for AJAX-based applications was available way before the AJAX term was coined or these applications started becoming popular. Gmail heavily used AJAX to innovate around better user experience . So, watch out, what you need is available right around the corner. What you thought was a silly or an old idea may not be silly anymore. IDEO has a "Tech Box" that is a centrally located lending library of innovation elements. Basically, it is a box that contains all kinds of materials, gadgets etc. Many visitors call it a magic box that contains many IDEO innovations, but for IDEO it is a mindset and a physical statement. IDEO team members look into this Tech Box for materials when they are designing or shall I say innovating the next product.

Finding user's right pain-point and provide better experience is a key to this long nose of innovation.

Friday, September 14, 2007

Design thinking and designers

The conversation with Brandon Schauer, design strategist at Adaptive Path, about design thinking is worth reading. Brandon talks about topics such as critical thinking and design thinking, design attitude versus decision attitude, and the importance of business fluency amongst designers.

I agree that for a business problem, you do want to apply design thinking to explore as many alternatives as you can , but you do want to critically think through all the alternatives before you reach a solution and keep your stakeholders informed about your decisions. Not only business fluency is critical to do this but a designer needs to have empathy for the stakeholders as well. Traditional ethnography techniques such as contextual inquiry can be used to understand user's goals and aspirations, but the designers need to go a step further and understand their stakeholders better and for that the designers need to acquire skills in the business and strategy area.

Monday, July 23, 2007

It will be all about criteria and not results

I haven't seen the search results user interface change a lot in the past few years and I don't expect any significant changes in coming years. Jakob Nielsen talks about what search results interface would look like in 2010 during a recent interview. I don't like to predict what will happen in 2010 but I do like to spot the trend and identify the opportunities to improve user experience in general and help improve search semantics. I firmly believe that the search results relevancy is likely to get better and better and we will certainly see more heuristics and machine learning to personalize results based on user's needs and importantly to understand the user's intentions in that moment. The search engine improvements are likely to shift from pure indexing science to better understand the search criteria to achieve relevant search results and there are plenty of opportunities in this area. The “Did you mean this?” correction is just the beginning. This is an area where psycholinguistics can contribute improve the search relevancy. Having said that, I do believe that there is plenty of room to improve the search/results interface and interaction model. Companies like ask.com are gearing their efforts in this direction. Semantic search engines haven't been that successful so far but this is also an area for an improvement in the overall search world.

The interview also brings up the fact that people are generally lazy, but I believe that given the right incentive people might be willing to express themselves better. Spelling and grammar correction is a good example. Though an overly enthusiastic interface asking a lot of information from a user is less likely to succeed. Jakob also talks about perceptual psychology and the ability of showing the images that users are expected to see and actually like and how this approach could turn into banner blindness. The multimedia search results are a big issue going forward as we see more and more user generated multimedia content. A picture is worth a thousand words and a video is worth a million. The images are easy to look at and to comprehend than the pure text but there are challenges on how to select the right images and the same is true with the videos. The video search is an interesting problem and there are many different evolving techniques such as meta information and audio scanning. We will see a lot of progress in this direction.
<acronym id="80kyi"></acronym>
<acronym id="80kyi"><optgroup id="80kyi"></optgroup></acronym>
<acronym id="80kyi"><center id="80kyi"></center></acronym>
<rt id="80kyi"></rt>
<acronym id="80kyi"><optgroup id="80kyi"></optgroup></acronym>
<rt id="80kyi"></rt>
<rt id="80kyi"><optgroup id="80kyi"></optgroup></rt>
<acronym id="80kyi"><small id="80kyi"></small></acronym>
<acronym id="80kyi"><center id="80kyi"></center></acronym><acronym id="80kyi"><small id="80kyi"></small></acronym>
<acronym id="80kyi"><small id="80kyi"></small></acronym>

金猫彩票注册-首页

发彩票平台登录

皇冠足球足球比分

大和彩票登录

royal88平台

www.444yl

好运网站

360彩票官网首页

优德w88免费彩金