If these cars could talk.

At a recent cars and coffee event, I came across two Volkswagen van conversions. While not the most expensive and rare of this weeks displays, they did stick in my mind later.

I started to think how the humble VW van can relate to user experience. It’s mostly a study of ethnography and personalization, born out of necessity and utility. Each claims it’s identity by its owner and the modifications done to it. It is unknown if the selection of the VW van as a flexible platform for its variants and tweaks was out of simplicity or a availability. The base design remain unchanged for decades. Take notice that you may have seen many VW vans and Kombis in your lifetime, but I can guarantee that rarely has one been identical to a previous encounter. They are like dogs in their variety, and likewise in our affection for them. They have achieved that man’s best friend status.

It’s not an elegant ride, by far. It will never claim the sexiness of an Alfa Romeo, or a Jaguar. It does project an image that may not square with superiority, but it does make a statement of uniqueness. It is hip to be square.

Imagine the stories these two examples could tell. I am sure the lowered one has stories on multiple coasts. Hauling people, sail skiffs, canoes, surfboards, band equipment, migrant workers, partygoers of all types.

The olive green example is more camper like. I imagine it reeks of patchouli and Humboldt Headband, or better yet it may capture the mood, smell, tastes, and excitement of the Star Wars Catina scene.

While the occasional law may be broken near or in these vans, seldom does it involve malice. Consider the beginnings of Volkswagen as a company, and its peace-loving, hippie-like, iconic status it now represents. The miles these vehicles have traveled exceed physical and emotional norms.

So tell me your VeeDub experience in the comments below.


On Being an Almost Famous Chameleon

In the movie Almost Famous, Jason Lee’s character, Jeff Bebe, explains his drive on connecting with fans. “I get people off, I look for the one guy not getting off, and I make him get off.” See clip

Minus the bravado of a cocksure 70s lead singer, this is what makes UX people shine. The ability to connect, using empathy, walking in someone else’s shoes to generate an enjoyable outcome. This is our jam. This is what we do. While it will always be easy to understand a subject we are experts in, for example, avid travelers recreating a reservation site, the real art is in full immersion into something new.

This where it helps to be a chameleon of sorts. To quickly adapt to a person’s needs and desires to create that optimal, delightful experience. To quickly understand the tasks needed, the optimal results, and identify pitfalls that may be blockers to that positive outcome. And like Jeff Bebe, it helps to find the toughest user or stakeholder, the skeptic, and make that connection. Make that person your champion by showing them your process, your prototypes, your attempts to understand their needs. And you will get better at this, each and every time. The more of these experiences that you can blend into, and show off your skills, the better of a chameleon you will become. The challenges you will face will always be met by your ability to change, but not change who you are. Keep your integrity.

Have junk? Make music. My dive into cigar box instruments.

My oldest son taken to playing guitar, and like many guitar players, the amount of his playthings seems to be constantly growing. It is said that idle hands are the devils playthings. His interest into music has brought him out of just sitting behind a computer to interacting with creative folks. The friends that he has made in his teenage musician circles, has also led him to join the wrestling team. Who knew so many wrestlers also jammed. His confidence has grown and his physique has improved. Plus he rocks at both guitar and bass now.

Well I wanted my own little playthings of the musical variety. I felt an urge to join in this madness, but knowing that household budgets are limited, I decided to begin making guitars and musical instruments out of leftover wood and cigar boxes.innovation-quotes-18-728

Cigar box guitars are embedded in American roots music. It spans Mississippi Delta blues to power rock, as well as international flavors. Basically anywhere people can fashion a pluckable string to a resonating chamber, you will find creativity in sights and sounds. With parts easily accessible from on-line shops, one can quickly amplify a primitive instrument to a searing electric scream machine for very little money.

This was my first creation, the Victor Sinclair fret-less, 3 string. It has a piezo pickup encased in silicone to lesson the sounds as it is being handled. It plays nicely with a slide. It is a red oak next with a bubinga fingerboard. I used zebrawood for the nut and floating bridge. I used a drawer-pull as a hand rest near the tail piece. Screened grommets allow for good resonance so it can be played unplugged.


