He now identifies as a journalist, but was born naked, hairless, and unable to control his bowels.
He now identifies as a journalist, but was born naked, hairless, and unable to control his bowels.
Neither Google Analytics nor Adobe Reports & Analytics recognizes Playstation 4 as a device, operating system or browser.
In Google Analytics you can create a custom segment with the following constraints to only show visits from PS4s:
Operating System: contains “(not set)”
Browser: contains “Mozilla Compatible Agent”
Browser Version: contains “5.0”
Screen Resolution: contains “1920x1080”
How to solve this in Adobe Reports & Analytics is left as an exercise for the reader, because I can’t freaking figure it out.
This may seem obvious, but I looked for this for months before finding it by coincidence. If you are stuck using Lotus Notes you are probably not surprised by someone having a hard time doing anything at all in this convoluted nightmare of a system.
Anyway, to enable full-text email search:
Many designers, me especially, have an unfounded fear of selling. We’re solvers of problem and creators of solutions, our thinking goes. We’re not sleazy salesmen trying to wring money from unwanting people. Our designs are work of truth and beauty and should practically sell themselves.
Ok, I’m not really that naïve, but it’s not that far off base.
The solution might be a change of mindset. To not see selling as pushing crap onto unwilling customers, but instead think of it as helping people finding solutions to their pains and problems.
Design does not start with being handed a defined problem, but somehow I’ve always thought of finding a troubled client as “not my job”. Even after realizing that design is not just a craft – it’s also business – I’ve always thought myself too junior to try to sell our services. Or too timid. Or simply too afraid.
Afraid I’ll do it wrong. Afraid I’ll come across as a slick used car salesman type. Afraid I’ll just scare the clients away.
Anyhow, to help me and other sell-o-phobics, I’ve found two helpful books!
Spin Selling by Neil Rackham – Disregard the “selly” name and the horrid cover. It’s a great book, based in extensive research. It discusses the difference between what’s effective in small sales (used cars, magazine subscriptions and other things that most of the time can be sold with just one conversation) and major sales (website redesigns, fleets of trucks, apartments and other sales where seller probably won’t be present when the final decision to buy is made). It also makes it clear why traditional pushy selling, focused on “closing”, does not work when selling design. Most of all this book really helped me see selling in terms of solving a need.
Spin Selling is available as a hardback on Amazon, but I would recommend the abridged audio book available at Audible.* I’ve listened to it twice. The narrator is a bit overenthusiastic, but you get 3 hour of interesting listening. Some parts are a bit repetitive, but the plentiful nuggets make up for that. If you aren’t already a Audible customer you can get the book for free with your free 30-day trial.
Design is a Job by Mike Monteiro – Actually, I’ve known about this book since it was published, but only took the time to read it recently. I should have done it earlier! It’s a short & sweet read, and Mike is a great writer. The book is full of no-nonsense advice, not only covering selling in the sense of getting clients, but also points out the importance of selling, not just presenting, your design. Mikes source of knowledge is decades of mistakes made working in design, and he’s not afraid to share.
Working in User Experience empathy with the users of our designs is second nature to us, but Mike reminds us of the equally important empathy with our clients. Clients are not the enemy. Bad design is.
The best thing? The chapter most relevant to this discussion, Getting clients, is actually available for free online! I do recommend you to buy the whole thing though.
So, did the books help? Sure, I’m no longer pathologically scared of the concept of selling, just nervous about the actual activity. Roleplaying selling our design services with my colleagues while drinking beer after work sure helped with that though. :)
No more Mister Complainypants!
"All things are true, even false things." -Principa Discordia
David Deutsch says that we choose theories based on their explanatory power. The study of mythology, through a myriad of cultures and peoples, reveals that we choose our myths on the same criteria. Myths that endure have the power of explanation, repeatability, and often some point to more healthy social or individual conduct. In our common stories we choose success, and experience it as learning. This creates an odd dichotomy that’s hard for the analytic perspective to process. Myth is rarely or never factual, but always or nearly always true. The use of myth as a data source has a controversial history as a result.
User mythology is a set of received or generated knowledge based on the experiences of a user base. A user base can be one person or the entire user community of a product. Users create stories about their experiences in the often inscrutable world of computers and the internet all the time. Those stories are refined, reformed, and passed on in accordance with how well they explain what the computer is doing, and how best to handle it. For instance, a computer that is swapping is often perceived to be “thinking very hard”. Both novice and expert computer users, even those who know a computer does nothing close to the process of thought, will interpret a swapping or slowed computer as thinking very hard. This metaphor is so useful it often supplants known factual data- namely that computers don’t think. User mythology is part of the cognitive process of routing around trouble, or optimizing conditions for the user. By the time a myth gets around a user base it contains some important truth about the software or hardware which has survived the test of multiple perspectives. That myth has optimized the program, the environment or the user his or herself, the codification of that optimization knowledge creates a mythology.
People are continual myth creators. Their interface with technology is no exception- the body of use mythos is incredibly rich and voluminous. It is an organic knowledge base, shifting and changing continually. It is highly gestaltic, and little can be gleaned from this knowledge base through reductionism and careful measurement. As a result the formal sciences which have influences the field of user interface neglect this body of information. Somewhat understandably- we haven’t exactly exhausted the more concrete avenues of understanding yet. The field is very young and as of yet has never generated a principle of uncontested repeatability.
The interesting part about user mythology (beyond the rich aesthetics of all mythology that is) is that it is true, and it is the truth which is often not obtainable any other way beyond learning to interpret the mythology. It is the language that users speak to the creators of their systems in, and the language they speak to each other in. We in the UI community have spent years focusing on how to speak to users in their own terms- but far less time trying to understand them in their own terms. An example from Jared Spool’s research on website usability illustrates the importance of listening to myth.
It was long the accepted and established fact that no one would wait for a website. Users wanted sites to be fast, and often raged critically when they weren’t. For years, everything was about page weights and loading time. Jared Spool decided to actually study people’s perception vs. The actually time it took a page to load. He found that the perception of speed was almost always inverse to actual speed. The slowest pages were often perceived to be the fastest, and vice versa. People were definitely consistently frustrated with “slow” sites, though- he had stumbled upon a common mythology. It would have been easier and more obvious to simply conclude that speed in fact wasn’t what users wanted. It would have been factually accurate, as well. Fortunately for the field he interviewed his subjects to find out what the positive myth of speed really meant. What he uncovered was the user’s the expectation of a successful experience was quantified by the idea of speed. Indeed, many of the slow sites were the fastest- when it came to acomplishing a task and being freed up from needing the computer anymore. This idea helped refocus website usability from simple speed to successful completion of tasks. As a result, the web got better. (if not actually faster!)
Everyday the field of UI is struggling with uptake of our work by the user community, and often in the dark. We don’t know why many things fail, even in retrospect. The best we work with on many occasions is a smattering of data and our own gut interpretations of both our data and that work. We are working in a field before its founding. There is no adam smith or sigmund freud of UI- no body of unifying work which we can act and react and build on. User mythology is important above all because we need all the help we can get.
The most unclear part of a theory of user mythology is how to effectively apply it. User mythology carries a lot of psychological and linguistic baggage without much discoverable significance, much mythology will always be inscrutable to the UI researcher. Also, getting usage stories out of the userbase is getting harder. User’s stories are so often rebuffed or ridiculed for not being factual and literal that users have become hesitant to honestly and openly tell their stories. Once we do have a body of mythology to study the task is made even more non-obvious by the context of the creator’s own perceptions about how the software or system work. Viewing these stories objectively requires a mental gymnastics few of us are trained in. The first step to understanding a mythology is therefore to assume it contains a view of reality you’d like to know better, and ask yourself, “how is this true?”. This is a powerfully different perspective from the analysis many of us are trained in. We spend much of our live evaluating for truth and falseness. Often asking “how is this true?” is a frighteningly creative process- you find yourself making up stories without much data behind them to build a bridge between the user’s point of view and the creator’s. It’s important to remember that this is what the userbase has been doing all along. Building a bridge between the literalism of computer science and user mythology suggests its own applications, beyond a better understand of the total environmental system of computers and users. Information derived from it can demonstrate factors of the software no party is conscious of. For instance, an avoided area of the program or an elaborate ritual can suggest a coding or interface bug undiscovered in the development process. A mythological portrait can suggest the direction for the next generation of a piece of software. Stories often contain the kind of wish fulfillment that suggest UI changes and new features which will be enthusiastically taken up by a user base. Ultimately, it is my hope that a high level and ranging analysis of mythologies will point to universal and generalizable principles of interface and mature the field.
Simply not enough user mythology has been documented and studied to say how useful this knowledge is in the field. What has been studied has often revealed surprising anecdotal results, but how far that might go and how universally it may be applied can’t be predicted yet. My hope is to see more user stories documented and shared and serious thought given to them. Until then, we UI people guess and test on.