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.

Advertisements

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.

20170512_180505

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

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.

yoda

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.

 

 

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.

low_wireframe

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.