This is my first build. I will post more as I continue this journey. See my Instagram for this guitar being played.
Read More

My UX Team is Run Like a Circus

There is an old Polish saying, “Not my circus, not my monkeys!” This is used when something has devolved into chaos. Our current election cycle often brings up the reference that normalcy and sanity has devolved into a circus.6d36e782c1b48a128f4e53d063e134aa

The idea of the circus is energy, confusion and novelty. You never quite know what to expect – that’s why people go to the circus. When monkeys are involved, especially if they get loose, there’s a good deal of chaos as well. But that reality is that circuses are well run, highly synchronized and choreographed displays of ordinary people doing extraordinary things to the delight of others.  Whomever utters the saying, signals that they not the ring master of this disaster, mess or ball of confusion. The problems/monkeys aren’t from their show. They are just watching – it’s not their job to fix it. But in UX, everything gets back to the experience. Slow connections, bad data, poor responsiveness, accessibility issues, these all track back to the user experience. So it is our circus even if its not our monkey.

All members of a development team are responsible for the user experience of the end result. With DevOps, the entire team has the responsibility to satisfy the customer by maintaining the software in production. By blending UX and DevOps we draw inspiration from what I learned as a circus performer with a foundation of teamwork, trust, and audience feedback. Circus performers and UX teams are similar in that teams can embrace multiple disciplines to make system development fun, engaging and to thunderous applause.

The act of watching a circus is about witnessing amazing things. The breathtaking acts of physicality that brings audible gasps, rollicking laughter, thrills, excitement; it is all about the experience.

But how does it happen and how does it relate to UX and building amazing web products. There is so much more behind the scenes that happen before the lights turn on, the curtain raises, and audience fills in. And there are direct juxtapositions to application and web development.

Being part of a circus, like successful development teams, relies on teamwork, specialization, cross training, security (safety), the right equipment and, sometimes, a little luck. It’s based on training, repeated practice, and learning new things. It’s accidents and failures that we learn from; that missed trick that becomes the inspiration, and the inspiration that becomes the catalyst for dreams.

It’s also about building a team, and building it quickly. Where do you find this unique talent? It’s actually everywhere, but its hidden in plain site. There are the once-in-a-lifetime folks with broad skills (unicorns and freaks) and innovators; the dreamers, non-conformists, builders, and coaches, passing down skills. Its practice (hack-a-thons), and open experimentation, and getting that crowd feedback.

It’s about being bold and pushing yourself and your team to do something crazy. It’s getting outside of your comfort zone, and sometimes wearing tights in front of a crowd of strangers and enjoying every minute of it. But it is also about transforming not only yourself but also the culture. Circuses, like development methods and technology, evolves over the years to account for changing expectations. The formula is the same; push yourself, do something rad, entertain, and repeat. It is always about people, the ones on stage and the ones watching.

While in college, I was part of the Florida State University Flying High Circus while obtaining a Studio Art degree from a football factory (a limitation I fully understand). As a performer and coach, including acts like high-wire and teeterboard, my time in the circus prepared me to be a successful leader. I challenge my team to try new things, but mostly to enjoy doing them.

“We are the dreamers of the big dreams.” – Willy Wonka


I will be speaking next week about Circus and UX at GiantConf in Charlotte, NC. Join us.

May all of your days be circus days.

Improving the User Experience of Creating a User Experience

There are two types of users for everything we build; end users and those that build and run the system. Both sets of users can benefit from a better user experience. These benefits can be in the form of a productive, human-centric, quality of life improvements to the process of systems delivery. But it also can lead to uncovering that innovative spark that can be easily missed if we are not looking for it.

DevOps eliminates the all-day all-hands, end of release code push, thus freeing up the weekends of your staff, reducing stress, and positively adding to their work life balance. Adopting continuous development and delivery also reduces the ‘work in progress’ time as code ships when it ready, eliminating bottlenecks and gateways that cause buildup. Project plans are always based on best-case scenarios with some room for the unforeseen, but not much. Removing these bottlenecks improves the efficiency of developed code to be pushed. Communications and automation reduces human error. Projects can be run in ‘human time.’ Continuous monitoring used to track system efficiency, can also be used to track development progress and velocity.

