Digital clucking

A goal is a dream with a deadline

2012-02-12T16:32:00.002-05:00

A goal is a dream with a deadline
— Napoleon Hill (wikiquote)

This quote has almost become a cliche and many people have reused it in one way or another. You mostly see it in the form that Dr. Phil uses: A goal without a deadline is just a dream.

This week marks the 1 year anniversary where my long standing dream of being healthier became a goal. About a year ago, I stood in front of a bunch of my colleagues in a Toastmasters meeting and I stated, out loud, that I would loose 50 lbs before July 1st.

Goals are tricky, once you commit to a deadline and turn your dreams into goals, you expose yourself to missing the mark. And miss the mark you will. When I reached July and had met my goal. I re-set my goalpost. I wanted to reach 200 lbs by Valentine's day. And it is clear now that I won't meet that goal. I made good progress but I missed my mark.

It turns-out that missing your mark ain't so bad. I think that once you start missing your objectives, you become more comfortable setting them and you get more out of your goals. You learn a lot aout yourself and about the goal you're trying to achieve. Achieving a goal is great and missing the goal kinda sucks. But it is much better than not setting one.

That being said, no one wants to miss goal after goal. So, another good thing about setting goals is that it keeps you honest and realistic. Setting a goal is a commitment to yourself and being honest about it forces you to gauge your ability to achieve it before you start. You can set stretch goals but you can only stretch so much.

So it is time to move my goalpost again. To reach a healthy weight for my height and age, I have to be just under the 190 lbs mark. So, my new goal is to reach that weight by July 1st.

P.S. Sorry for the personal, self-congratulatory, somewhat off-topic post. Let me bring it back on topic a little. This also applies to products, teams, and workplaces. Grand visions without deadlines are just wishful thinking. But we all knew that right?

Is there a good privacy model for applications

2012-02-11T12:32:00.001-05:00

This week, for those that don't know, Path's CEO had to issue an apology to its user and update their app and now Instagram updated their app to avoid the same PR problem. Basically, what both apps apparently did was to automatically collect users from your address book to improve your social experience.

Some people will argue that this kind of thing cannot happen on Android phones. When you install an application from the Android market, there is a very detailed disclosure of what pieces of your device each application is allowed to touch. As a user, you preemptively accept to give the application access to your data before you make your purchase.

For example, TouchNote Postcards (I picked something from the featured applications) requires full access to the address book. The Android market gives you this dire warning:

READ CONTACT DATA
Allows an application to read all of the contact (address) data stored on your device. Malicious applications can use this to send your data to other people.

WRITE CONTACT DATA
Allows an application to modify the contact (address) data stored on your device. Malicious applications can use this to erase or modify your contact data.

Once you install this, you're done. You agreed; They own your contact data. The application maker can always state that they told you so.

The Apple model is different. It is pretty much an all-or-nothing thing. There is no fine grained access-control built-in to the App store. The only control they give the user happens after you download and install the application and is mostly related to notifications.

The interesting thing is that this week, Apple and its users are benefiting from the work of hackers that desire to understand what happens with their device. They examine the application's traffic and ultimately figure out what it does and can disclose it to the public. The threat of a PR nightmare and the potential devaluation of their company is the only thing that could potentially keep application makers in check.

The Apple model is clearly riskier. No doubt about that. Any application can just rummage through your personal data and send it over. You would only know about it after the fact if someone bothered to investigate.

But I really wonder what the effectiveness of the Android model actually is? I suspect that for most users, the Android model fails to give the intended benefit. I fear that most users become numb to the constant privacy warnings. No matter how dire. Specifically because they can't even try the app if they don't agree to give away the permissions. The privacy warning is becoming the EULA that we've all trained ourselves to just click through. In the end, the only person that it protects is the application maker.

[Edit]
Marco Arment, the developer of Instapaper wrote about his thoughts on the IOS address book API and its security model.

Refactoring the user experience

2012-01-09T08:55:00.000-05:00

I'm starting a new project in the new year. I'm really excited about it. I can't talk about any specifics but it is a long term project in which me and my colleagues are working to integrate two large entreprise applications with disparate user experiences.

From my previous life as a programmer, I know that integrating two disparate applications is really difficult. However, I have a good idea of how I'd go about it. Refactoring here is the tool of choice. Refactoring is a challenging and rewarding practice that, when done right, improves the software significantly and safely. So naturally, I tried to find the equivalent on the user experience side.

Asking Google gave me a couple of articles. Most of which were making the case for it but none discussed what it would really look like. The more I thought about it, the more I wondered if you can refactor the user experience. By definition, code refactoring is "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior".

Code refactoring is a technique that works because it is based on a strict set of rules. For example:

Test profusely
Think globally, act locally
You can't change external behaviour
Don't add new functionality while refactoring
Don't repeat yourself (don't copy-paste, always cut-paste)
and much more...

What would refactoring the user experience look like? What would the rules be?

Off the top of my head, here's a first kick at possible rules:

Test profusely (before and after refactoring)
Set a big picture goal. Always move towards that goal with each change
You can't change the user's mental model (unless testing tells you it was wrong before)
Adding new features is not refactoring.
Jump at the opportunity to remove/hide/displace an unused feature when possible

So maybe it is possible to refactor a user experience. If it is, maybe there is a set of reusable rules that can be written down in a recipe book. I'll keep my eyes opened for things that I can see and my ears opened for any suggestions you might have.

The war on general purpose computing

2012-01-04T21:21:00.001-05:00

Today, many people tweeted about Cory Doctorow's keynote at the CCC. Every one that uses the internet on a daily basis should spend the 50 minutes to listen to it. It is smart and enlightened.

In this talk, he asserts that the fight against dumb copyright regulation is merely a battle in the war to protect the very nature of general purpose computing devices. And by extension, the war to save the internet.

