Why car companies need to do usability testing

Overall I love my Toyota Prius. Under the hood, it is an engineering marvel. Prius' have been around for 10 years and still sell like hotcakes.  I honestly don't understand why Ford hasn't made a competing product by now.

I have come to realize that I pay attention to design more than the average person. I hate it when simple design mistakes ruin an overall well designed product. The interior of my Prius has some obvious problems that could have easily been fixed had they asked the right questions.


Separation of Concerns
Is there any reason they needed to put the door lock/unlock button between the buttons that operate the windows?

 

The buttons feel different - therefore its not likely that I'm going to press the wrong button. However, nearly every time I want to use one one of the buttons I have to take my eyes off the road and look at the buttons to choose the correct one or I have to feel each one to get the correct one. This simply violates the principal that you shouldn't make your users think necessarily.

Positive Actions vs Negative Actions

-and-

Direct Users To The Most Common Action

To me, Toyota completely confuses button shape and action. Its been nearly 8 months and I still have to stop and think about which is the correct button. I occasionally make the wrong choice and send a caller to voicemail rather than picking up the phone. Take a look at the phone answer and hangup buttons:

The button to hang up the phone (the top one) is raised. I consider this the negative action. The button to answer the phone (bottom) is sunken in. This bothers me for two reasons:

#1 If I'm driving and the phone rings I'm being interrupted.  Thus, I'm not 100% focused on the phone yet. The easiest button to find is the raised button. This should be the button I hit to answer, but Toyota made this the hangup button. Maddening.

#2 When I'm ending a call the sunken button makes sense. No matter what mnemonic I go through the raised button doesn't work for ending a call/conversation.

Because I'm thinking about what the right button should be I sometimes make the wrong choice because I'm thinking too hard about doing the opposite of what comes naturally.

*Note: They make all Toyota Prius' for the whole world in Japan. The above concerns might be personal issue or an issue of how British/Americans view the world. I don't know if Toyota makes all of their cars the exact same for all geographies either. 

Looking Back at My Most Popular Posts

Anybody who has worked with me knows that I'm a fan of analytics. If you are selling soap or software development services, I strongly believe you should be capturing metrics on how people use and interact with your product. As such, I have Google Analytics on my blog. I have learned quite a few things about my content over the past few years.

#1 Short blog posts are the most popular.

#2 However, the longer multi-part ones engage users more

#3 Good content draws people in. Of the people who stay on my blog for more than 10 minutes - which is a long time in the web -, half come in through the top 5 posts.

The top 5 posts are:
Boarding Pass - You're doing it wrong
How to Interview and Hire a Good Project Manager
Effective vs Efficient Teams
Principled Leadership
Maker's Schedule, Manager's Schedule

...not in the top 5, but one of my favorite posts...
Systematic Amateurism

Patterns of traffic

Usage:

• 10% of traffic comes to the site and reads the blog in depth. They stay for 600 or more seconds. These people are truly finding the value in the content. I'm pretty happy this is so high.
• 30% of traffic reads the very short posts and sometimes shares them with other people via twitter or email.
• The other 60% of visitors bounce out immediately. This is actually pretty low compared to what I have seem on other sites.

Traffic Sources (non-bounced i.e. the other 40% of visitors):

• 20% of traffic comes from searching Google for my name. I assume these are people whom I have met at meetups or have heard about me. If this was higher I would be a bit disappointed. I want people to come to the blog in order to get valuable content. For me, its not only about personal marketing. 
• 75% of the traffic comes from people looking for a specifics topics. For example, "Lean Software Development Techniques"
• 5% of traffic has no disernable pattern. For example, "dominator influencer supporter critical cd"
  

Conclusion

• No more book reviews. They are time consuming for me to write, have a very high bounce rate and get very little traffic
• Most of the medium sized blog posts (4-8 paragraphs) are not valuable to people. This tells me I need to put a quick post together or cover a topic in depth. This is good news as well. I find quick posts enjoyable and the longer ones I really dig into and think about for quite some time which is also enojoyable.

Jakob Nielsen's Kindle Fire Usability Findings

I don't like to re-post, but I highly recommend reading this. Tablets are, finally, not going to go away and will only increase in usage.