Without employing a DevOps posture, small fixes are sometimes pushed off in favor of new features leading to UX debt. UX debt is the difference between the experience your current digital product versus how it can be improved if it would be given the necessary attention and resources. UX debt can stymie the maturity a product if it is never addressed, or pushed to that never to be realized defect sprint. What should concern the entire team is that widening delta between the original intent and the current outcome.

This can breed a culture in which smaller issues, which may seem unimportant, get over looked or never even attempted. This can also lead to less technical areas of practice, such as user research and concept validation are typically sacrificed for saving time and costs. The pace of feature building usually forces this sacrifice to the point that innovation and viable alternatives are never even attempted. What innovation are we missing by not coming up with and/or testing alternatives?

Instead of skipping steps to save time or money we need to ask, not only what does the user lose by not implementing the better solution? But what does the program or organization lose by not innovating?

Designing for continuous software delivery means being in step with the velocity of development while simultaneously listening to user feedback that gets translated into the next set of improvements. If we ignore UX for the sake of feature delivery, we can lose more than better project. We can lose credibility and future revenue.

At the end of the day for the end user or customer, deadlines, processes, checkpoints, and controls that govern the development of a digital product has no relevance. Satisfaction comes from the actual desired outcome, and that is independent of the internal workings of the organization.

Fear and loathing in medical intake.

empathySimple ways empathy and anticipatory design can be used to ease fears.

A few years ago my family went through a very trying medical emergency, which required a trip to a local hospital. This trip was set up hours before our estimated arrival time so that we knew we could be seen and adequate personnel and procedures would be streamlined. However it was not the case. Without getting into too much personal detail, I will outline the shortcomings of this intake experience and how it could have easily been made better, and less traumatic. My skills are as a user experience professional, but I am a budding customer experience/service design enthusiast. But first and foremost I am a father, husband, and human. Any medical intake process can be alarming to a first timer regardless of the condition or situation. Fear overrules rationality, and when no information is flowing, that fear can take a firm grasp of your psyche.

The hospital knew we were coming, but had nothing showing in anticipation of our arrival. It was a cold, wet December evening with slush and snow still on the ground. And it was after visiting hours. This was our first experience with this facility, a fact that was shared with our intake team during the preceding few hours that led to the availability of their services. Upon arrival we noticed that there was no parking at the entrance to the facility, not even temporary. There was parking along side of the building, closest to the door, but every one of those spots were taken. Due to the time, well after visiting hours, my only assumption was that this was staff parking, the fact that many of the wipers were altered for the treat of ice cemented my thought that these folks intended on being here through the majority of the snow and ice. We parked at the rear of the facility, but were not allowed entrances through the rear. We had to walk around the facility parking lot, which was still full of slush and snow. Please keep in mind that this was somewhat of an emergency situation, not life or death, but something that needed an immediate visit. The first solution is to reserve the parking spaces closest to the front for intake only. Employees have access to the rear of the facility; nervous patients and their families do not.

When we arrived we noticed the intake/reception area was empty. We were the only ones there with the exception of the receptionist who sat in silence after we explained who we were and why we were there. She acknowledged that she was expecting us and asked us to take a seat. After a few more minutes in silence, the receptionist finally explained the process only after we asked her how long this would take. We were handed paperwork that was redundant to the information we provided on the phone prior to being cleared to arrive. We were scared nervous and needed support. But we are left in silence. There were water and snack machines, but the receptionist will not give change, says a note on the machine. A TV is playing news. There are flyers about various conditions scattered about on various end tables. No one is talking to us. This is all unknown and new to us, and it could be done so much better. The receptionist still has my driver’s license and health ID card, 30 minutes after I gave it to her. A quick reminder that she is working on things would have been helpful. An administrator did finally come to speak to us with a question about our paperwork. The administrator person further explained the process, but only after we pried for information.  She is being patient as well as the IT department is working on her computer and she is waiting for issues to be resolved of her own. She gave us book, pamphlets, and reminded the intake person we were waiting. The books and explanations provided gave us insight to what to expect. This was calming, however should have been done much earlier. She stated that if her computer wasn’t offline, these delays would not have happened; however there should be a plan for this situation.

