How to do user experience when engaged on a new client project?
The challenge – fit in user experience at all stages of your agile project. I looked at the “IDEO way“.
Observation
It starts with observation. Observation should start with shadowing people, taking notes, taking photographs, and taking videos. This stage will establish the overall context for the problem solving exercise. The context will establish the end user as a human being instead of a faceless “user”. The problem has to be framed in the terms of the overall context. Instead of simply focusing on specific tasks, start with end user goals – broad and ambitious goals. These goals should guide the development of the applications throughout its lifecycle. What you shouldn’t start with is interviewing users on what they want. In my opinion, the interviews tend to focus on specific pains within the context of the existing applications. Interviews tend to generate ideas that solely focus on fixing the pains that exist right now. Instead, start by interviewing people who may provide the organizational perspective, and the departmental perspective. Once a broad view is established, dive into observation mode by shadowing the users in their day to day activities. Connecting the dots that emerge through this activities provide invaluable insights into what the users are trying to accomplish. Armed with still and video cameras – even something as simple as a phone camera or Flip recorder, you can start to piece together a picture of the user environment, their goals, their usage patterns, and how they interact with their computers, phones and other teammates.
Once you have had a chance to assimilate all the input, go back and interview with more specific questions to help guide the vision for the new application. However, don’t put the users in charge of the innovation. Solicit opinions on their pain points, but use these points as another source of input, not the sole guide for new features.
Ideas
Part of observing includes picking a diverse group of users to bring in as many ideas as possible. There is nothing wrong in copying ideas from other sources that have inspired you. However, encourage diverse and outlandish ideas. At this stage, the mission is to generate as many ideas as possible. Don’t underestimate how hard it is to go through a brainstorming exercise without overt criticism. Team may have the tendencies to start debating ideas as soon as they are generated. The art is to simply log these ideas to come back to them at a separate time. By separating the sessions for generating ideas and judging ideas, you can encourage lateral thinking in the first session.
Rapid Prototyping
Mocking up everything is the key. Ideas can come to life when mocked up and it helps in the narrowing of the choices.
Narrowing down the ideas
In this session, the objective is to focus on those ideas that are executable and the best ideas out of all the ideas generated in the previous session. This session is where the team can debate pros and cons of each idea and get a collective buy-in on what needs to be done. Involve end-users in helping narrow down the choices. Get the buy-in from the project sponsors and executives at this stage. Instead of just focusing on the screens, branch in role-playing the end-users and how “a day in the life of” scenario might work with the new solution.
Implementation
Implement in an iterative way and make it a point to involve the users at frequent checkpoints. Simplicity is hard to achieve. Keep focus on the end user goals and demonstrate the partial product on a frequent basis. Solicit additional user experience feedback and plug it into the enhancement queue.
This entry was written by , posted on April 11, 2010 at 9:57 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Made in China
Progressing from the slideshow last week, I converted the presentation into a podcast. Watch it here.
This entry was written by , posted on April 5, 2009 at 6:42 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Great philosophies underlie great products
Ever since I first used hulu.com, I knew that it was a work of a great team. I was even more delighted to learn that the product was developed partly in China with the help of an offshore team. The core teams are located in Los Angeles, Chicago and Beijing.
From the CNN article, “Money, it turned out, was not an object for Hulu. In May, Providence Equity Partners offered a cool $100 million for a 10% stake – giving the nascent operation an astonishing valuation of $1 billion.
But the secret of Hulu’s initial success – the thing that made believers out of the skeptics – is the power and simplicity of the website itself. Hulu’s creators focused with almost obsessive attention to detail on the user’s experience.”
So how do companies become great and create ground-breaking products? The answer partly lies in the underlying philosophy behind the organization.
Here is an excerpt from “What defines Hulu”: “We are passionate in our opinion that the world has long since exceeded its quota in the mediocrity department.
We believe our professional calling is to deliver quality. And not simply run-of-the-mill, five-star quality. For Hulu, nothing less than brain-spray awesome quality* will do, down to the finest detail. This atypically high quality bar leads us to sweat every pixel, every second of transcode, every customer.”
So when you are making your next product, ask yourself this question: what is the definition of quality for you? Will your product get a response like “My first hulu experience made my head explode in a brain-spray of awesome.’
This entry was written by , posted on October 6, 2008 at 4:23 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Let your code automatically open defects
Opening defects is time consuming. So why not let the code automatically enter defects in your bug tracking system. Of course, this means your bug tracking software should provide ability to open defects via APIs, via Emails, or any other programmatic means.
Second, all untrapped exceptions must be logged as defects automatically by the exception handling code. Now how do you determine if the same defect is already logged and prevent a flood of the such defects?
One easy way to uniquely identify a defect is Line Number of the Code. Every time an exception occurs it originates at a certain line of code in a certain class. Thats the unique identification.
Before opening a new defect, the bug tracker should check if a defect exists with same class and same line number. If it does exist, then the new event gets appended to the existing defect instead of creating a new one.
Want a bug tracking/project tracking software that already does all of the above? Try FogBugz.
This entry was written by , posted on at 4:17 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
"No matter how cool your interface, less would be better."
How long will we keep building software that has 10 search boxes on its search page? Google launched in year 1999, and its user interface has one text field and two buttons(one too many in my opinion). Today we are still building screens with more than 50 items, numerous buttons, drop-downs, long scroll after scroll. When will we learn that users need less not more user interface.Choices = Headaches
Imagine you are building a user interface for the Army, for a battle decision control system, where pushing wrong buttons could result in loss of lives. Now rethink the interface from the army commander’s perspective – how would you present this information. Suddenly you become sensitive to throwing more drop-downs, text boxes and buttons on there. I think you have started to see the picture of the impact of your user interface on the day to day life of the end user.
How do we innovate our user interfaces. Certainly not by “asking” the users what they would like. Innovation is creative solutions to user pains that may come by “observing” the user, their context and their larger world in general. It cannot be accomplished simply by “asking” the user. “Why” is a friendly weapon in an innovator’s arsenal to determine what the user motivations are, and what the current pain points are. Of course, it takes creative software development team to convert the idea into working software that resembles something that understands the user. This is why it is my firm belief that great software can only come from teams that have user empathy at the core of their effort, whether their contribution is that of a requirement writer, designer, developer, or tester. If every single person on the team cannot envision their product in the hands of the eventual user, they will not be able to build a very effective piece of software. Every small decision that a requirement writer, developer or tester takes has eventual impact on the usability of the software. It is virtually impossible to make software development “factory like” work with specifications, in my opinion. The states that the executing code be in at any given moment explodes once developers start converting requirements specifications into executable code. At this point, developer make conscious decisions on the behavior of the software, sort of “reading in-between the lines” of the specifications. How good the product will end up to be will depend on what developer wrote and what the tester interpreted as the requirement to be.This is as much art as much it is science. The quality of your people will determine the end result.
So we owe it to our teams to teach them to write software with less interface and coming up with innovative ways to solve the problems that the users don’t know need solving yet.
This entry was written by , posted on at 4:17 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Need for Speed
When porting a thick client application to a web based application, there are some significant challenges that the team needs to think about.
Let me illustrate this transition by hypothetically taking away some of your favorite thick client applications. Imagine your boss comes in one day, and tells you “We are getting rid of all thick client applications because this is 2008 and we will be moving all application to web based interface. So tomorrow you will be receiving new computers that will only have a web browser (kinda like the machines you see if you ever used Denver Public Library computer).
No more MS Word or Excel or PowerPoint or even Outlook. Eclipse? ha! use an online text editor. Instant Messenger? use web based chat.
Just imagine going one day by just using web based versions of your favorite applications. Not a pretty picture. Why is this? Many reasons, but primarily because most web based applications do not provide the same user experience as a thick client does. That and our need for speed. Many web based application still perform poorly compared to their thick client cousins.
Web usability guru Jacob Nielsen talks about response times highlights pretty interesting facts:
1) 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
2) 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
Jacob also provides some useful advice on how to design the interface so as to make it more responsive to user needs. Notice that there is a difference between actual response times and perceived response times. What matters to end user is perceived response time.
So when rewriting an existing thick client application to a web based interface, these challenges must be kept on top of list or the application will be what Outlook for Web Access has become. A nice to have alternative that you will use only if Outlook thick client is not available.
This entry was written by , posted on at 4:16 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Performance and Usability – The missing link
When an existing application is being replaced by a new application, performance and usability requirements become intricately linked. In case of data entry applications, what matters is the speed and agility with which the user can get through a given scenario. This is where things get tricky. The speed is not only a function of how fast the system responds (performance) but also how is the interaction design of the application aiding in that agility(usability).
Consider a call center customer care application. If your boss comes to you and says “I need you to plan a new call center. Let me know how many people will you need to answer calls and manager those who are answering calls”, you may naturally ask questions such as “how many calls do we receive on average and peak times?” and “what types of calls are coming in?” and “how long does it take typically to get through a single call?”. Since you are a math genius, you figure, you will do some math and take number of calls on an average day, multiply by time it takes to handle a single call and divide by 8 hours.. and ta da you should have a magic figure of how many people you need. So some years pass by and existing application must be replaced with a new application. How is your life as a call center manager going to change?
Is the new application making the customer service representative take longer to get through each call or its making their life easier by taking less time than before? Is the application high friction and making the life of the customer and the service representative much harder?
So how do performance and usability play into this? Performance testing in isolation is only step one. Step two must be a combined usability drill during peak load conditions to validate that the new application indeed makes life better.
If you were the customer paying for the new application, wouldn’t you expect this validation?
This entry was written by , posted on at 4:12 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
New Maxims I learned from my latest project
….until newer Maxims demolish old ones:
1. Time taken to do reviews(all artifacts – requirement specs, design spec, code, test cases etc)
is directly proportional to application quality and inversely proportional to number of defects.
2. Definition of “Done” = QA executes the software with acceptable types and amounts of defects.
3. “Working code against tiny database” != “Working code against production size database”
or “Tested against tiny database or tiny files” != “Production Ready Application”
4. Cross vertical understanding by developers is directly proportional to code quality in a given vertical.
4a. Business understanding by developers is directly proportional to Quality of software.
5. Agile development != Automatic Quality and Success
or Speed of agility is directly proportional to Risk of Architecture shifting requirements discovered late in the cycle.
6. Not integrated software = Not working software.
7. Nightly Trunk Building, Deploying and Smoke Tested = Stability.
7a. Nightly Master Build = Successful Compilation + Successful Unit Tests + Successful Integration Tests + Successful Deployment + Successful Smoke Testing
8. Number of Branches is indirectly proportional to Stability of Code.
9. Duration of Branches is indirectly proportional to Stability of Code.
10. Developer Estimate != Commitment
11. Contract = Commitment
12. Probability that Estimate in Contract is in vicinity of accuracy = 0.
13. Probability that Contract will be altered as project progresses = 0.
15. The usability of a product is directly proportional to the hourly salary of the intended end-users.
16. Defect Fixing – Root Cause Analysis and Addressal = Lost Opportunity for better quality.
17. Probability of defects slipping in is indirectly proportional to build, test, deploy speed.
This entry was written by , posted on August 3, 2008 at 8:21 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Developing Great Software that Changes People’s Lives
Software development is not just about using technology to solve problems. Rather it is about offering tangible value. A good software developer hopes his or her effort will result in something that will be liked and used by someone. However the truth is that a vast majority of the software out in the world produces one common emotion in people – frustration.
I am considering two different types of software applications in this article. On one hand, we have shrink wrapped software written by some independent software vendor (ISV), and on the other we have applications written by the software department of a non-ISV to support the firm’s internal or external business processes. There are interesting differences between the two.
Lets consider the non-ISV software first.
In today’s world, the workforce is a moving target. Under such scenarios, software built to support internal processes are primarily of two types. Commercial Off the Shelf (COTS) or custom developed applications.
COTS is some software vendor’s idea of how your business might do its business with customization. Custom developed applications are a result of the workforce’s idea of how business must be done, or at least the idea of someone in the workforce.
If the workforce is changing, then present reality may not be real tomorrow. Hence by definition the internal systems will lag behind the changes occurring in the business place. The systems will not be proactive agents of change.
Inevitably, such systems will lead to frustration for people using them as well as people responsible for their upkeep.
For ISVs, its challenging to build something for a huge indeterminate audience. Using software essentially involves engaging in specific behaviors. To a large extent, the software will force the users to choose from a some specific set of behaviors.
This scenario by definition means change in user’s habits while interacting with the computer.
A great software product is a pleasure to use, irrespective of the goal you are trying to accomplish. Whether it is a customer service representative, recording the call or a commodity trader making a trade, the interaction should induce a sense of fulfillment.
Any repetitive task will eventually get boring. I do not know of any school of software which advocates boring programs. Yet, product after product are churned out barely making the grade. Why? It due to the fact that most software designers cannot imagine seeing their user in action, not just for a day but day after day of interaction with their software applications.
Why does the typical software application have the appeal similar to a mathematics problem solved on a page in a notebook? Add a new customer, edit details, update your account etc. Endless such programs are created causing emotional nausea among users.
Who among us knows of users that exclaim that the part of their job that they love is the opportunity to use the software to “Update Customer Detail” or fill endless computer forms without feeling stupid or someone telling them that “they do not know how to use the software properly”.
Fixed context problem solving approach.
Whenever a new application is written, it is from the viewpoint of a fixed domain, or fixed context. “We need a customer management application, Bob.” It should be able to interface with our multiple vendor systems, our inventory systems and our data mining applications. Great! Yet another piece of misery inflicted upon some wheel in the process workflow, forced to submit to the software’s dictates, entering information, producing reports, wondering why they didn’t take up the art as a career instead.
Instead, what if the executive were to say, we need a software application that makes it fun for customer service representatives to manage our customers, gets the job done in the simplest possible way, and actually makes it visible to the representative what impact did the actions make, while making it fun for them.
How about a trading application that actually allows me to become a better trader, not simply being the fastest trade and real time data enabler. Isn’t that my primary goal, be a better trader to be able to make more money? Now, such software would be truly revolutionary.
For most software developers, the computer and the person complete the equation in terms of the context. Well, we couldn’t be more wrong when approaching software applications. The entire domain of workplace is ignored in most software applications.
Where your customers are? Why are they there?
Are people talking to other people while using your software? Does the user have ten instant messaging windows open? What if they have to leave the work half-way and evacuate for a fire-drill?
A fifty field form submission is denied because the software does not like the way you entered your zip code. If zip code was absolutely essential wouldn’t you get all the letters back from the Post Office saying, “Thanks for making the trip to the Post Office and dropping your letter. Unfortunately, you forgot to write down the zip code, and you must complete this and drop the letter again.”
Writing an application for commodity traders to trade and an application for a point of sales clerk to complete a transaction, completely different scenarios, yet we can hear the argument, well only the user interface is different. Any good developer can write all the other parts for the application without any problems. But it is the whole environment which should guide the application development from end to end. We cannot isolate it to just user interface differences. Different environments, different needs and hence completely different understanding of how to build that software that could change people’s lives.
“It’s something that I cannot live without”. Is your software producing this emotion in your users? It’s important to ask this question again and again during development and subsequently as well. It will allow you to get rid of annoyances from the beginning. A lot of time I hear in development meetings, “Yes I know this will be annoying to the user, but…… “. How can we even dare to keep our users in contempt and follow such sentences by something that’s usually making our (the development team) lives simpler.
Such mentality results from partly the way technology progresses.
In the software marketplace, there are companies that are creating the mass production framework and technologies which hungry IT houses and ISV devour till the technology runs out of steam or something new comes along. A firm that I worked at, spent couple of decades building a large unwieldy infrastructure in one platform only to start abandoning it in favor of newer technologies. How do they expect innovation and a quick ROI if no proactive and adaptive frame of mind existed for over two decades?
There is a great lag between building software and keeping it exceeding user expectation on a continuous basis. Most software companies do a poor job f letting the customers even feed into the priorities and expectation for future version of the software. Imagine a company that sells you some software with a promise that within one and half month of your initial purchase and use, you will see another version of the same product fitting your needs more closely. Wouldn’t that be an exciting proposition?
Of course, you cannot let the users direct the innovation your company is producing, but can you at least take them along on the ride and let them feel that their concerns do matter and will be addressed. I find that lacking tremendously in most packaged software out there. Something of this nature would be a nightmare to implement with a hardware product (imagine buying an Ipod with the promise that within a month, they are going to give you a better version based on your usage of the product).
It is not only possible but must be done on a ongoing basis. Imagine a company that doesn’t leave you once your credit card has been charged. Wouldn’t this spawn off some new methodologies for building software packages. Millions of dollars are spent on creating, maintaining and running expensive software application. I cannot imagine how little of this money goes into an active feedback cycle upon deployment.
The truth is that we as users expect very little from software. Majority of users are not demanding. They submit to the whims of the software rather than be more demanding. Only eight percent of VCR owners know how to program it. Why? We simply found it too challenging and did not demand simpler ways to program it.
I don’t know how many developers I have seen who have no real desire or passion to put the product into the hands of real customers. They are well meaning people, but beyond solving a particular software problem, the interest wanes on seeing it in action in user’s hands. That’s someone else’s job in their mind. They could be building the most complex and satisfying application, but the desire to see it in action with happy end users is almost non-existent even in most supercharged teams.
An important piece missing from traditional software life cycles is production software experiences and its incorporation into software itself. I have seen lifecycles talk about maintenance and warranty, but critically lack talking about any real means to observe, record, incorporate feedback from real users into the software product itself. To this regard, even eXtreme programming talks about involving users into sequential iterations but all change must come from the embedded user or representative into the team. There is practice listed which states that software is never really done and is similar to an evolving species. (Survival of the fittest software theory)
How would users react to the fact that they are being delivered “unfinished” software. It would be the honest thing to do. Couple it with a guaranteed promise of evolving software. There is hope in such a tool. How many software vendors promise user input manner, but how hard is it for an average user to make the opinion known and see it actually make a difference. I see no standard way that organizations do product improvement based on user feedback.
Improvement is not the same thing as innovation. Innovation is thinking of something that does not exist yet and certainly we cannot delegate this important task to user feedback alone.
In the next part we will examine Innovation in greater detail. How we have progressed from text based interfaces to today varied means of accessing information and interacting with it.
Any software that needs long training phase and a lag phase before user becomes productive on it, is expensive from the business point of view. Rarely, the cost of user training is built into the costing of software development. A truer picture will only emerge when vendors start incorporating the cost of end user training into the total cost incurred by the buyer.
If a user can learn the core functionality of a product in less than an hour, we can say that the software package is pretty lean on its training needs. Lengthy training periods tend to overwhelm hapless users and they generally gravitate towards using simpler software.
Compare the way Microsoft implemented Search in the Desktop to the way Google searches the whole World Wide Web. We know who the winner is.
Pebble Drop Approach
Even a tiny pebble tossed into the calm waters creates a ripple effect. Similarly, each software product put out to the users has the possibility of creating ripple effects into how they interact with the computer and do their business. Unfortunately, most software development processes end once the software is deployed and do not harness the energy created by this ripple. A tremendous opportunity is lost here.
You have got someone to use the software written by you. But you have put little or no formal methodical effort into gaining insight by measuring and quantifying their reactions to the software.
Most software development processes ignore this part of the life cycle. It’s a mistaken belief that the software development life cycle ends with delivery of the product or lives on in a dormant fashion during the maintenance phase.
Indeed some organizations utilize the beta testing phase to gather feedback about the upcoming product and also glean information about bugs that have slipped their development cycle. The beta users represent a fraction of the actual users. Big decisions about the product are generally taken by this time. Beta users can suggest improvements however; it is unlikely their feedback has a major impact on direction of the product. Also majority of the beta users are using the product in a “testing” mode. They are usually advanced users and are likely to view the product from the point of view of a wider spectrum.
Why would I buy Version 1.0?
If the customer knows that you are coming out with version 2.0 soon why
should they bother looking at version 1.0. This continues to be a genuine risk area for hardware products, which cost more and not quickly upgraded or replaced.
A customer wants version 1.0 of a product, for the following reasons:
- The need outweighs the rationale of waiting for a better version
- Version 1.0 can be used in a different capacity upon upgrading
- Version 2.0 is cheaper to upgrade than buy anew.
- Many important needs are already fulfilled by version 1.0 right now.
This entry was written by , posted on December 24, 2007 at 1:00 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
How many clicks to get to what you need?
It was in the news today. CBS bought Last.fm.
I admit I had not heard of it before. So I decided to check it out.
Type in www.lastfm.com into the browser.
What strikes you on the home page is “Start Listening with Last.fm” I had no idea what it meant at the time. So I punch in “Diana Krall” looking to listen to one of the smooth creations from the Vancouver native.
It took me a single click. The Last.fm radio played on for hours.
What a satisfactory user experience! From not knowing anything about the website to being on it for hours.
This entry was written by , posted on May 30, 2007 at 7:11 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.