The assertion is based on the fact that most technology-based solutions to protect digital assets imply creating locked computing platforms. Platforms where the user is not in control or aware of the software that runs on the computer. In essence trying to create a computing device that is specialized. The natural extension of this is that companies (and governments) won't have any incentive to produce/allow general purpose computers.

I agree with the argument. It is a really dangerous thing to not have any control over the software that runs on your computer. It has implications on many of your freedoms and it creates many potentials for abuse by corporations and governments.

The problem that I am seeing there is when he extends his argument to software that is running on the computer in your hearing aid or in your car. The idea of complete knowledge and freedom on what happens on your own devices is really appealing. But, aside from the people at that conference, who has time and knowledge to deal with that? Who will actively monitor and control software that runs on the hundreds of devices that they own?

Some devices, even if they are at heart a general purpose computer, need to be trusted implicitly. Accepting a trusted computing platform in some circumstances is one of those necessary compromises that we need to make in our modern lives.

There is only one alternative solution that I can see to this problem: Force (through legislation) the software that runs in our devices to be open-sourced. And then, you can trust any 3rd party you choose to validate the software that runs your devices or even do it yourself if you're so inclined.

But I wouldn't hold my breath for that.

Back to School

2011-12-16T15:48:00.000-05:00

There is a bunch of us at Macadamian that are volunteering as mentors for a small group of High-School students that are interested in software product development. The kids picked a small project to work on and we're helping them to turn it into a product.

Of course, the main interest of the kids is technology and actual coding but, as part of the mentoring, we're also helping them with some of the things that surround development. For example, we set them up on GitHub and thought them the basics of source control.

Yesterday, I had the privilege of meeting them for the first time and, as one of those non-coding activities, we ran a bit of a design workshop where we spent time on the whiteboard wireframing the UI for a particular user story for their application.

It was really cool to break down the specific story into the various bits and to sketch a UI with them. We got them to get their first ideas on the board and then, challenged their design using the personas that they had defined in previous weeks. By asking questions like "Would Tony really know what to pick here?" they were able to break down their assumptions (which were based on the physical model of the data) and redesign a UI which was more respectful of the user's mental model and their context of use.

At one point during the session, one of the kids turned to me and asked: "Do you really do this on projects?". I must have had this stupid grin on my face when I answered yes. The voice in the back of my head was saying: "Can you believe that I get paid to do this?".

By the end of the session, we had a complete workflow documented that they will be able to go out and code this week. And the kids had a glimpse of one of the non-coding parts of what turns a piece of software into a product.

I'm really excited to see how it turns out.

The compost in my life

2011-09-21T10:08:00.000-04:00

Sometimes I feel like the only thing that comes out as a by-product of my life is stuff. There is a significant amount of stuff that I get rid every week with the garbage. But I'm not talking about that. I'm talking about the stuff that accumulates.

In my home, I have an office. I set it up when I bought the house and at a time when, to do any serious work with a computer, you needed one of those large tower PCs. Nowadays, I do all my work on my laptop or on my iPad so I don't need an office. It has become a repository for my unused stuff. The compost that accumulates in my life.

The picture above is from a shelf in my office. This shelf is a great examplar of stuff I keep all around my house. Let's see if the stuff can be categorized.

Things that you just don't throw away: The "non-designers design book" (throwing books away is a crime isn't it?), Macadamian baseball cap

Things that have a sentimental value: The stuffed Smurf, Starbucks cup

Things that are cute or beautiful or fun: The little cat rock statue, Peter (family guy that says funny things when you squeeze it)

Things that belong to other people that just happen to be in my possession: The bottle of rum, the plastic pitcher, "les laboratories Crete" book

Things that are part of projects that never finished or even started: Bonsai tree kit, large bag of silica gel packets

Things that are obsolete or should be digital: Old compact flash cards, replacement batteries for a camera I don't use anymore, paper printout for the rules of a board game, software retail boxes, business cards

Tools: Air pressure gauge, paintbrushes, pens, 9v battery, tie-wrap, little hard-disk screw, cables, plugs, adaptors, lens cleaning cloth, the various containers to organize the stuff

After making an inventory of the content of the shelf, I realize that (aside from the little pile of change) most of the stuff in there is stuff that I don't use often or at all. Yet I keep it. Stuff accumulates, a perfect incarnation of the principle of entropy.

How to deal with that stuff? Is it different depending on the type of stuff?

And putting it away is not the answer here. Actually, putting it away is part of the problem. It is not about cleanliness, it's about the stuff itself.

Anyone has brilliant ideas here? How do you deal with your stuff?

Information architecture is not about your database

2011-09-08T09:21:00.000-04:00

I've recently started a new project with a new customer. It is a rather large project to redesign an old process-control application. I started by working with them on defining a design intent for the project and then I gave them an initial framework to define an information architecture.

And then I got an odd silence in email replies. And ultimately, I got a phone call with this question: Why do you need to talk about our database?

So I found myself in a position to explain information architecture on the spot.

I'm not trained as an information architect and there are plenty of better answers online but here's my ad-hoc, 5 minute explanation of information architecture:

Most systems that we get to design and work with today are made-up of a big pile of information. Not unlike the pile of lego blocks in this picture. To be able to build an information system to warehouse and manipulate these blocks, systems architects will organize the data given specific criteria. For example, they might organize them based on their size. Or the number of studs on each block.

This is why my customer had this reaction about his database.

Information architecture, on the other hand, is more concerned with how the user of the system organizes this information in their head. If I were to dump a box of random legos on your desk and asked you to organize them, how would you do it? You can organize them by their size, color, function or any of a dozen potential criteria.