How to easily make this better? Have information ready for us when we arrive. Start thinking in anticipation of arrival, not reactionary. There was no reason for this intake to take as long as it did. We were with our two children who were a little scared. Healthy snacks and something for them to do, like a coloring book, or something of that nature would have done wonders for them, and for us as parents. It is easy to come up with some healthy, non-allergenic snacks to have on stand-by for such a situation. Instead of a news program, perhaps the receptionist could have switched to an appropriate movie or something the kids could have enjoyed to ease any fears or confusion. If there is a snack machine in your lobby, be prepared to offer change.

The paperwork we went through on the phone could have been ready for us to sign when we arrived with follow-up validation steps. A complete repeat of the exact same process we worked for hours on the phone with the intake specialist felt soul crushing, and it seemed like a waste of time. The situation we were in was unique to us as it was our first time, but this facility deals with these scenarios often. Did complacency taint the experience? Is there a lack of empathy due to the repetitive nature to the work?

The suggestions I propose are low cost, and in my opinion, basic common sense. But I do not work in the facility or in that field of medicine to know a difference on what is procedural and what is apathy. But I am human and I understand empathy. Each of those people in the intake station should try to walk in the shoes of their patients every now and then to understand life on the other, scarier side of the desk.


Thankfully, our issues have been controlled and we have not needed to return to that facility. However I wonder if anything ever got better. I do not wish to point blame, which is why the facility is not mentioned. The care we received served our needs, but it could have been a simpler, less scary experience with simple, more human, adjustments.



Guaxamole: Awesome food as metaphor for UX.

A few years back, Patrick Neeman shared Ed Lea‘s brilliant info graphic  on User Interface vs. User Experience utilizing cereal as the metaphor. It works on many levels, but mostly, in my opinion, because everyone understands cereal.

Since I am always hungry, I was wondering if I could do something similar, but expand it and using guacamole as the metaphor. I also wanted to see if I can push the conversation a little further to create a level of understanding that can explain the voodoo that we do, and be fun in the process.

mojcajete.jpgIf you have taken the time to read this, please follow through and see if I have missed something, or could expand on things more. I am planning a presentation to my UX team to go through these concepts while making a batch of my exquisite guacamole. I hope to capture some images from that event and post them here. In the meantime, here are my thoughts with various images from the web.

Initial considerations

  • What is the definition of done? We need to agree what is guacamole, is it just avocado and peppers? Tomato? Do we add lime? Defining our agreement on the recipe sets expectations and goals.
  • If guacamole is just smashed avocado and little else, are there pre-made products may be combined for quick satisfaction of need? This would increase your “time to market” but what about quality and differentiation?


  • Mise en place, the cooking term for your initial set up (knife, cutting board, ingredients, bowls), are the tools you need for development, development environment, server, content, information architecture, etc.
  • The cutting board and molcajete is your development environment. The latter is possibly your server or production environment as well.
  • The act of making guacamole is your development sprints.
  • If not serving from the same bowl you made the guacamole in, then plates used are your browser.
  • Tasting while you make guacamole is your unit tests. Having guests taste test are your constant user feedback. Other people tasting while in process is user interaction with prototyping.

ia-persUser Feedback/Ethnography

  • Chips are your User Interface.
  • Having multiple chips available, blue corn ships, cantina chips, etc. is a form of user feedback with A/B testing. Watching some chips break is usability testing of the UI.
  • Asking users about spiciness, cilantro tolerance, or preferences is ethnography.
  • Ethnography and user feedback lead to personalization factors. This can be in the form of extra jalapeño and salt allotted for personal tastes, or perhaps a new ingredient like a tomatillo can be offered.

service-designService Design/Customer Experience

  • Giving chips and salsa prior to making guacamole is service design, customer experience, and hints of anticipatory design. In a restaurant it primes the visitor for ordering guacamole, or a tasty beverage. This is part of your UX/Customer Experience strategy.
  • Table side guacamole in front of guests is the customer experience, more than just taste, creates memories. Entices others to order their own table-side guacamole.