Jakob Nielsen does a great job of discussing the usability and design of 7-inch tablets. Then he talks about the future of 7-inch tablets based on the market and design choices required to ensure their future.

http://www.useit.com/alertbox/kindle-fire-usability.html

Review: Individuals and Interactions an agile guide

In Individuals and Interactions an agile guide, Ken Howard and Barry Rogers give us a set of tools for managing individuals on agile projects. They acknowledge that "There have been countless books on the subject of human behavior and communication. Psychologists, sociologists, organizational behavior experts, and others have conducted studies, published journal articles, taught courses, and granted degrees in this subject area." Since the philosophical science has been covered in detail by many many others, this book focuses on specific tools you can use for individuals and interactions on agile software projects. It jumps right into actionable techniques without much exposition. It assumes you are fully in agreement with running projects utilizing agile project management practices. Fair warning: The book might feel quite one sided for some if you come from a heavy command and control background or don't agree with agile principals. You might get a bit frustrated.

In the first few pages the book discusses what a group of people behaving as a team looks like. How a "team" of individuals working alone isn't as good as a team working together.  How productivity increases once a team stops focusing on process, but on results. Next the book brings up the concept of the DISC behavior model. I really liked the quick explanation of DISC as "a behavioral fingerprint." For those unfamiliar with DISC it segments people into 4 categories: D—Dominator, I—Influencer, S—Supporter, and C—Critical Thinker. I generally hate to label people, but I find myself using DISC often when thinking about how to work with people professionally and personally. Its a useful tool.

After a detailed section on team dynamics the book moves to communication. Agile projects can succeed or fail based on the quality of communication of the team. I found a section about body language particularly interesting. Surprisingly, body language has never been included in any manager training I have been through. On Agile teams a project manager pays a lot of attention to the nuances of how people talk and work together. Body language tells a lot about the conversation. Its big tool to fail to have it in your tool box. I'm not a particularly empathetic person, but I notice a lot when it comes to my teams. The reason is that I read a book about body language when I first got in the workplace and feel that I have been at an advantage ever since. Finally, the book moves on to the highest form of speech: collaborative interaction. Its probably a blog post in itself so I suggest you learn more about it from reading the book.

Next in the book is a section about people's motivators. It goes into more detail than the simple adage: Some people follow a craft for the money, others make money to follow a craft. The book ends with a focus on people's strengths. My experience is that many people look to change and "improve" individuals vs directing them toward what they are good at and will enjoy.

The final part of the book is filled with a few workshops that are useful for those who want to facilitate a group into cohesion. I worry that they might be hard to get through in a very staunch environment. Of course, I haven't seen too many staunch organizations successfully do Agile anyway. Your milage my vary.

The final part of the book has a personal DISC test you can take. This is useful because, in my 5 minutes of research on Google, I couldn't find a free one on the web. Again your mileage my vary.

Overall I think this a great book for those who are doing agile, but only have a perfunctory understanding the mechanical processes. This book will round out your understanding and have to understand the why of it. If you have been successfully using agile principals and practices for a number of years, you are likely to find something useful in this book too.

Its short, pick it up. You won't be disappointed.

Review: Leading Lean Software Development

I am reviewing books I have read in the past for an upcoming coaching gig. I realized I hadn't posted this review on my blog yet! This is from over a year ago, but its still relevant as I work with more and more customers who are now becoming interested in Lean software development. This is still one of the better "agile" books I have read in the past couple of years. Here is my review:

In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.”  If you are completely new to agile and lean you the book might move a little fast for you.  If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

Six Reasons Why EA Should NOT be Assigned to the IT Department

I have always disliked working with the "big architecture" people. It was only in the last 5 years that I came to realize why.  Enterprise Architects are often software developers who have reached the pinacle of programming greatness. They can solve massive problems and are truly amazing software developers. However, they often lack business accumen. As such, their solutions don't consider the most important part of the solution - the business' goals:


EA is short for Enterprise Architecture:

1. EA ≠ IT Architecture
2. True EA leads to redistribution of authority, which is beyond CIO jurisdiction.
3. EA value proposition (i.e. standardization vs. innovation) is solely business realizable.
4. The primary goal of EA is to build coherent enterprises, not better IT systems.
5. Synthesis takes precedence over analysis.
6. EA failure is an organization failure, not an IT failure.

I came across this post on LinkedIn and felt I needed to share. It was posted by a person named Pallab S who is an Evangelist [Enterprise Architecture Practice] at National University of Singapore | Institute of Systems Science.

Agile In Regulated Software - Partnering

This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:

Photo By: JD Hancock

Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it be likely that you will produce a better product now. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with the business and marketing? Here are the difficulties you will likely face:

• Goals are different
• The phases and corporate dialect are different
• Time frames of when decisions are made is different
• Required documentation will be different and address different goals
• Stakeholders will feel comfortable giving verbal requirements, but you must to document them, get them formally approved and finally build them into working software

How do you partner with the business and still meet your commitments? Follow the practices I presented earlier and stick to the following principals:

• Consistent focus on activities that add business value
• Build trusted partnerships
• Constant customer engagement
• Continual process and practice improvement
• Be collaborative and transparent
• Work together: No heroes, lone wolves, or cowboys
• Pay attention to the team and adapt as needed

Agile in Regulated Software - Sweat the Details

Very few people in the software development community have issues with maintaining good attention to the details. However, I bet those who live in the regulated software community view the “normal” software world as quite sloppy. Attention to detail is a matter of life and death for a medical device. Because of this, the entire software community does a good job maintaining checks and balances. I have three suggestions that will make a tremendous difference when you start a regulated project or when you finally get near to releasing your medical device.

Photo by: myguerrilla

#1 Plan to get audited

It is a good bet you are going to get audited sooner or later. Its even possible to get a product out into the market only to have it get audited a second time. An FDA auditor will keep asking “why do you think that works?” type questions and continue to drill down until they find something or are satisfied there is nothing to find. If they find something you are going to get a warning letter and start the expensive process of FDA remediation. Getting past this will cost you a significant amount of resources and likely delay new product development. Usually just in time for your competitors to catch up. Keep good records.

#2 Do Test Driven Development (TDD) Well

By well I mean do all of the normal activities that are part of TDD … and do one more thing. Create self documenting code that also lends itself to traceability directly back to product requirements. Imagine telling an auditor that you can prove that you tested every path of the code EVERY time you checked your code in…thousands of times.  All of these tests can be directly linked back to product requirements. That would make an audit pretty easy.

#3 Create a Traceability Matrix

This may seem obvious. However, I know of many, successful, software shops that have stopped doing this. Ask a developer with 1-2 years of experience why they would need a traceability matrix and you will know what I mean. If you are planing to get audited and want to show that all of your requirements have been tested thousands of times, you need a traceability matrix.

Next up: Partnering

Agile in Regulated Software - Its not what you wear. Its how you wear it.

Its not what you wear. Its how you wear it.

Photo by country_boy_shane

I have to thank Tavi Scandiff-Pirvu for coining this expression as it relates to regulated software development. As long as you use industry standard methods, the FDA allows you to determine the rules that you are going to follow. If you want to have 15 exhaustive steps in order to build each piece of functionality the FDA will say, “Go do it. Just document each step as you go.” If you can reach the same quality in only 7 steps the FDA will say, “Go do it. Just document each step as you go. The FDA isn’t going to test your software in detail. They are going to test your process to ensure that you did what you said you were going to do. This may appear that the FDA is interested in the product but only the process! But, the FDA also wants to see (via documentation) that you built the product features you claimed you had.

The criminally minded will see an opportunity to claim they did more than they actually did via documentation, but in reality do less work. However, there is a natural equilibrium via the market. If you cut steps you will likely pay for it in your product via poor quality and sales. In the end the product has to work. Also, experience shows that it generally takes just as much time to design, create the documentation, necessary traceability and tracking support as to do the actual work. Inefficient? Slightly, but we are trying to sustain human life – not make a quick buck. Its not just about the money. Finally, a big picture analysis shows that it is cheaper for everyone to document what you did rather than pay somebody from the FDA to be a part of your project on a daily basis.