This is a difficult task and it shouldn't be done in a vacuum. It needs to be done with the participation of your users. The main reason for this is that it is likely that you wouldn't organize the blocks the same way than they would. And it gets better: There is a good chance that different users of your system view the data from different angles and require different ways to organize it.

The benefit of going through this exercise is to discover the organization scheme that better suits your target user and the task that they are trying to accomplish. If you succeed in matching your user's mental model and design an interface that respects it, you will end-up with a system that makes more sense to them. A system that will feel more intuitive.

There's a lot more to information architecture than sorting blocks. But as a first step, using IA techniques to organize the information in your system is a great way to start making sense of your data. And making sense of your data is a good first step to make your application more intuitive to your users.

Giving the customer good value out of a concept design

2011-08-30T09:43:00.010-04:00

Often, the first design engagement I get with a customer comes in the form of a concept design. When this happens with a first-time customer, they are typically unsure about the value of design (especially an outside designer) and don't want to spend too much money.

Concept design is hard to scope but it usually is made of: Some soft of requirements/task analysis workshop, some high-level wireframe creation, some form of user feedback gathering and one or two visual design concepts. The bigest factor to limit the scope of the engagement is usually the budget.

This means that engaging into a concept design project puts the designer in a double-jeopardy situation. The customer doesn't know what to expect (they were probably convinced by sales that designers are magical beings made of rainbows and chocolate cake) and the end of the project will be very arbitrary.

Defining scope and managing expectations is hard to do but this is not what I want to discuss here. I want to talk about another other challenge with concept design: A concept design is not enough to start implementing.

However, the customer often has to jump straight into implementation armed with only a high-level concept. So how do you give them more value out of the concept you created?

Explain your information hierarchy

One thing that feels like black magic to an outsider is how you organized the information in the concept. Explain your information hierarchy, the kinds of objects you put in what buckets. Refer to your sources (maybe you did card-sorting with some users). Give examples of features/data that you already laid-out in that hierarchy and maybe pick one that you haven't gotten to yet and show how you would categorize it.

Another thing that can help is to pick a problem that you have solved in the concept that didn't fit so neatly in the information hierarchy you had picked. Or maybe it forced you to stretch it a little. Describe that and how the problem was solved.

List-out your next steps

So you've reached the end of your budget but there's more work to do. Be nice and lay-out the remaining work for your customer. They'll have to do it in one way or another. Take the remainder of the work that you would see and then, make a quick list of how you would proceed if the project were to continue.

This doesn't need to be complete. It probably can't be anyway. But the intent there is to give them a starting point to take your concept and turn it into a product. The scary thing is knowing where to start. Tell them what you would do.

Give some guidance

Presumably, the customer came to you because you know what you're doing. This means that there's a lot of little decisions that you made while working on the concept that are only visible through the delivered artifacts.

Take some time to document some basic guidelines that you used in the concept. You can start from some basic all-purpose design guidelines and make it relevant to their product. Give an example of how it was applied in the context. There might also be decisions that you made regarding their UI like how you used modals or how you notify the user of errors. Take the time to turn those into guidelines.

Offer help

The project might be over for you but the work is just starting for your customer. They might not be in a position to continue hiring you to finish the work but they might be able to use your help in smaller doses.

Propose an arrangement where they can schedule design reviews with you or maybe a demo of their product as they progress through the implementation. Be creative about it. They might be able to do a better good job of taking your concept forward if you are there to help them when they hit a difficult problem along the way.

The real value of a concept

Customers see design artifacts like comps or wireframes as the product of a design. But, at the concept design stage, the real value is the high-level problem solving. If you are just handing your customer a slidedeck with your wireframes, they might be missing out.

A concept design is useless if it can't be turned into a product. At one point, you have to let go and accept that you can't do all the work. It is your job to make sure that your customer is well equipped to take it all the way there once you leave.

Why I prefer high-fidelity wireframes

2011-07-22T13:25:00.004-04:00

Ever since I started my new path as an interaction designer, the process has always been described the same way to me: concept/sketch -> wireframe -> visual design. All steps resulting in increasing levels of visual fidelity.

I'm not a visual designer by any stretch of the imagination so my work has always been situated in the first two steps: sketching and wireframing.

I love sketching and I think it is essential. I actually prefer sketching by hand and my sketches are typically very messy. I'm a doodler and this is typically how I get unstuck when I am faced with a hard problem.

But a significant portion of my time is spent wireframing. And I have been working with the assumption that wireframes have to be low fidelity. I've hated that assumption from the beginning because I find low-fidelity wireframes to be very limiting as a communication tool.

The low-fidelity wireframes reside in the uncanny valley of interaction design. Customers will gladly comment a concept sketch. And they will surely comment a fully rendered visual design. But somehow, I have had many customers that are blind to a low-fidelity wireframe. They'll just wave it by, blindly approving it just to come back with a metric-boatload of comments once it gets fully rendered or implemented. Mostly comments about things that were there in the wireframe; Just invisible to them.

I was reading this post: 4 things no one told me about high fidelity wireframes and I was filled with a great sense of relief: I'm not alone to prefer higher-fidelity wireframes.

Technical people are people too

2011-07-19T12:59:00.002-04:00

TL;DR: It is not because your product is targeted at technical users that it won't benefit from proper user experience design.

Recently, I've been tasked to work on the redesign of many products that are targeted at technical users. Tools like network management or backup software. The initial engagement with those customers is almost always the same. They come to us because they have a competitor that has a “more modern” or better looking product. And they want to remain competitive.

However, the fresh coat of paint and new curtains approach is rarely the most effective approach to beat your competitors. Let's say your company has been putting out a product targeted at technical users. You've been doing it for years and you carved-out part of the market. Now, you're trying to distinguish yourself from your competition.