Guacamole-00-ingredientsContent Strategy/Information Architecture

  • The categorization of ingredients is your content inventory. Fruits, vegetables, herbs, spices, heat, aromatics. These are also the elements of your information architecture.
  • Using fresh ingredients is an example of content strategy. You can opt for cheaper ingredients that are not as fresh, but will affect the outcome.
  • Chopping up ingredients is also part of content strategy. Do you want to create chunky or smooth guacamole? User feedback is key to finding this out. This is also part of your content strategy as it will define how you offer your product and how will it be prepared.

guaconthegoMobile Strategy

  • Responsive design, the use of small soufflé cups full of guacamole can represent a mobile solution for guacamole. The previously mentioned ready-made guacamole (like Wholly Guacamole) can also be considered part of a mobile first strategy as it is already packaged for travel.

visualVisual Design

  • Using best looking ingredients, different colors, purple chips, is visual design. This is your presentation layer. Do you have artistic platters or bowls. This is where colors and textures differentiate your guac from others.

Follow this post and comment and I will post my recipe and techniques on making the world’s best guacamole. Please comment so I can refine this.

Thwarting Pigs, Crushing Candy, and Prototyping.

Failure is not an option. It’s a necessity.

If all we ever do is succeed, we have never pushed our own limits. Failure is an important step – and a very liberating one – when interaction designers realize they can miss the mark on something without it being the end of the world. And when they start to realize that it is a stepping stone to future success, that’s when they take off.

The object of a prototype is to learn, and often by failure. That is, it is to test the limits of design, so it can be improved. Thomas Edison, while inventing the light bulb, often opined on the large number of failures we worked through to light up our world. He has been quoted as saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

angryBirdsAnother common example of repeated failure leading to success is/was Angry Birds, depending on your level of mobile phone games. No one ever uses up their birds and says “I quit”. Even experienced players will even launch birds at specific targets in an attempt to discover weaknesses in the structure, which is intentional failure with a purpose. In Candy Crush, as we progress through levels of complexity, we will try combinations of moves that lead to repeatable patterns to overcome the challenges. When we fail, we tweak our patterns and try again.

In our world we are not thwarting pigs or crushing candy we are building systems and our prototypes are interactive tools that communicate the organization and navigation of the application – often called the Information Architecture. They also serve to depict how individual pages should be structured for usability purposes.

A typical prototype contains very few graphical elements, most (if not all) back-end functionality is simulated, and data is static. For web sites and web applications (and even for software applications), we use a combination of HTML, CSS, and JavaScript to simulate the actual intended behavior of the system. We can also employ tools like Axure Rapid Prototyping, to increase the level of fidelity without increasing time.

Level Up: The Different Levels of Fidelity

The level of “fidelity” of a prototype refers to how closely it resembles the final product. For simplicity’s sake, we’ll consider three levels of fidelity used for prototypes: Low, Medium, and High.

Wireframes are, in essence, low-fidelity prototypes. They may have been implemented from a collaborative mass of sticky notes on an office wall; results of a multi-colored JAD sessions on a white-board, or, in most cases, PowerPoint pages that depict navigation and screen layout. They’re easy to create, inexpensive to change, and are good for providing a basic “high-level view” of the overall system structure. Where wireframes typically focus on what can be developed with the total understanding of constraints and resources, prototypes focus on the art of the possible. Typically constraints are ignored in initial ideation in prototyping, and are introduced though refinement and iterative designs.


High-Fidelity Prototypes, on the other hand, are often deployed with an almost-full set of graphics, functionality (such as usernames and passwords, session variables, etc.) and tie-ins to dynamic data sources. They are very detailed systems that are expensive to create, difficult to change quickly, and usually require more rigid software development practices in order to successfully complete. In fact, High-Fidelity Prototypes are sometimes so close to the final product that they actually become the final product. These are mostly effective to get client buy in and to create proof of concept pieces.

The higher the level of fidelity of a prototype, the more complete and accurate it is at representing the final application. However, that completeness comes at a cost. Rapid changes are more difficult to put in place due to design considerations.

The middle ground is to create Medium-Fidelity Prototypes. These prototypes are sort of a best-of-both-worlds implementation that allows for a combination of both high-level and detailed views; rapid, iterative changes; and the ability to conduct meaningful user tests to evaluate complex functionality and to help determine system specifics.