Don’t cut corners, or change your process, once you define it just to save time and money!

My final thought is that in order to do good process design (the 7 step version vs the 15 step version) and thorough documentation you will need to know your organization and team well. You will also need to know the product well so that you don’t design a seemly efficient process that is blind to the needs of the market the product will be launched in.

Sorry kids. Nobody ever said it was going to be easy.

Next up: Sweat the details

Agile in Regulated Software - Functional Testing vs Technical Testing

Testing is a crucial part of all software development. If you don't believe this you are likely just starting your career or haven't had to support an application in production with users.  It becomes doubly important in a regulated environment. This is because testing for regulated software serves multiple purposes. There is the usual software product development reasons to consider (i.e. professional integrity and no one wants a bug in production). But it is also because the FDA, in particular, wants to make sure you are performing validation and verification of the software. Verification (Was the product built right?) Validation (Was the right product built?)

While I acknowledge there are a number of useful and important ways to describe software testing techniques, I strive to keep things simple, and understandable, by the whole team. To that end, I split testing into two tracts: Functional and Technical.Functional is about bring business value to the stakeholders - the validation part. On an Agile project we are testing the acceptance criteria of each story. This validates we have realized the benefit to the business and end users. If some thing cannot be tested by an end user, it doesn't exist or have significant value. This is of course untrue. However, to simplify things and keep the team laser focused on only working on tasks that provide business benefit I start with this ideal. All other testing activities are testing Technical requirements. Or, verifying that the software is correct. Some examples of these technical requirements are things like performance criteria, common libraries to the backend and data retention rules. Those who do testing for a living are looking at the screen sideways by now I suspect. I realize that these things must be done correctly or the system will not realize business value to an end user. Both ate needed. That's why the FDA requires proof of verification and validation.

The common flow of testing in an Agile project is to create acceptance criteria for each story then do regression testing after each iteration:

On the other hand, tradition testing documents and verifies each step before it is performed. The goal is for planning to be exhaustive and cover all possible scenarios.

Traditional testing is expensive and often makes validation hard to do. On the other hand, the common Agile testing approach is going to make documenting verification activities difficult. Once you acknowledge both are needed you can find a way that works. The best tools we've found leverage and extend the automated testing you are already doing. Look at the software testing as having two "tracks".
#1 Manual Functional Testing of acceptance criteria. All of the speed and simplicity of user stories. An efficient communication mechanism for stakeholders.
#2 Test everything else via automated tools. Ensures all gets tested. In our case we use unit testing and 100% code coverage.
Here is a graphic of how we can document that we are testing against pre-approved requirements - both functional (validation) and technical (verification).

Next up: Its not what you wear. Its how you wear it.

Agile in Regulated Software - Checklists

Lets be honest: Checklists aren't the most exciting topic to blog about. However, in the context of regulation they become interesting. Everybody loves checklists and hates them at the same time. It's really easy to make them and just as easy to forget to use them. Later on, after the emergency and/or reason they were created has subsided, using the checklists becomes a ceremony - something that must be done rather than a helpful tool. Checklist also may foster an anti-change mentality and allow people to cruise through their jobs without think about them. This is why we all hate them.

Photo By: adesigna

All feelings about checklist aside: If each detail of your project's history is going to be scrutinized, checklists are essential. On a regulated project their are a lot of steps to follow. It's hard to remember each step of each procedure followed. Its really easy to finish delivering a feature then forget to check the software verification report in to your document management system. Once this occurs it looks like you didn't test the feature before checking it in. Worse, you moved on to the next step of features and never turned in the verification report ever. 9 months later an auditor finds it and you have to doubly prove you did the testing and that you didn't miss any other steps someplace else. Nobody wants to be in a position where they are on the defense. Often a missed step means all of the testing and tracking is nullified.

There are number of things you can do to ensure you have good lists and they get used often.

• Make them short - A 10 page checklist is not going to be used properly or use up time at the cost of efficiency. Train your staff. Don't rely on process to get quality work.
• Have less steps - Can you tighten up your process and simplify it?
• Create checklist by role rather than at stage gates - The list will be shorter and highly focused on what matters to the person doing the work.
• Have the team members create their own checklists - They can identify the handful of tasks that are at risk of getting missed. That's your checklist!
• Review checklists often for new procedures and question why each step exists often.