In any other case, improving the user experience would be a perfect way to get a leg-up on your competition. But your users are technical. They don't care for fancy user interfaces. They have spent time to learn your tool and are happy manually editing .conf files and working around the quirks of your software.

But are they really?

Although they are capable of figuring-out complicated technical products, technical users are just like normal users in many ways:

They have other things to do than using your product. Typically, using your product is only one of the many things that they are responsible for. They might have chosen your product because it is reliable and useful. But believe me when I say that they'd use less of it if they could.

By allowing them to perform their tasks more efficiently, you will delight your technical users to the point of evangelism.

They view your product using completely different goggles than you do. When you look at your own product, you see the way it is built inside. You see code and database tables and network connections. This often means that your user interface reflects this physical model or how your product works internally. Users, even technical users, see your product from their own angle. They see their network equipment and their servers and their offices and equipment cabinets. In other words, they already have a mental model of what your product should be doing.

If the Physical model you propose through your UI doesn't match the mental model that they expect, it will create extra work for them and increase learning cost for even the most technical of users.

How do we fix that?

Interestingly, the fact that you are targeting a very specific group of users is a good thing. The first step in the process is to validate assumptions about your product. Go to the users and observe how they use the product. Specifically:

What are they actually using it for? (it might not be what you built it for)
What workarounds have they built around your product's limitations? (sometimes, technical users maintain whole suites of scripts and tools to do that)
What specific tasks do then need to get done often or in emergency situations

Armed with this information, you can enter an incremental cycle of design, test, build, retest until you are successful at delighting those technical users.

When the coat of paint won't do

Strangely enough, when I start work on a product with highly technical users, the request is almost always about making it prettier. However, especially with technical users, making it look good is probably the least cost-effective way to improve their experience. Technical users usually care about getting things done fast and accurately. They often can disregard an ugly UI if they can spend less time using it and more time getting other things done.

Unexpected behavior from customer

2011-05-13T14:36:00.001-04:00

(reposting this because Blogger ate it)

Today, I had a strange experience in a customer meeting. This meeting was part of a large iPad project to offer mobile features to the users of an existing desktop application. The purpose of the meeting was to review the remaining work to be done and identify the things that were more likely to add risk to the timeline. The remaining effort that could be spent on the project to reach the deadline was around 600 man-days and the estimate for the remaining work hovered dangerously close to that.

We were taking the time to identify individual feature details to identify the ones that might push us over the limit.

Suddenly, someone on the customer side did something completely unexpected. He suggested that we completely drop one of the major features. Not a small task or detail. Something big; Something that demos really well. Something that already exists in their desktop application. Something that we didn't expect them to have any flexibility about.