Medium-Fidelity Prototypes: A Win-win Situation

By combining HTML, CSS, and JavaScript (for web applications), or utilizing a tool like Axure, we’re able to relatively quickly create an interactive example system that is designed to help the client, the development team, and the visual designers better understand the requirements guiding the project. When used as part of an application development project, a prototype can:

  • Communicate the design. If a picture is worth a thousand words then an interactive tool is much, much more. A prototype demonstrates to a client what functionality the system can deliver and what it will be like for users to interact with that system. With this knowledge, a client and the development team can more easily prioritize the development of features and functions and determine project scope.
  • Get everyone involved. Prototypes are primarily top-level, simple in design, and relatively inexpensive to implement and change. Available to the client team, the development team and a wide variety of users, prototypes lend themselves to a participatory design process where many key roles have to “buy-in” to the nature and behavior of the final product. If you include using actual users, these participants form your user pool become your internal advocates for a new application or a redesign.
  • Catch mistakes early. Ideally, prototypes are frequently tested in formal and informal usability sessions throughout their development. This allows design flaws such as ambiguous labels or intolerance for user errors to be caught early and corrected relatively inexpensively. Prototyping reduces risk and helps avoid the possibility that the final product becomes merely a prototype for the next release or a situation in which the prototype itself becomes the final product!
  • Support iterative development. Frequent user testing and subsequent prototype revision can also support an iterative development process. In this way, the Web site or application interface can evolve (through the process of either adding, refining, or removing features and functionality) until it reaches a stable state. Once the design is stable, development can begin.
  • Facilitate detailed requirements gathering. Because prototypes provide a common ground of understanding between users, client team members, and development team members, they greatly help in establishing business requirements, application requirements, and use cases. Ideas for what the system should include or how it should function can be quickly worked into the prototype, evaluated, and reflected in the formal requirements.
  • Guide later development stages. Once a prototype is developed and approved, it becomes a blueprint that can guide many teams involved in the later stages of the development process. Graphic Designers, for example, can use the prototype to understand system behavior and graphical requirements (buttons, navigation, etc.). At the same time, Application Developers can use the prototype as a live representation of the use cases (even to the point of using prototype pages as a test front-end to their code) and to understand how the system is intended to interact with users.

The Pitfalls of Prototypespitfall

Despite their many benefits, using prototypes in an application development setting often require some setting of expectations among users and client team members. The most important is that, generally, prototype code should never be used as production code. It should be considered throw-away code.

Because they lack graphics and dynamic data, they are generally not considered “final” products. Yet it is easy for both clients and team members to want to see more and more functionality and detail included in the prototype. We recommend avoiding this temptation, however, and reminding your clients of the benefits of keeping the prototype at a medium-level of fidelity. For it is only at this level that you can completely enjoy the benefits outlined above. It is important that a “finish line” is established for a prototype.

Although Medium-Fidelity Prototypes maintain a relatively “unpolished” presentation, they can support highly relevant system interactions, and are easily modified to illustrate alternative designs. Because of this, we find our prototypes are often at the center of many critical discussions involving the members of both the client and the development teams. Ultimately, these discussions result in a better solution, and our clients (and their users) are happier for it.

Achievement Unlocked: So what did we learn?

Prototypes are attractive to development teams because they have clear benefits. They facilitate communication by exposing design assumptions, drive ideation, and provide an optimal, realistic setting, for gathering user feedback. But prototypes are complex artifacts: They have many different dimensions and can be created with a variety of tools. Project teams that don’t understand these complexities can waste time and effort–and even thwart project progress, but not any pigs. Before they start to develop a prototype, project teams need to consider the business objectives that are driving their efforts–and then manipulate prototype attributes and fidelity to support these needs, and get that high score.

Is he ruining the soup? Can anyone do User Experience?

For those who haven’t seen the movie, Ratatouille, it recounts a rat named Remy who has a dream to become a chef in the city of Paris. The dream seems impossible, because he is just a rat. However, at the end Remy manages to be a chef despite the troubles he faces. There are the themes of courage and perseverance, but another theme that runs through this film is, “Not everyone can be a good cook, but a good cook can come from anyone.”