Finally, keep in mind that whatever you put on the checklist becomes part of your project documentaiton history. Thus, you must do every item on the list every time you run through a procedure. Think carefuly before adding things to a checklist.

Next up: Functional Testing vs Technical Testing

Agile in Regulated Software - Have Some Class

The FDA states that a medical device is a product that is used for medical purposes in patients, in diagnosis, therapy, or surgery. As opposed to a pharmaceuticals, who use the body's metabolism, medical devices act mechanically or chemically. The FDA's role in this is to assure the safety and effectiveness of devices. Keep this in mind while going through the process (they are not just to make your life hard).

Photo By: birlewphotography

From a software developer's perspective, there are three classes of medical devices the FDA regulates. You should know what kind of product/device you are making very early on - before you start planning the work. Their are legends of companies that have outsourced development only to find that their partner had yet to take a device to the point where the FDA would audit it. An even worse scenario: they had done the work with an offshore partner who didn't fully understand FDA requirements and couldn't prove traceability nor pass an audit. Whatever cost effectiveness a company offers, make sure its not going to be at the expense of doing the project twice.

Class I
Class I devices are not intended to be used for supporting life. As such, they have the least regulatory controls. Product development efforts lend themselves well to utilizing Agile practices. Do some research before you start development though. About 74% of devices are exempt from pre-market notification in the first place. Those that aren't, might fit into an existing device panel. Often a few pages of documentation will suffice to pass pre-market approval for Class I devices. To find out more go to the FDA's classification database.

Class II
For Class II devices, the FDA recognizes that general commercial quality control and manufacturing practices alone may not be sufficient to assure safety. However, they state that "existing methods" are in place to prove safety. You will still have to prove this to the FDA. Simply put: If you follow a process, and document it, you will be able to prove the device you are creating is safe. Rely heavily on documenting the history of the project well. The project will be characterized by significant documentation and process compared to a "normal" Agile project. Because Agile is quite new in the FDA space, you will probably need a seasoned compliance officer with FDA experience. Plan to get audited.This doesn't mean that utilizing Agile practices is difficult or shouldn't be done. In fact, because so much time is spent on each feature of the software, I would argue that efficiency and managing waste become critical issues. Attacking risk and focus on delivering the highest value features first is key here. The team just can't be sloppy with process or documentation for this type of device.

Class III
Class III devices are new or are used to sustain life. The team can't rely on existing methods to prove to the FDA that the device is safe and labeled correctly. Time to market will play a part, but software development isn't likely to be on the critical path of product development. The raw science and research are likely to take up most of the product lifecycle. Is agile right for R&D? That's a topic better covered in another blog post.

Given the wide range the FDA has in place, the life of your product development team will be greatly affected by the classification of the device you are creating. In my experience, working on Class I and Class II devices often feel like working on a "normal" Agile project - assuming your Agile process incorporates enough controls to document the process itself.

Next Up: Keeping Track with Checklists

Agile In Regulated Software - Methodology

Methodology
"The analysis of the principles of methods, rules, and postulates employed by a discipline"

For software companies these day it seems that its not a hard choice to follow Agile principles. With some practice, or hiring a consultant, you can learn Agile practices and employ them as well. Its an entirely different animal to decide you are going to use Agile practices in a regulated environment though. If you choose this route you must understand that you are on the leading edge of the rest of the industry. Here are some questions you should know the answer to before you can get started:

Photo By: susanrudat

What is Right for My Organization?

Most companies operating in a regulated environment are comfortable utilizing traditional software practices. This is often a waterfall approach. However, it may not be. Most Agile practices are not new - they are what good software organizations have been doing for years. Before you decree "We will be Agile" take a look at what the software organization is doing now. Do an inventory of the practices they are doing compared to something like Kanban or Extreme Programming. Before changing the process for process sake, ask yourself: Are they meeting deadlines set? Are you happy with the products they are creating? Does the overall organization seem happy with the software group?