Once we got over the initial shock of the idea, he proceeded to explain why. Although this was an important feature to their users, this particular feature would mostly be useful when their user was comfortably sitting at their desk. Not while they were walking making their rounds. (yes, it's for doctors)

This might be a decision that they will have a hard time explaining to their marketing department. However, what they get in exchange for that feature, is a project with less risk and more effort being put on the features that have more value to the end user.

Another thing that this gives them is a tremendous amount of leadership. The entire team, from our side (the vendor) to their side (the customer) can see by example what it is to do the right thing. It empowers the rest of the team to do what is right instead of doing what they are told.

I was pleasantly surprised about this. Not because it meant that we would have less work to do. But because it meant that i was working with people for which the first priority is to do the work that has the most value for the end-user. And that they were willing to course correct if this was the best thing to do.

Building a next gen system: How not to forget anything?

2011-05-05T14:18:00.006-04:00

Recently, there was an discussion thread at the office that started with this question: Do you know any tool or process that could help this customer?

We have a customer that wants to re-architect and evolve a large undocumented software written in C++.

They have very little automated tests if any, and the system is not designed to make it easy to add the unit tests that would be needed.

They are wondering how they could ensure no feature is lost while reworking the system, and would like to have some sort of checklist to ensure that all functionality was maintained, and be able to know which test case need to be executed when a part of the code changes.

I thought it was interesting so I decided to share my answer here:

Buy them this book and this book and give them a pat on the ass and wish them luck.

Joking aside, if it is as bad as it sounds, doing this right will cost them almost as much as rewriting. But it is better than re-writing because they will get a stable, tested system out of this exercise. They have to be aware of this starting off. And they also have to resist the temptation to do a rewrite. At least, they have to consider a rewrite only as a last-ditch option.

I don't know of a systematic process that I can point to that would help them get out of this predicament.

I am reminded of a previous life where we inherited a large mess of C# and ASP.Net code. We needed to stabilize the product, make it more testable and easier to modify.

The process we applied was as such:

Identify a good candidate subsystem to isolate
Refactor connections into that subsystem from the rest of the app to use a stable interface. Without changing implementation. Refactor typically means no change in functionality. Also don't forget that connections aren't always in code; Access to a database table is a connection that might need to be isolated
Write Unit tests against that stable interface
Goto 1

If you do this enough times, and start breaking subsystems into smaller units, you will end-up with something that will be much manageable. It becomes ravioli code instead of spaghetti code.

Notice that, in this process, there is as little actual rewriting as possible. First part of the strategy is to break the big mess into smaller messes.

To help in identifying pieces that can be broken off, you can use a tool like CPP Depend that will parse your code and identify pieces that depend on each other. You can also use that tool to validate that, once you've broken off a piece, there isn't still a stray code dependency between pieces.

I also think that this is probably the best strategy if the system needs remain live, and to continue being maintained and evolved as this happens. Once a piece gets isolated, the system goes back to production with its new structure.

One thing that we learned from doing this before is that, when a subsystem is being split, everyone in the team has to understand that split before it occurs. Otherwise, the part of the team that is still adding features will work against the guys that are trying to do the refactoring.

Once a subsystem is sufficiently small and has a good unit test suite, you can then start entertaining the idea of a rewrite, with fewer risk.

Doing this is hard and requires experience and discipline. It also produces few improvements that are visible to anyone else but the programmers. There is a risk that people in management might wonder why there are no new features that get implemented for all that work.

This is paying the debt. Not buying more stuff.

If management doesn't understand that upfront; Some people will get impatient, other people might lose their jobs.

Simple doesn't imply intuitive

2010-12-15T09:00:00.001-05:00

Today, we had a good snowfall and I spent some quality time with my shovel after work. As I was working on my driveway, I noticed that my neighbour was performing the time-honored ritual of teaching his teenage son how to use the snowblower.

As I was pushing snow I started to think about the user interface for the snowblower. Turns-out that a snowblower is a pretty simple machine. There are basically 5 functions:

Start throwing snow (auger control)
Start moving (drive clutch)
Direct the flow of snow (chute direction)
Control the speed of the engine (throttle)
Control the direction of movement (forward, backward)

Each of the functions is controlled by a lever and the user feedback is pretty direct. Push the lever; Machine reacts. Like I said, a pretty simple machine.

However, I'd be hard pressed to call this UI intuitive. I don't think that someone, being put in front of a snowblower for the first time, can intuit how it works without being taught or without reading the manual. I find it interesting that, when designing User Interfaces for software, we often assume that something intuitive has to be so obvious that it is self explanatory.

So, simple doesn't always imply intuitive.

Well, maybe. If you look at the definition of the word intuitive in the dictionary, it reads: readily learned or understood.

With this new definition, the snowblower's UI becomes intuitive. It does require that my neighbour's boy learn how it works but its simplicity makes it easy for the him to learn and understand how the machine reacts to his actions.

A source of friction between designers and developers

2010-12-10T09:00:00.005-05:00

This week, I went to Winnipeg for the penultimate visit in the TechDays Canada tour. Over the past few weeks, me and my colleague Tony have had the opportunity to talk to a large number of people about the (sometimes painful) interactions between designers and developers working on software projects. This picture is an actual slide in our deck, usually gets people laughing

During the talk, we go on about tools, tricks and techniques to help alleviate this pain and to empower the designers in your team by making them an active part of your product development team. One of the things that we say in the talk is that it is not a problem with the people, it is a problem with the fact that their job (designers and developers) are fundamentally different. It forces each of them to approach the project from completely different angles. In other words: Don't hate the player, hate the game.

This is even more obvious when you consider how both groups react when a change has to be made to an application.

When a designer has to make a change to the design of a specific feature in an application; He will make the change and then, start considering the impact of that change on the rest of the application. To him, the important thing is that the application retains its consistency throughout the change and that the application be globally well designed. To a designer, change is global.

When a developer has to make a change to the implementation of a feature in an application; She will use techniques like layering, decoupling and encapsulation to limit the effect of the change on the rest of the application. To a developer, change is something that has to be controlled, a good change is a local change.

With these two positions that are at opposing ends of the same axis, no wonder that sometimes, designers get on developers nerves, and vice versa.

User-Centered Agile Software Development

2010-12-09T10:55:00.003-05:00

I just finished reading User-Centered Agile Methods. It is a short and well written book that attempts to paint an accurate picture of how user experience design can fit in with current Agile development processes.

It has a whole bunch of useful nuggets of information (for both UXers and developers). However, the most useful piece to me is the really cogent description of Sprint 0 (Inception sprint, Phase 0) .

Sprint 0 is one of the most debated aspects of integrating UX into the Agile development cycle. Many Agile experts state that Sprint 0 is a violation of the basic principles of Agile. While others say that it is just silly to start a project without a bit of planning and architecture.

People that debate against Sprint 0 say that it is just one way to sneak Big Design Up Front (BDUF) into agile development. The point that the book makes is that it isn't BDUF, It is Big Picture Up Front.

In the book, he explains:

From the agile perspective, the world changes. Requirements change. Management goals change. Therefore, if you spend months working on a design, it is highly likely that most of that design will never be implemented as envisioned.

But he counters:

It has been the experience of the developers that every time users are shown a system that implements the requirements the developers were given, the users ask for something different. This makes it look like the requirements have changed. It is not apparent that the users were unable to articulate their real needs in the first place.

Putting a UX designer on your team to be the voice of the user and using a sprint 0 to draw up the big picture will do a much better job at gathering useful requirements and crafting user stories than the project owner or the users themselves could ever do.

In theory, not doing a sprint 0 and refining the application through iteration could achieve the same result as doing some UX design in a sprint 0. The same way that unicellular organisms incrementally evolved into human beings. But that took millions of years and most of our projects are not planned on geologic time scales.

Making your web site a Wiki is not always a good idea

2010-11-30T15:36:00.005-05:00

Recently, we had a discussion at work about using tricky tactics to influence the behavior of users on a web site. The discussion was interesting and I decided to chime in by pointing my colleagues to the darkpatterns.org web site.

Before I sent the link, I tested it. To my dismay they had taken their web site and converted it to a Wiki. So, instead of being greeted with this:

I was instead greeted with this now familiar nugget of web design:

My gut feeling was one of instant disappointment. Wikis are amazing collaboration tools and allow the content to create and maintain itself. With little added effort to the site owner.

But Wikis also have huge drawbacks. Unless there is a really large (Wikipedia) or dedicated (MagmaWiki) user community, Wikis tend to become static or really disorganized. For example, our intranet at work is a Wiki and it is really hard to find things in there.

This change to a Wiki also made the site design much more generic and removed the flavor of the original site. It visually is less recognizable and, most importantly, doesn't provide me with the feeling that I am having curated experience. It looses a lot of its authoritative nature.

So if you manage a site with lots of user-contributed content, think twice before loading everything up in a wiki and calling it a day. The design of your site and the organization of its content have a lot of impact on how your users will perceive you. You shouldn't leave it to chance.

Everyone is a designer

2010-05-17T09:00:00.000-04:00

There is a new buzzphrase that has emerged. Apparently, we are entering the age of experience. The future will tell if this, like many other things, will pass or stick. However, one thing is certain, people that build products and offer services are becoming more and more aware of the need to provide the user with an experience that matches their expectations.

The deeper trend that this reveals is that there will be more demand for products to be designed instead of just being put together haphazardly. The corollary to this is that more and more people will be put in a position to make design decisions. And many of these people will not be professional designers.

A few weeks ago, while I was at a conference, someone asked the speaker: “How to we deal with developers that think that they are designers?”.

I don't remember who answered the question at the time but I remember the answer: “They are designers; Everyone is a designer”.

In short, everyone designs, we all make design decisions all the time when we do mundane things like shopping for furniture or pick clothes. That doesn't mean that all the design decisions we make are good. The responsibility of professional designers in this case is to help people with less design knowledge to make the right decisions and spend the time to educate them on what is bad design. Sometimes, a little bit of knowledge goes a long way.

Coincidentally, on my wait to the airport after the conference, I struck a conversation with the cab driver. He asked me why I was in town and I told him that I was at a conference about web application design. He went on and told me about his web site and how he was designing it and he barraged me with questions all the way to the airport. As I was stepping into the airport he followed-me to the door and asked: “If you had one tip, just one, what would it be?”

I gave him some random advice about not making his users work for nothing (like filling forms and whatnot). He thanked, me gave me the URL of his web site (he was selling African coffee online) and I went in the airport.

I have had some time to think about this a little more since then. I would probably answer something completely different today like: “Buy Don't make me think and read it.”

But that is not the true morale of the story. The most important is that any little bit of knowledge about design is worth sharing. Because, whether it is by choice or not; Everyone is a designer. And I never know when I might need to order some African coffee online and at that time, I'll be happy that I don't have to fill-out all those extra forms that he was going to put in his web site.

Keeping my MacBook cool

2010-05-07T16:49:00.002-04:00

Since I got my MacBook, I have been plagued with random Kernel Panics that, at first I though were all related to specific software. But as time went on, seemed more and more random. Usually, they happened at the end of the day and didn't seem to be related to a particular piece of software.

After a while, I was suspecting a problem with heat buildup. I had noticed that, after a day of usage at the office, my MPB would be really warm to the touch when I packed it to go home. After installing iStat nano, I observed that the temperature would get all the way to 70C and yet, the fan would remain steady at 2000 rmp.

I had observed that the fan would speed-up when I was doing something CPU intensive but the speed didn't seem to be related to the CPU temperature, only CPU usage. That seemed odd to me as I use the computer all day and the CPU rarely spikes very long. So the heat kept building up and I kept getting Kernel Panics.

3 weeks ago, I found and installed Fan Control. A little control panel utility that monitors the CPU temperature and changes the minimum fan speed for me as the temperature changes throughout the day.

My MPB now remains under 60C all day and I haven't had an unexplained kernel panic since.

Do everything you can

2010-05-03T08:00:00.003-04:00

In my last passage at the Pearson International airport in Toronto, I stopped over at one of the restaurants for a bite to eat. While waiting for my food, I observed a message stuck to the register on the counter. It said: "Do everything you can to make the traveler's life better."

I realize that the piece of paper stuck to the monitor is just a reminder. And that there is probably a better message that was given to the staff of the restaurant to give it context or meaning. Or was there?

I can definitely see the management wanting to get a better performing organization hiring a consultant. I can see the consultant telling them that they needed to have a vision statement for their organization. They lock themselves in a room for a day and collectively author this vision statement: At Molson's T1 lounge, we make everything we can to make the traveler's life better. And then the managers come back and organize a company gathering and serve drinks and present the company vision in a nice PowerPoint.

Although the statement is short and memorable (the business consultant told them that the vision statement had to be short and memorable), it does not have much meaning by itself. The individual employee, the one that didn't participate in authoring the statement, is left with two important questions: Where is the limit of "everything I can do"? and; What does it meant to make the traveler's life better?

I have learned last week that the solution is to make the vision concrete. You are trying to define an experience for the traveler so you need to tell the story from the traveler's standpoint and not the company's. To do this from the traveler's point of view, you need to create a clear picture of that traveler. In other words, a persona representing this traveler. You need to know enough about him to know what is important to him and what are his goals. After all, you cannot make his life better if you do not know what his goals are.

Once you now the person that you are trying to help, you need to create an instance of the vision. A context that the employees can use to guide their own interpretation of the vision. For example, you could tell the story of the traveler missing his connection an having a hard time getting home. Show how the employee at the bar can help make this traveler's life better by serving him food and, while he is eating, making a phone call to help him to get another flight or lodging.

In an situation like this restaurant, you might want to pick 2 or 3 personas to tell stories around. To make the story easier to tell and remember, you could make a small comic-book or short movie to show to employees this instantiation of the vision. Once you have seen such a video, you don't need a reminder on your monitor. The message becomes really concrete and memorable. This is a key element of creating a compelling experience for the traveler.

All employees at this restaurant are design agents of the traveler's experience. And they cannot design a compelling experience for the traveler if they do not have a clear picture in their minds of the vision for this experience. Making the vision concrete is an essential step in achieving this.

And you; Can you articulate in a concrete way the vision of your company from the point of view of your customer or your end-user?

UIE Web App Master Tour, day 2

2010-04-29T10:22:00.003-04:00

Sitting at the airport waiting for my flight home this morning, I thought that I'd checkin on the second and last day of the Web App Master Tour in Minneapolis.

The bar was set high after the first day I was pumped to hear more. Bill Scott started us off by stating that designing interactions is like performing magic on stage. It is in the details and in the performance. The slightest mistake destroys the illusion. And then he covered examples of what were those details that you have to pay attention to if you want the delicacy of the illusion to be preserved.

Then, Ken Kellog spoke about the path that his research team took to bring change to the marriott.com online reservation system and main page. How you have to ensure that you do no harm to the cash cow and the importance of negotiation. Also the fact that even if you have 100 stakeholders in a project. Each one is still a person.

After lunch, Luke Wroblewski shared results from his research regarding web forms. Most notably, how to handle validation and get better input from the user. He then went on to conclude that the best form might be no form at all. Discussing things like Facebook connect for registration and using alternate methods of input like GPS, camera and the like.

Mark Trammel from Twitter then proceeded to walk us through the latest redesigns to the sign-up process of Twitter and how it was driven by the model of engagement that they have constructed through their own user research. He explained the concept of the magnet, the hook and the glue. Which is used to take users through the engagement ladder from curious to casual and finally, to a committed user.

And finally, Jared Spool closed the circle by finishing up the concepts that he had introduced in the very first talk by discussing about the importance of having a vision that you can articulate. That their research concluded that it is an essential component of the recipe for companies that were successful at creating compelling user experiences.

In short, 2 days of interesting talks and discussions. Well worth my time.

In addition, this was my first time in Minneapolis and I felt right at home. I had the whole evening to soak in the city and I am glad that I did. I walked to a restaurant by the river called Ginger Hop and mingled with the locals. Had a really good vegetarian curry and a local beer called Farm Girl. Traded baseball storied (always useful to have one of those handy) and finished the evening catching a movie at the MSP International Film Festival. (the movie was called The bone man and it was very good. Got a little weird at the end)

Awesome time and I am really looking forward to the next time I come back to Minneapolis or the next time I cross paths with someone I met this week.

UIE Web App Master Tour, day 1

2010-04-28T08:34:00.003-04:00

Just thought that I would write a little something before I walk into the second day of the UIE Web App Master Tour in Minneapolis.

So far, it has been a really fun and interesting experience. Lots of interesting people and really great presentations.

Jared Spool opened with an interesting presentation about some of the research that he and his team have been working on to try to define what the required skills that a design team needs to have to solve the difficult problems that today's application can bring to the table.

Stephen Anderson also shared his work on the psychology of the user and how what is known about psychology can help make applications more seductive. He walked us through the process of using mental notes cards to help with brainstorming. (I want a deck of those cards)

In the afternoon, Hagan Rivers spoke about navigation hell. That is a really large topic that seems a little dry. No worries, the presentation was pretty interesting and had 2 little gems in it: Navigation is its own application and Navigation is like storytelling.

Christian Crumlish spoke about social media. He broke it down into its basic components and the patterns that make things social. With simple examples and a few anti-patterns to be aware of.

The day ended with Jason Fried that walked us through the redesign of the project overview page of the Basecamp application. He even joined the conversation with his team live from the stage to comment on an iteration of the design that had just been posted on their chat. (he didn't like it)

Looking forward to today's presentations, I'll check in again tonight or tomorrow.

The geeks don't matter

2010-04-14T08:00:00.001-04:00

Oh yes, I said it, the geeks don't matter. Or maybe I should be more nuanced: As a consumer group, the geeks don't matter as much as they used to.

After the latest round of announcements from Apple about the iPhone, All over the internet, on blogs, FaceBook, Twitter and wherever you choose to point your browser, you'll find a whole lot of angry geeks. That is, if you are yourself a geek. Otherwise, you're probably not reading those articles.

People are angry that Apple is further building their closed system. That they are removing user's freedom to choose. That they are forcing developers to write Apple specific code by blocking cross-compilers and all that. They vent online making all sorts of arguments about how they won't use Apple products and how they have lost their trust in apple that has finally become as bad as Microsoft.

Vent and rant all you want. Rest assured however that it doesn't matter. It will not change Apple's decisions. You, me, the geeks, are not the main customer group for Apple. See, we never were. This is perfectly consistent with Apple's past behavior and strategy.

And geeks all over should be ready to suffer even more and get angrier. Not only are geeks not the main customer group for Apple. But they are bound to loose their status as the main customer group of most other technology companies as well. The biggest accomplishment of Apple over the past few years, culminating with this week's announcement, is to demonstrate that if you don't aim your technology product to a technologically savvy audience, you end-up making bucketloads of money.

This means that other technology companies will also realize that they can stop caring about the requests for openness from the technology elite. They can safely ignore this because it is much more lucrative to sell to the normals than it is to sell to the geeks.

Some will argue that this is not the best for the consumer. But then again, companies rarely do things because they are best for the consumer. They do things because they are best for themselves. (tobacco, agro-industry, oil companies, etc...) Why would a company like Apple (or Microsoft, or Google or Amazon) voluntarily limit the amount of revenue they can extract from their customers just to preserve their rights to choose the content that they consume or the way they consume it.

Consumers will continue to purchase proprietary devices with arbitrary limitations because they are not interested in how it works or why it works in a particular way. They just want to get something that satisfies their needs, that works and that they can afford.

I guess us geeks should get used to this. The era of large technology companies run by geeks building products for geeks is over.

Hey... we had a good run, it was fun while it lasted.

An exchange program for employees

2010-04-12T08:00:00.001-04:00

A few weeks ago, I read an interesting post from Darren Barefoot who was asking What if we traded employees like hockey teams trade players?

It is an interesting concept but I think it might be too much of a culture shift to be practical.

As someone already pointed out in the comments, large companies already do this between departments. However, I work for a smaller company and there are no other departments to shift the employee to.

Although my employer is not big enough to do this, the company is old enough to have employees that have been there for more than 7 years. Some are choosing to leave. Not necessarily because it is not a fit or are unhappy but because they don't want to stagnate. There's an urge to see elsewhere.

What if we sort of went half-way? What if companies were setup to participate in an employee exchange program? Take 2 software companies in the same town. One is specialized in iPhone development and the other is specialized in writing software for medical devices. Both are staffed with a mix of programmers that are competent but some of them need a change of pace and are feeling the need to keep their knowledge fresh. They could swap one or 2 programmers from each side for 3-6 months.

As an employee, it seems like a good situation. Your employment status doesn't change, you get to satisfy your wanderlust and you get to learn new skills.

As an employer, you benefit from having people trained in the other company's specialty and in addition, you get to learn a little bit from how the other company works. There might be an opportunity to streamline your own practices. Since you're trying to involve employees with similar skill level, they will contribute to your own projects. Maybe not as much as a fully ramped-up employee but it is like getting some training for a lesser cost.

There is always a risk that, after the exchange, the employee might want to stay with the other company. It is probably possible to mitigate this contractually. Through a no-hire clause or through some compensation agreement. But I feel that the openness of the exchange program would make it easier for companies to be better prepared for these unplanned departures.

I have been working 12 years in the same company. I like my job, I don't want to quit. But if I had the opportunity, I would be interested in seeing how it is done somewhere else. If just to satisfy my curiosity and possibly learn a thing or two.

After the gold rush

2010-04-05T11:45:00.000-04:00

Recently, a colleague of mine was cleaning his desk and found a copy of After the gold rush (the book, not the album) that he had borrowed from me years ago.

This reminded me of how I felt about that book. When I first read this book, I was just starting my career and I was very impressed by that book. It is one of those books that I would have put on the must-read list for any software developer.

I really liked the idea of software being thought of as an engineering discipline. I wanted software companies to make better software and the process to become more predictable. I used to work for a company that made shrink wrap software and that was known for the death-march style of software development.

Well, the gold rush came and went, and came and went. Software development had changed but I have also changed. More than 10 years later, I don't think the same way at all about programming. In the past 10 years, we have tried to formalize, productize and normalize software development. And as much as we tried, it pushed back and wanted to go back to its true nature.

I think that software development is a craft. Something that skilled, trained people do. There is still a category of software that is purely engineering; like software that runs nuclear power plants and the space shuttle. But that is a tiny fragment of the software that gets written in the world. In the past few years, software has become so entrenched in our lives that it has become very personal. Software is not about machines but more about people.

People don't like to consider software as a craft because they associate craftsmen with the old guy making custom vintage furniture replicas in his workshop. But there are other large-scale human endeavours that are also run by craftspeople. Movies are one great example. Movies have been compared with software development before but I'm looking at it from the point of view of the skill required. Movies involved large budget, tight schedules and lots of specialized, highly technical labor. In many cases, actual engineering is involved. But in the movie industry, engineers that work on a movie set are considered craftsmen and there is no negative connotation to this.

Like software, there is a method to the creation of movies and there are ways to manage these large projects even if it is not all guesswork and gut feel. So I think that, after the gold rush, we should embrace the craft of software development. We should learn to deal with it as such and learn to manage it properly. Instead of trying to force-fit an engineering or manufacturing process that will never really fit.

To every person involved in designing software

2010-03-31T09:14:00.003-04:00

Greetings.

As we learn to design software, a recurring problem becomes clear.

The problem is this: To differentiate between valuable and not-valuable. Let me break it down now.

Everyone in product management is screaming at us to make the software easier to use. We are also tasked with it, it seems, cramming a shitload of features into a little bit of time.

Our friends, the penguins, think that we, therefore are employed to write features — and, so, at times, it seems to us.

But note: The users will not log-in to use features. You wouldn't, I wouldn't. No one would or will. The user will only log-in and keep logging-in to get value.

Question: What is value? Value, again, is the quest of the user to overcome those things which prevent him from achieving a specific, acute goal.

So: we, the software authors, must ask ourselves of every feature these three questions.
1. Who wants that?
2. What happens if they don't get it?
3. Why do they want it?

The answers to these questions are Litmus paper. Apply them, and their answer will tell you if the feature adds value or not.

There is not magic fairy dust that will turn a superfluous, useless, redundant or merely hard to use feature valuable once the user downloads the software. You the software author are in charge of making sure every feature is valuable.

If the features confuses or bores you when you design it, rest assured that it will bore the programmers, and will, then bore the user, and we're all going back to the breadline.

Someone has to make the feature valuable. It is not the programmer's job (the programmer's job is to make it work to the design). It is not the project manager's job. His or her job is to make sure it gets built and delivered on time and on budget. It is your job.

Every feature must be valuable. That means: The user must have a simple, straightforward, pressing need which impels him or her to show-up and use the feature.

This need is why they came. It is what the feature is about. Their attempt to get this need met will lead, at the end of the workflow, to success. If this need is complex and requires more than one feature, this need will, then, of necessity, propel the user into the next feature.

All of these workflows, taken together, will, over the course of the session, constitute a completed task.

Any feature, thus, which does not both advance the task and standalone (has value, by itself, on its own merits) is either superfluous, or incorrectly designed.

I close with one though: Look at the feature and ask yourself "Does it add value? Is it essential? Does it help the user complete their tasks?"

Answer truthfully.

If the answer is "no", write it again or throw it out.

It is not your responsibility to know all the answers, but it is your responsibility to know and ask the right questions, over and over, until it becomes second nature.

With apologies to David Mamet (original text)