UX: Deliberate and Ethical Persuasion

Robert Hoekman Jr, in his book Designing the Obvious lists deliberately and ethically persuading users to perform a specific action as one of the tenants of obvious design. Hoekman’s book gives some examples. One element that he discusses is scarcity. It's a marketing trick as well, to use scarcity to drive sales.

BestBuy does this all the time. They've got computers and TVs on sale, and then they attach, “Limit 1 per customer”, or only, “Limit 5 per store”. Were you planning buying more than one TV? Is there really a scarcity of TVs at BestBuy that they can only have 5 of that particular model at your local store? The answer to both of these questions is usually, “No!” So why do you rush to BestBuy on Saturday morning to buy that TV that you've been thinking about for over 6 months. Because they might run out.

In a similar way, web applications can also create scarcity to influence and persuade a user to perform a certain action. Now this is where Hoekman's point about ethical persuasion comes in. Artifically creating scarcity to drive up demand is bad, and even worse when you're on the web. However if you're working with a product that is actually scarce, why not take advantage of that. For example, airplane seats, hotel rooms and concert tickets, these are all physical things that will run out.

Today I found myself admiring Booking.com's persuasive techniques to get me to book a hotel for Google I/O 2012. The site used OAuth authentication which allowed me to cross one hurdle, registration. I didn't need to create an account, as my Google account got me in the door. Everywhere the price was listed, was a green reassuring text that said, "FREE CANCELLATION". That reduces any barrier that I might have to making a booking. Then they used metrics that had at their disposal to influence me to book quickly. By showing me how many people were currently looking at that particular hotel on their site, I knew how many people I was competing with. All of a sudden, it was no longer a solitary purchase behind a computer desk, I had to grab that hotel before the guy from Munich took it. Then there was a notice of when the last booking happened at that hotel, that was mere minutes ago. Then as the text turned red, to draw my eye toward there only being 1 room left at that price, and competing with several other people, I just booked the room. If after reading countless reviews after, I wanted to cancel, I could always come back to Booking.com and cancel, but they didn't let me get away.

I left thinking about their user interface, and how they managed to get me to make a booking at a decent hotel in record time. I didn't labor over pages of TripAdvisor reviews before I made the booking. I stayed entirely within the booking.com website. If anyone knows me, that's entirely unlike me. I usually research something to death. But thanks to persuasive design, I saved time, and money by booking my hotel for Google I/O 2012 early. Now all I need to do is get tickets for the conference...

In case you're wondering...

Google I/O 2012 is held at the Moscone Center in San Francisco from June 27-29, 2012. Registration opens at 7am PST on March 27, 2012. Unlike most conferences, Google's development conference sold out last year in 59mins. So people like me are booking hotels before they are actually registered for the conference. They increased the cost of the conference this year to $900. Hopefully that'll be enough to get the moochers out and allow developers to attend. There has been a ridiculous number of non-developers who have attended their developers conferences in the past, only for the free stuff.

And yes, I did look up my hotel after at TripAdvisor for some peace of mind...

The Case for Source Code Backup - Desktop (Part 1)