If the software group isn't delivering then using Agile practices can be a proven tool one can use to solve the problem. That being said, some organizations are extremely resistant to change. Being transparent, working collaboratively, and focuses on delivering software regularly can hard for somebody who has spent their career doing the exact opposite. In this case Agile may not something everyone can embrace easily.

How fast can the organization move?
Eventually a team that embraces Agile principles and practices is going to start moving faster than before. Make sure the rest of the organization understands clearly what is going to be expected of them. This will require open communication and and transparency by your team. There is no need to have a rockstar team that can't move forward because the backend team isn't able to deliver dependent software within your schedule.

Do I know enough about Agile?
My experience is that the most popular Agile templates out there (Scrum, Extreme Programing, Kanban, Lean) don't directly lend themselves to building software in a regulated environment. This means are you going to be bending and breaking the "Agile" rules a bit. Before you can make your own path you must fully understand the "normal" path. Make sure you have significant Agile experience or hire that experience in before you start something difficult and try to expand on it.


Next Up: Have Some Class

Agile In Regulated Software - It can be done!

Photo Credit: LucaDeravignone.com

We have all heard that developing software utilizing Agile principles yields high quality, working software in customers' hands quickly. It is widely believed that utilizing Agile practices leads to better, cheaper software than waterfall methods in most instances. However, those who write software that must be reviewed by the FDA know that, at first look, the FDA regulations run counter to this approach. They lend themselves well to a heavyweight waterfall process with big design upfront and heavyweight documentation. How can you gain the benefit of optimizations such as minimal documentation, a lot of verbal communication, rapid feedback loops, collective code ownership, rapidly pivoting the product based on customer development, reduced waste and increases speed of development?
Can you get the benefits of agile in an FDA regulated environment?  Yes. We are doing it right now. I'm going to be talking about how over the next few weeks.

Next up: A Brief Discussion of Methodology

Product Camp Chicago

Join me at Product Camp Chicago this Saturday April 2, 2011 to see my talk about How to Incorporate Apple like design into your products.  http://bit.ly/eCTVN5

All the things I never thought I would use my iPad for

My family bought me an iPad for fathers day last year.  I have been completely surprised how much I use it professionally and personally.  Here are the ways I have been using it that I never expected:

• The only computer I use at home (sometimes I don't turn on my laptop at work until lunch time either)
• Never taking a laptop on a vacation again
• Teaching my kids the alphabet, numbers, and simple arithmetic (I was shocked how well this worked & how much the kids were into it)
• Watching Netflix
• Letting kids use the iPad on vacation so I can sleep in
• Tracking my finances on Mint (until I ditched Mint - that's for another blog post)
• Writing blog posts (this one included)
• Flipboard!
• Playing casual games (I never used my iPhone or Android phone for this before)
• Actually using Twitter
• Finding creative commons images on Flickr
• Reading articles sent from people at work after hours
• Reading the blogs I follow in Google Reader
• Looking at Pivotal tracker while I'm jumping from team to team at work
• Giving very short presentations to clients and potential customers
• Passing the iPad around when ordering dinner when friends are over - everybody gets what they want and I dont' have to take notes for 20 people
• Demoing Pathfinder Projects to clients and potential clients
• Reviewing specs for user stories
• Writing test cases for user stories
• Teaching my kids about pianos and drums

  

Everyone hates gadgets! Don't make your product a gadget

Photo Credit: Librarian By Day

My mother sent me the following comment in a email recently:

"Us senior citizens don't need anymore gadgets. The tv remote and the garage door remote are about all we can handle."

I find the concept of gadgets interesting. I don't consider myself a gadget person.  However, I own an iPad and Android phone. My brother owns quite a few portable technology devices, but doesn't consider any of them gadgets. My mother owns a digital camera, mobile phone, and iPod. These devices are more complex than a TV remote or garage door opener, but are not gadgets to her. They are useful tools. The line between gadget and useful thing is how useful the owner finds it.  

This is something to keep in mind when designing. If somebody can find clear utility in your product they will spend time learning how to use it. You can increase your customer retention by focusing on clear workflows, usability, and tracking customer behavior. If you can't explain to somebody how using your product will help them sleep better at night they aren't going to even start using it.