Refactoring the user experience

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

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

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

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

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

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

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.