As a software engineer I tend to end up with many lines of source code that change over time, and projects that I want to preserve and update. I've tried different methods of keeping everything in sync. Everyone starts up with strategies that they swear by until they fail them. I'm going to illustrate why I needed source code hosting, and the lessons I learned along the way. This post deals strictly with backups on the desktop in a pre-2000 era. This post is a 3-part series on backup and version control. For modern desktop backup practices, skip this post and go directly to the last post in the series (which I haven't published as yet).

1987: 5¼" floppies and a TRS-80

In my defense, I wasn't yet ten years old at this time, but I was busy writing code on my very own Tandy TRS-80 personal computer. I know all the TRS-80 fans are probably perking up by now. After writing every program in the Extended Color Basic manual that was included with the ‘Coco’ I moved on to trying out some of my own programs. At the time I didn't know anyone else with a Tandy computer, so all my programs were written to a stack of 5¼" floppies that I had with the computer.

As anybody who remembered those times can tell you, these disks proved extremely unreliable. So much so, that when I tried to read them several years later, all my code was lost. Good for me, I'm actually grateful my programs from my early years are lost forever. They were some horrendous games with flashing block graphics and awful musical tones. What did I learn from this, next time I needed to write code, I should use some reliable storage medium.

1994: The stack of 3½" disks

Fast forward to my O'Level Computer Science project in high school, I'd now learned the basics of computer programming, and I could program circles around almost everyone in my school, except for 2 computer science teachers. There were a few of us in this class who were grasping the technology at the rapid pace it was being developed, and the slow pace we could grab on to it in Trinidad at the time. Buy now the 5¼" floppies were unceremoniously replaced with high capacity 3½" floppies. I actually don't know why we called them floppies still, as these were small disks in a hard plastic case. A disk could hold 1.44MB of data, fit easily in a shirt pocket, and at the time that was a lot of code to be walking around with.

For O'Level Computer Studies, I was required to complete a year project to design and implement a software application in the language we were learning at the time. Given a full year, I had completed my final year project shortly after Christmas, and I had the working BASIC program on my floppy disk. I didn't own my own personal computer at the time, so the only copy of my program resided on my 3½" floppy disk. One of my good friends at the time had also completed his final year project after Christmas, and was eager to show off his coding skills. He had written a program that would read another software program and count the total number of lines in the program.  As part of the adventurous group, I gave him my diskette with the only full working copy of my program to count the number of lines in my program. Strangely enough when he ran it on my program, the result was: 0. For the initiated, there was a problem in the code between LINEIN and LINEOUT. When we opened up my program to see what was wrong, there was a strange number, which we later presumed to be the number of lines of code in my program. Unfortunately, that was now all that was left of my program.

I could now, either restart my program from a backup diskette, made from over a month ago, or use the adrenaline of everything lost to start my project over from scratch.  Lesson learned, I was now creating 3 copies of the program every time I saved it. I went on to create a different project and win the award for best O'Level Computer Studies project for 1994, something I went on to do again at Advanced Levels in 1996, albeit without the drama of losing my code again.  I also learned to never let people experiment on my code again.

1999: How my hard drive failed me

So I learned my lesson about removable storage. Now fast-forward to my final year Computer Engineering project in 1999. I was writing a Java Servlet-based course management program.  Again, this was now my year-long Electrical & Computer Engineering project. I had gone through most of the year making slow but steady progress toward completing the application from design through implementation. I was also steadily documenting the application as I went along, so my design documentation was in-sync with my development.

With one month left to go before submission of the project, the impossible happened.  My hard drive crashed. This was the first hard drive failure that I'd ever had, and the crash took with it my final year undergraduate project, source code and documentation.  8 months of work and research was now gone.  University isn't high school, you can't tell you teacher that your hard drive crashed.  So I started over a brand new project the very next day with approval from my supervisor, who I'm sure was ready to write me off as a lost cause. When it was all over, I also ended up winning the prize that year for best final year project in Electrical & Computer Engineering at the University for 2000. Although my loss of data had an incredible ending, I'm not encouraging anyone to follow suit. I now have 4 hard drives in my desktop computer, I do RAID and weekly backups which have saved me from the 6 hard disk failures I've had since. Redundancy has been a great thing.

More to come

There are more lessons that I learned, and I'm setting the stage for some best practices here, but I'm also taking you through my own journey as I got to these best practices. In the next post in this series I will discuss networks and server-based backups.

Prototyping a Business Idea 1

I've read a lot online about quickly testing a market to see if there is any demand for your service. So I decided to put it into practice and walk through the process myself. As promised I'll be documenting every personal project that I start from now on. Continue reading as I show how I went about prototyping a business to create usability reports in one evening.

Step 1: What am I good at?

Before I can begin offering any service, I need to identify the things I'm good at and passionate about. I quickly made a list over the weekend.

• Java web application programming
• Android apps
• Usable website design
• Application of technology to solve social problems
• Logo designs

My list can probably go on for pages, but that was enough to get me started. In this section I'm following the advice of Noah Kagan and the crew at AppSumo. I'm going after low hanging fruit. So ‘Usable website design’ seemed to me like it was pretty low on my tree. After all I've been critiquing websites on forums for free, for over a decade, and building them since 1996. I confess that back in 1996 I was really just building a bunch of local sites as I didn't yet have Internet access.

I'm picking a trivial example first, and it might become something, but it's so easy I can do it for other things on my list as well. Actually, you know what, I'll go through this process for as many items on the list as I can. Some fruit are higher than others, for example setting up and running a Java web application will probably take me a little longer, but it'll be worth it.

Step 2: Determine the market size (approx)

There are many ways to do this, and you could really do your market research and spend days and months testing the market. Or, you can use a shortcut and see how many people are searching for your service online to get a rough estimate of the market size. Again, this is all about rough approximations. I want to show you how I did all of this on Sunday evening and got my first order by midnight on Sunday. So I just used the  Google Keyword Search Tool, and that gave me ideas on the keywords that my service should contain and the number of users who are looking for that service.

Step 3: Idea Validation

Since I'm just trying to figure out if I want to do this at all, I decided to try this on the popular service, Fiverr. Fiverr has a niche marketplace for brief usability reports, and design analysis. Users of Fiverr are mostly people who are trying out new things and want to save a lot of money. You might be thinking, “Fiverr? Don't you get paid just $5 per gig?” Actually I'll get paid $4 per gig, but this project isn't about money, it's about validating the idea, testing the market size and building a reputation and refining my product offering.

I checked how many people on Fiverr were offering this service, and how many of them looked like they were any good. I think I found about 50 people who were offering design and usability, and about 2 of them were worth their salt. So my competition on Fiverr is basically 2 people.  At this point, you're probably still asking yourself, “$5 dude?” Yes, my goal is to help make a more beautiful web, so by making this more affordable to the average person, I'll get a lot more people trying out my service, and hopefully save the Internet from a couple dozen horrendous websites in the process. Actually if people won't buy this service at $5, I see no reason in scaling it up to a bigger offering.

So I opened by LibreOffice and started writing my copy for my service offering. Fiverr gives you 120 characters for the gig name, and 450 characters for the description. I had to be pretty careful with my copy. With a couple minutes of tuning, and hitting the keywords I found in Step 2, I created my gig. You'd be surprised how far ahead of the pack you can be by just doing some simple spell checking.  I decided I wanted to catch people at the design and the implementation stage to help them with usability. So I created split the gigs into two separate gigs, one for mockups and another for website designs.

Then I spent a little effort creating an appropriate marketing image for each of my Fiverr gigs, which adequately convey what the service is about. Part of my marketing, is using a limited time-offer, which is really true, because I don't intend to offer $5 website reviews forever, and I want a cut-off date after which I can evaluate my service offering.

I then posted my website usability report gig at 11:46pm and went to sleep. By 12:06am, I had my first client. I'll update in a month how this process goes.

Step 4: Do the work

Just because Fiverr is cheap doesn't mean I have to offer a cheap product. However for $5, I can't setup a usability lab, and pay for testers and do A/B testing. What I have to offer is my 16 years of experience designing websites, and knowledge gained from many books, and reviewing many other sites. I've got some usability engineering under my belt and the words of Jakob Nielsen burned into my brain. I can offer a pretty basic review for $5, but my years of knowledge guarantee that it will be helpful to the end-user in my niche market.

Update March 5, 2012. By now I've had one client who needed a rushed report for a website they were having a contractor build for them. It has helped me refine my market to people who are outsourcing websites. The client wanted a professional second opinion on the mockup of the site that the contractors were presenting before they even built it. My report saved her hundreds of dollars upfront, and helped her correct small mistakes at the early stage.

The best part about doing the work, is that since it is low-hanging fruit, I already know how to do it. Actually I can do it in my sleep.

Step 5: Refine and find the right market

Fiverr isn't a long-term niche market. Although there is a niche among people who can only pay $5 for website usability scorecards, there isn't long-term business potential here for me. So while I'm refining a product offering and building a reputation on Fiverr, I have to go back to the drawing board and consider niche markets where people would actually pay for website usability scorecards and reports. In other words I have to tap into a market that sees the value in my product offering.

Conclusion

I'll have to wait 'till the end of March to see how this one plays out. I'll probably tweak the service offering a bit to grab more market share. In the mean time, while I'm waiting I can start prototyping other ideas from my tree. The higher up the tree the fruit lies, the less competition I'm bound to have, but also the longer it will take me to get up and running with a prototype.