The same can be said for usability and user experience. As a leader of a user experience team, how can I say that anybody can do UX? Have I just written us off your projects? To be blunt, the answer is no.

Anyone can do some UX and usability analysis. And, as a mantra, some usability is better than none. But knowing your limitations and being aware of what you could be missing is really important. Having a guide that can show you how to maximize your usability analysis can be the difference between simply meeting your project goals and delivering a product that will resonate with users.

I often use food as a metaphor. It is something we all have in common. For some it is a necessity to eat, others a desire and joy. In going over research and in discussions at conferences with UX professionals and others conducting usability tests, there is an unsettling trend in which untrained and inexperienced testers make a variety of errors in the way they conduct usability tests. Valid and useful UX activities, like a good recipe, take time and expertise. Shortcuts and lack of rigorous controls invariably reduce the validity and usefulness of the usability activities, like information architecture, usability testing, and interaction design. Too much browning and garlic gets bitter, spoiling your pasta sauce. Without the proper amount of time, your dough will not rise in baking. Usability is a lot like cooking.

Cooking, like your projects have a start and an end, and people need the finished product. Like our need to for sustenance, our systems need to meet their stated goals, which it can do much better if the design has been improved through usability.

But can anyone really do some UX and get results?

In cooking, like UX, anybody can perform the most basic activities. Most anyone can boil water, scramble an egg, run a quick test with 5 users, or score a design for compliance with a heuristic checklist. And if you cannot, you can learn the basics pretty quickly. They’re not all that difficult. Remember, any usability is better than no usability. However, there is a level of excellence beyond the basics.

Going to a fancy restaurant and eating a meal cooked by a five-star chef is vastly different than eating something you throw together yourself in 20 minutes. Similarly, a usability expert will give you insights into your users’ needs and your possible design directions that are much deeper than advice you’d get from someone whose main job is in a different field. Skill levels form a continuum from beginner to expert, it’s not an either or situation.

Every time a non-UX practitioner learns something, their performance improves and they learn a new skill. Some facets of UX, like usability and cooking are particularly suited for continuing education, because anything you learn will remain useful for many years to come. This is why some basic usability training is important: you get better results for every extra bit you learn.

The cooking analogy gets even tastier:

  • Even though multi-star gourmet restaurants are wonderful, there’s also a need for modest neighborhood restaurants, and comfort food. Similarly, you should sometimes use a junior usability practitioner or even a resource with a passing interest in usability, instead of bringing in an established usability practitioner. Most design projects include many workman-like, everyday UX analysis activities that the less experienced folks can succeed at.
  • Even if you can afford it, you shouldn’t eat out every day. Your waistline benefits from getting more modest meals most of the week. Similarly, sometimes it’s good for your project if many day-to-day usability activities are performed by the designers and developers themselves. The more usability guidelines these folks know, the fewer design mistakes they’ll make, and the less rework you’ll have to do after discovering how people really use your product. But knowing what you don’t know is important. And if you are trying a new recipe at home, you will most likely look for an experienced resource, like the internet, cookbook, or a friend that has tried it before as well. The bottom line, know when to ask for help.
  • Variety is the spice of life. Think of a resort, a gourmet market, or the many restaurant choices that a city has to offer. Why pick only one type of cuisine? Similarly, combining many usability methods — such as user testing, guideline reviews, analysis by independent experts, analytics, and field studies — offers the best insights into optimal design. Experienced usability professionals have a very rich toolbox that goes beyond the simpler methods that anyone can use after a few days’ training.
  • Sometimes it’s important and easier to leave it up to experienced cooks. As much as someone may enjoy sushi, seldom does one attempt this on their own. Are you sure you are using the right type of tuna? If cooking for guests do they trust you? If being served by an untrained cook, do you trust they got that specialty correct? Also consider something like stuffed grape leaves, which are amazing, but where does one find grape leaves? Or the more common Indian food, like butter chicken. Do you have a clay tandoor oven? Do you want to roast cardamom pods in your home? The people who specialize in these things can do it faster and already have the right tool for the job.

DIY or leave it to the Pros – It’s really a matter of balance.

Experts will always add value in user experience, as in other walks of life. An expert can go beyond the accomplishments of newbies and those that are interested, but not exactly classically trained. But no, that doesn’t mean that usability and UX should be the responsibility of the experts alone. Everybody on the team needs to take responsibility for improving the user experience. And anybody can do usability; the basic methods are simple enough.

For more tasty examples of how user experience can help your projects, contact the Digital Strategy User Experience Team.

Bon Appetite.

Fat Monday. Or playing to your strengths.

Many, many, years ago, I thought I wanted to be a chef. I did, and somewhat still do, but there is one thing in the way, reality. I like to cook out of joy. Why attach it to a job? I already do that with design, once graphically, and now with making information systems, applications, and websites easier to use. But my first love will always be cooking. I know I get this from my mom and dad. Mom would spend nearly every Sunday making pasta from scratch. And on the 29th of every month, she would make homemade gnocchi. My dad was the asador, the master of the parillada. He gave me my zeal for adventurous eating. Try being a young boy and trying to understand what blood sausage and sweatbreads are. Just taste, and then learn what they are never go the other way, your palate and experiences will always be limited.

Being a fat guy, I could not rely on looks to get dates, and there were not many. A fellow man-larger-carriage, John Popper of Blues Traveler, once said that his music needs to be great, “Because my ass won’t sell records.” I have used humor and food preparation in the wooing of women. It worked; I am not tragically single and have found my partner in life, my wife Michelle, many moons ago. She is not as adventurous when it comes to trying new foods, but we have come a long way from fish sticks (her own admission of an Ohio born girl).

One of the first things, I believe, I every made her were the stuffed peppers below. They are amazing, especially served chilled. Mind you, Michelle despises two of the ingredients, anchovy and olives. But it contains balsamic vinegar, which makes the world go ‘round.  I lost this recipe for many years. It originates from Anthony’s Runway 84 in Ft.Lauderdale. I recently found an article in the Sun Sentinel Online form 1994 that has it. It has been saved to the hard drive and it is not presented to you here. Enjoy this chilled.

The Cubanelle peppers are a native of Florida and available in most supermarkets and produce markets. They are a light green, elongated pepper with a very mild flavor, a perfect vehicle for the savory stuffing.

Stuffed Cubanelle Peppers

  • 12 Cubanelle peppers, stem ends cut off and se
    eded (I used a demitasse spoon to reach into the narrow ends)
  • 1 1/2 cups dry bread crumbs
  • 1/3 cup vegetable oil
  • 1/4 cup grated Pecorino Romano cheese
  • 1 (2-ounce) can flat anchovy fillets, drained and medium chopped
  • 1 (3 1/4-ounce) can pitted black California olives, drained and medium chopped
  • 2 medium cloves garlic, minced
  • 1/4 cup fine-chopped fresh Italian (flat leaf) parsley
  • 2 tablespoons drained capers, medium chopped
  • Fresh-ground black pepper, to taste
  • 1/2 cup red wine vinegar, divided
  • 1/4 cup olive oil


Steps:Preheat oven to 375 degrees. Lightly oil a baking dish large enough to hold the peppers (on their sides) in a single layer. Set aside.

Mix the bread crumbs with the oil, so that the crumbs, in Anthony’s words, “pack up.”I used my hands to do this. Mix in the remaining ingredients, except 1/4 cup of the vinegar and the olive oil.

Use this mixture to stuff the peppers, just to their tops (the demitasse spoon worked well here, too). Line the stuffed peppers up on their sides in the prepared baking dish. Drizzle with the olive oil. Cover with aluminum foil and bake in the center of the oven for 30 minutes or until soft.

Remove from the oven, sprinkle with the remaining 1/4 cup vinegar, cover, and let sit on a wire rack for 10 minutes. Uncover and let come to room temperature, then refrigerate to chill thoroughly before serving. Makes 12 stuffed peppers.

Use your talents. If you can cook, do it. It is design that you can eat. If you can’t cook, learn to some basics and build as you go at your own pace. The experience of cooking for someone is fulfilling in many ways. Mostly is all about the experience. The prep, the ingredients, the presentation…it is performance art for an audience. And anyone can do it.