I left London after ten years, and moved to Berlin, for various reasons. There is a lot of UX work here, but most of it is in digital B2C Product creation in the lean / Agile / data-informed variety for start-ups (or companies that think they want to be start-ups). Showing up with twenty years of product facilitation and advanced concepts on the CV meant a lot of searching to find a good fit, and I now am working in scientific publishing, enabling an internal platform for many business units.

I recently noticed a core piece of anxiety I used to have almost every day at work in London at the various agencies and clients, is gone. It isn’t just the way UX in London is so over-hyped with its constant events and conferences that makes you feel just doing your job is not good enough, but something else has qualitatively changed for me. I sat with it for a moment and realized what it was: I am not asked to do the impossible anymore.

There are a lot of ways to find joy in programming, but I think that there are very few of us for whom the joy comes from increasing conversion rates by 0.01% so the investors and founders get slightly closer to buying their sixth car.

— Gary Bernhardt (@garybernhardt) November 10, 2018

The higher I got, the more unreasonable the requirements I had to take responsibility for became. I have been the Director of UX for a client where someone included in the pitch the promise that our version of their new website would increase conversion by 10%. Just like that. Or I have been co-tasked with revamping a whole web product to be more socially conscious and long-term oriented, but then also told the lead-generation part of it could absolutely not drop, even though offering those leads were in direct contravention in tone to the new product. That sort of thing, mostly just blithely required so someone upstairs could get or keep their bonus.

So, increasing the business, not hurting the money they make, why do I call that unreasonable? The problem with those kinds of requirements is that UX doesn’t have the tools to evaluate them before the work is taken on. I have no way of conclusively starting out and saying, oh yeah I can do that. Asking me to sign up to goals I can’t evaluate, well, yeah that is unreasonable.

What is wrong with our industry that after 30 years we can’t authoritively place an OK button effectively on a page without a Build / Measure / Learn cycle?

Does every magazine page need qual interviews? Can we not lay out books without A/B tests?

— FJ!! (@fj) August 16, 2018

Every UX Researcher will tell you: users never stop surprising you. Every UX Designer who has had their stuff user-tested a lot will tell you: the version before first testing is trash. We can throw however many years of experience we have at any design, however many heuristics we have to get it right, and we will still be surprised at how users interpret some aspect of a page: the copy, not seeing a button because of the surrounding elements, the sizes of boxes misleading the eye. Add to that how every design these days is very often not the actual full page, but a piece that will be inserted into a system of modules, journeys, cookie banners, mail sign-ups, surrounding content, and unpredictable ads, and we’re unable to have any certainty even if we did have predictive tools.

But we don’t have predictive tools in UX. Just a mountain of ways to lower risk by gathering information pre- or post-design. So when during a pitch I find out I am being signed up to a 10% increase of conversion I can’t actually say No and keep my job. I can barely say “I don’t know”, really. I have gotten away with “I’ll do my best” or “Well, their site is fundamentally ten years old–I really think we should be able to do better”.

Programming, i.e. software development, switched to Agile methodologies because it turns out the intricacies of legacy layers of code and business-requirements make it impossible to predict scope and time beyond four weeks. UX design tries to do the same shortening by advocating repeating quick build-test-measure cycles, calling it a “product experiment” to “fail fast at”, but it is still not accepted everywhere, and the reason this methodology needs to exists, that fundamental inability to predict during design how good a design is, just hasn’t properly percolated back up to decision makers yet. We also haven’t let it: part of clawing our way to a seat at the top table has been putting up this facade that “finally” letting us do “proper” proper Service / UX / Customer / Product / User-centered Design will surely lower risk and increase profits by making better products. That facade is hurting us by not letting us push back against requirements we can not fulfill, and that desire for a place at the table is holding us back by stopping us from staring the business in the face and point blank asking “Instead of making me obsess over 40 colors of green to increase click-through rates by .1%, have you considered making a product at a price people actually want? Because if you did, I could hide that Buy button and people would still click it.”

But no. Industry does not work that way. Instead I carried around a tiny gremlin far away in my consciousness, a gremlin I could easily explain and wave away as the way things are, or that by the time the client would notice I did not increase conversion by 10% or whatever, we would be further along the path of doing other things. But it still gnawed at me. I only notice now that it is gone by how much.

My job now has problems of how to display the contents of a book online that has, literally, 20.000 chapters, and how to let users search in reference media without having to ship the whole catalog over in hidden javascript–meaty questions of weighing user needs vs technological capability, and how to best communicate the trade-offs and effects. It’s fun work, it is hard work, it is serious work, but best of all, when I say “I’ll see what we can do, but no promises–this is kind of weird and unprecedented and we’re going to have to make it up for a while”, everybody understands, and nobody waves a contract at me where they go “But we promised the client that…!”

‘Conversion’ is not the work I signed up for twenty years ago when I wanted to make computing easier for my mother. This is.

The first time I actually worked on something we could term User Experience, I was changing the default positions of my icons on a UNIX workstation running some version of SunOS (in other words, it was a long effing time ago) and part of that was designing some icons in black and white, pixel by pixel, for programs that did not have icons. These days I make big things for many people, and I wouldn’t release anything on an app or website unless it had been made by a trained, experienced, graphics professional, which I am not.
I used to be able to code a website front to back too, and I stopped doing that as part of all my other tasks in 2006 and now it’s so complicated you can’t just do it as a side task of many. Thinking I have the knowledge to do everything myself on an app or website to high quality is just so arrogant it is stupid.

The same goes for content. That might seem like a no-brainer, but you can tell who still doesn’t have these brains: teams who design with Lorem Ipsum, or teams on a project with more than ten pages who think all they need for their content is a copywriter.

I was there myself a few years ago inside a big agency, thinking that content is just something you quickly commissioned and wrote. I should have already totally been over that when a previous project for a car brand fell apart when they wanted a whole new website and the sole copywriter they hired wasn’t fast enough and didn’t really know what to do, so I was told I should just use last year’s copy. The result was a mess, and yet I had not learned my lesson. A huge strategic gap in the creation of a rich, vast website with existing content was staring me in the face and I simply did not see it.

At first I did not know how to deal with Content Strategists, but now I am glad the agency had the foresight to sell their services to the client who wanted a re-platform and a re-vamp that reflected the aspirations of their high-end brand, whether it was just to raise the billable hours or not. By working with Content Strategists, a whole weight fell off my shoulders as a UX Director and I could focus my team better. The whole question of what the hell are we going to do for educational content about the brand and its USP and its products, what can we re-use from the existing site, what is even there in their twenty-thousand pages, and how do we get our brand’s point across coherently, was now being handled by a group of people whose main focus was indeed making coherent publications.

They had tools to find out what was already there, and patience to inventory and tally what content users obviously already liked, or needed. The Content Strategists created criteria for what should be considered success, and failure, in an article, based on their knowledge as editors of how people absorb corpora on information. I could focus helping users find what they needed to do, they focused on what users needed to know to get it done, and then get good at it.
It is a absolutely indispensable discipline when you either know that the user has deep educational needs in the service you provide, or the client already has a vast collection of content that is usually stale and no longer to the point. Just being able to walk up to them with some existing content around a form and being able to ask “Does this live on? Do we re-use it? Is it any good?” and getting an answer based on usefulness, current use, current satisfaction, and adherence to tone of voice, sped up my designers to no end as we never had to come up with our own placeholders or use lorem ipsum, which the agency, correctly, had banned anyway.

If you are going to be content-driven, having people who do content research at the beginning of the project, based on the user needs UX and Research have worked out, is mandatory–and these days, being content driven as a site in itself is mandatory.

I am currently consulting for a large consumer-finance brand, so established and large it is basically an institution. They have their (semi-)celebrity blog on consumer hints and myths, their social content, random pages for SEO value, and more articles of which we know the user is searching for them and desperately needs education. None of it is linked through from the current web site where they have their account. What they do have in educational content inside the service part of the website is about 60 questions, so-called frequently asked. I begged for a content strategist, trying to make clear that just having a copywriter for gaps isn’t enough. I am now working with a Content Strategy team in what I consider a model cooperation.

• We worked together to agree on a view of who our users are (very tricky in this specific case, because nominally we are designing for everybody here, so we had to agree on levels of understanding, language, and progression. The usual case is working from your personas).
• The Content Strategists made an inventory of everything already there, and held it up to brand values, tone of voice, and user needs as we understood them.
• My Product / UX team focused on the clicks and buttons and page journeys for the core service the brand provides.
• We look together at these service pages and note the educational needs on each page. The Content Strategists either suggested a link, or extracts or videos from existing content, or we identified we had a gap and they started on writing briefs and getting the necessary content made ASAP.
• They showed me their plan for all the articles and frequent questions and video and info-graphics: how they were grouped according to how they saw users currently search, what educational needs they satisfied, what was already available.
• My Product / UX team worked with them to re-design a library section of our website that could contain or point to all this content according to our joint user research, from hub pages to article templates
• My Product Managers are working with the third party that will host all this content, based on my UX templates. We needed a 3d party because this corpus needs to be easily seen by our phone support people, and integrate with their phone support tools in a piece of service design. Usually the content goes in the same CMS the website is being made with.
• I don’t have to worry about porting the content, filling in the gaps, or making sure it all looks good. The Content team is on it, commissioning writers, illustrators, photography, and videographers. They write and execute the plan for governance and approval, maintenance, and adaptation of the content in the future. They got this. I don’t have to.

This all creates such an increase in speed and especially quality, that they are totally worth the investment. Furthermore, their expertise in re-use and adaptation is saving money where my UX team would have been unable to accurately identify the gaps or articulate to content creators how they should be filled.

(The best part is watching them go to a client with a presentation like “You have 20.000 pages of SEO garbage. Yes, we counted. Your users hit about 600 of those, if that. You can save a ton of money by getting rid of those 19.400 pages, and guess what, you also won’t look like cheap hucksters in a list of Google results anymore.” The look on a client’s face when they realize how much they have wasted on old-school SEO is priceless. Make sure your Content Strategist at that meeting is both authoritative and really soothing.)

What has made these collaborations so good is their knowledge gained from specialization; most of the Content Strategists I have worked with come from the worlds of journalism and publishing, where having a single voice over many kinds of content, focusing on what people want or need to know, understanding where and who your readers really are, and  how they absorb information, is a basic ingrained task. It’s where they always have lived and now live in a new medium.

I raise some hackles left and right these days when I proclaim I consider them part of User Experience (or Customer Experience, or Service Design, or whatever we are calling ourselves these days) as much as the visual graphics team or the user research team: many UX people do not understand their value yet, and Content Strategists themselves are still so isolated often this viewpoint is new to them. But I won’t work on one of the large websites I usually get asked for without them. I do not have the knowledge of what they are so good at, and I definitely do not have the time.

 

In the last two posts I described two of the ways that I have seen Agile development and UX mix: Sprint Ahead, and a Two Streams model. Two streams is arguably a form of sprint ahead, but one in which the design and development sprints are not locked in their time periods. However you structure User Experience in the development process, though, it does have to come first, it has to help define what development is going to make. Even if you have a separate research department, even if the UXers are completely embedded and blending with developers, UX guides what is made and will be developed and visually designed by interpreting research.

That creates the problem of how to transition what UX specifies to development. It is in the handover that the friction appears. What can the development team handle in the time allotted? And what happens when a hypothesis gets disproven after a sprint?

Handing over: Simple / Better / Delightful

It can be sketches and conversations. Annotated comps. Discussions sitting together. Prototypes. But somehow the concept has to go from UX to developer, even when the work is done in the same sprint by a blended team. In a recent experience, the UX work I did would feed into development cycles, but because of ever-changing circumstances, decisions about what could be put in production could change from sprint to sprint, even while the finished designs were all ready and waiting.

The team soon settled on a handover structure that dealt with this:  I would design a Simple / Better / Delightful solution, and introduce them with a thorough background from testing, research, and stakeholder input.

• The Simple alternative would be the minimum to reach the product goal, usually a very concentrated intervention on the existing product
• Better would be close to state-of-the-art, perhaps also requiring changes to other areas to create a smoother flow with this new feature
• Delightful would be all about creating a unified flow with nice micro-interactions, that would involve significant investment in smarter interactions and perhaps dropping previous product decisions.

While this sounds like designing everything in triplicate, it actually usually meant that I would start with Better, tone it down for Simple, and scale it up with what could almost be called flights of fancy for Delightful. Because of the way Agile design decomposes the work into small issues, this was all very manageable–I wasn’t designing a complete flow all the time, but features in context.

By exploring the solution space this way deeply, come decision making time the decision-maker, like the UX designer or Product Manager, can be very flexible to only go with what they have resources for to put in production. They can show the stakeholders variations together with their cost, and get buy-in for informed decisions.

And Then Everything Changes

As described previously in Sprint Ahead, for some substantial pieces of work I was lucky enough to get budget to do real concept research before the actual design sprints, allowing the design team to test some serious assumptions of what users wanted. This can be seen as expensive, but for major e-commerce it is still cheaper than producing a bad flow that users can’t understand. You do want to avoid getting to a place where you have designed the whole product as a testable prototype before design actually starts: that’s simply about not wasting money. Focus on testing only assumptions, pieces of the flow you have real doubts about. My personal heuristic on top of that is to test to disprove, and do so by testing wild concepts: conversations with users about inappropriate or magical interfaces have often guided me to the heart of their needs.

Currently in our modern Agile world, the Lean methodology is helping speed up product delivery and cut costs by doing all testing and research almost during development: little piece-meal cycles of adding and subtracting features. One thing I’ve never read is how you go from MVP to some sort of MVP+ to maybe a full-featured delightful product: the shops I see trying to get to MVP with whatever permutation of Lean they call Lean basically just keep going with the same process to get to delightful, and I am really not sure that is appropriate; it doesn’t feel like you ever really pay off the design debt incurred from only always adding little pieces together.

However, if you do insist, you will get to the point where you prove or disprove some major assumption about how your product is going to work. A recent case was making a product for which we had a tough time getting to the right specific users until we had something concrete to show, and we had to work mostly with proxies: people who knew the space and possible users really well. Any meeting could (and often did!) yield completely new fundamental insights about the user’s conceptual model. While we were building. This meant not only incurring a huge design debt, but having to pay it on the spot.

Design is unable to keep the development pipeline full, or keep it from outright mutiny, if you have to scrap everything every 3 weeks, no matter how you have structured the cooperation with sprint ahead or two streams or blending all together. It is too wasteful, and angering. Once I realized the team could end up in this situation, my mitigation (I first typed in “solution”, and it is so not) was to defer fundamental design decisions as far as possible, or opt for the most flexible solutions at all time even if they were a little more complex than what seemed self-evident, using my experience to intuit what decision could be fundamental.

An example would be in the Information Architecture: first we thought we would have four major areas of activity, so the suggestion arose to organize them as tabs. I held off strongly because tabs really do not scale on a screen very well if areas are added and could not be secure yet that users would never need to see information from both areas at the same time. I instead opted for collapsible pods that could be added vertically. A few months later we were up to 6 areas of activity, with a seventh on the horizon, and where there was significant difference in the amount of activity in each area. Tabs would indeed have been inappropriate.

In all honesty, the way I managed this designing for possible futures was by mentally, and in sketches, constantly preparing what v2.0 and v3.0 of this product might look like based on what I could extrapolate from what I knew when making v1.0. Also, every time I added something, I had to ask myself, what if this is not true later on, and have an alternative ready. I have to say that working initially on this product as a web app in a responsive design was very helpful, since responsive design done mobile first has to be so constrained in what constructs are used anyway.

In the end the process felt less like putting features together into coherent flows, but more a sculpting by chiseling away hazy possible digital futures down to a product in current reality. There were days it felt like a high-wire act, and I had to do emotional management to make sure I saw every new requirement as a fun challenge instead of a blow to the work already done. I do regret I was only around to take the product to a Beta, I really want to see what the first contact with reality, the first real tests would take it to.

In the first article I described combining User Experience design with Agile timelines by having the design team be 1 sprint ahead for a specific project. But at another engagement, the development team had a steady weekly sprint rhythm, and plenty of backlog for an already live product that needed new features and continuous improvement. Slotting design and prototyping efforts into the weekly sprints made no sense, as this pre-development work was very separate from the development team, and would not impact weekly releases. Doing user research, doing user testing, looking at comparators and competitors, trying alternatives, making a prototype, deciding on tests, workshopping and all just doesn’t fit weekly schedules, nor need it.

Our Product Manager, already brilliantly straightening out the backlog and pointing process, suggested creating 2 streams: one for design, and one for development. Each stream would have its own Jira board, but design would be kanban, and development would continue for weekly sprints. She wrote the design stories based on management, and product ideas, and prioritized them along business and user priorities, with my input on structuring the work. I would pull the top one or two design stories and put them in flight.

The design stories would be worked on with whatever tools of the User Centered Design cycle as required to finish. When a story had been explored, prototypes, tested, discussed, workshopped, the results would then be turned into by us into stories on the development board, with the designs and justification attached. The product design team, by that time, would have worked so close in the process I would not even have to present the designs for grooming or sprint planning, as the Product Manager would know all the nuances. This way, the design stories could take the time they needed, but I did have a responsibility to stay timely and keep the development pipeline filled.

Designing in the Browsers and Boundaries

One issue that we did not fully work out during the engagement was how to fit in Designing in the Browser. The visual designer I worked with on the green stream of work had also become an accomplished coder, and when we designed together he would create the designs directly in CSS & HTML, bypassing any comps stage. This means that the resulting design was guaranteed to be implementable–we pretty much had just coded it during the design phase, save for JS wiring–but some of the resources for the gray stream had been put into action before stakeholders had seen the results. The end result was delivered faster in the end by being able to skip the comps stage, but there was a certain unease that committing resources to coding had happened too early and could have ended up wasted. Unfortunately, we never got to the point where we could prove or disprove that designing in code was as cheap as whipping up a quick Sketch comp for people to approve or steer.

Next: Handing over Minimal / More / Complete

One of the issues that arose mixing Agile and UX in two streams like this was the amount of fine-tuning that had to be done after exploring and settling on a design, when handing it over to the development team and their ever-changing circumstances within a dynamic environment. Another issue was how, because the Agile process explores requirements as it builds systems, having a coherent experience as a goal could create major design debt in a moment when a fundamental assumption of the design suddenly got challenged by the result of a sprint or exploration with the client. I will address how these got managed in the next post.

So much has already been discussed about merging the seemingly unmergable: Agile, a software practice based on not even knowing what you will deliver when you start, but delivering it in small, validated, increments, and User Experience Design, which, like every design practice, is about delivering a complete, though-out, lovely, all-encompassing solution. Endless discussions in Agile about which practices to forget and how to convince your client to trust you without a set endpoint, and case-study after mock-up in UX circles about how micro-interactions are a place to shine and create cohesion between the end-to-end service experience. All I have to add to this topic are actual experiences of doing UX in Agile environments.

Agile always proposes People Over Procedures, so of course there isn’t one good recipe for making good UX happen in an Agile team. Here is my first example of a project that I thought went well.

Sprint 0 / Sprint Ahead

This was an agency project, in which the client did indeed have a specific goal in mind. While Agile classically does not like to have an end point truly fully specced and specified before you start, you can’t just tell a client “Give us your money and we’ll see what we will deliver at the end.” It requires a level of trust you just will not get at the start of a relationship. (It’s also counter-intuitive to any other transaction ever: give me your money and let’s see how much cheese I can give you. Give me your money and I will let you know when your bathroom is finished and what is in it. Give me your money and I may give you that much of a massage, or not. Yes, every project has unknowns and cost-overruns, but it is only in software that we so have no clue what we are doing that we cooked up a methodology where we explicitly state we are not quite sure what’s going on, but we’ll all do our best. And then try to sell it to clients. And it is considered best practice based on the bad results of previous methodologies. Software is truly terrible to make.)

This project had very high commercial value, and thus a lot of heavy weight stakeholders. While Agile is supposed to come with taking risks in releases and fixing them quickly, the client would rather first use the considerable star power they had hired to do Digital to give us in the agency good feedback on everything we did. We therefore made the following choices:

• The Design team consisted of a blend of digital graphic designers and user experience designers. Design would be one sprint ahead of Development. This required the Coding & QA team to trust us in Design not to finish a sprint with a design they could not possibly implement. We tried to manage this risk by including them in the scoping and pointing of Design sprints, and by giving them their own pointing and scoping process in their sprints. Looking back I would say that took a really big leap of faith from Development, and I am very grateful they did it, and that Design honored that leap.
• Sprints were three weeks, with a demo to stakeholders at the end of every week. The demos at the end the weeks were: sketches, which the stakeholders would help narrow down, for week one, further worked out half-comps for week two that could be further critiqued by the stakeholders, and fully finished and annotated comps in week 3 that the stakeholders had better sign off on at that point. Delivery management very quickly learned how to elicit the right feedback at the right time to keep sprints within their boundaries and not have to do emergency work after the last demo of a sprint.
• Before the first real sprint, Design was given a sprint to experiment, concept and research. While the graphic designers spent that time concepting and exploring the brand, we in UX explored various aspects of the funnel by sketching the extremes of how clients might make selections on various platforms, mocking them up in Axure, and formally user testing them. By involving the client in this phase, we created a shared understanding of the truisms and of what was actually false about retailing in this sector, and learned to work together. It is true that basically the client paid to receive knowledge they probably already had in their customer experience divisions, but it was only by exploring this area together, and in new ways from our fresh eyes, that we together could push the state of the art further with confidence. Erika Hall wrote a great article about how this works.
  
• We had also negotiated a week of international user testing before the last sprint so we could do major course correction if necessary. This did put significant pressure on the first two sprints to deliver something that could be quickly be made interactive to be tested (and yes, being responsible for that to happen did give me some bad nights) but it totally paid off when we could have really productive discussions about commercial realities vs user satisfaction regarding the amount of steps in the funnel, now with actual data instead of the guesswork and intuition during previous design.
  (Although it pains me that even after this success, too many people in the agency considered user-testing so negotiable with clients such that I kept having to put my foot down again and again.)

The result was a high-quality front-end design and implementation that could be dropped in and wired up by the client to their back-ends.

Because Development was at the story-pointing meetings for Design, they had their say early and could help us create something they could deliver. Still, there were some moments were Design, and specifically UX, was called over to help out with something that simply could not be implemented as designed in the time available, and required re-concepting on the spot. But hey, real-time design is always my favorite.

This was a very specific structure for a new effort, with no Business-As-Usual to work from, and heavy on the stakeholders and experts. It went well enough that we stayed the course for the second brand we were contracted to design an experience for.

In my next post, I will discuss Agile and UX working together on a continuously developed project, and then a post on how Agile requires UXers to think in versions way far ahead.

Using Gray as an indicator for Off instead of Disabled

Let me show you an example, from the settings screen on my Xiaomi Mi3 phone, running the Miui user environment:

The Recurring do not disturb time toggle button, as awkwardly as it is named, is clearly indicating with a brighter, contrasting color, that it is set to on. Meanwhile, that Do Not Disturb toggle above it registers to me as disabled: it is grayed out and faint, conform to how functionality being disabled has been indicated since the first Macintosh. Well, guess what, it is not disabled, this is what the designers of this system decided off should look like. If you tap it, it will slide to an on state like the toggle below. I have no idea what an actually disabled toggle looks like in this system.

This color scheme goes against thirty years of accepted standard in visual interaction design, and I am disturbingly seeing it more and more. As interaction designers we are turning every interface into a place where users can’t see what can actually be done, what is available: we’re just asking them to swipe left and right anywhere and hope they discover that something might happen.

This mistake is a very strong indicator a system was never tested with actual users. It’s amateurish, it is a beginner’s mistake. An off button that can be switched to on must advertise it is ready for use, and making it faint and gray does not qualify. Don’t do it.

You see this flaw crop up a lot when a company insists on both having very few brand colors, and that no other colors should be allowed in digital. I had one of those in the last year: it’s primary brand color was a form of red, and only gray and black could be used with it. They wanted us initially to use that red to indicate on or selected. User testing immediately showed what everyone already knew: a control that turns red is actually seen as being wrong or unavailable. We had to have long conversations before we could use a second color, not on that brand palette.

Placing Titles And Buttons So Close Together The Button Takes On The Title

This is a result of pushing minimalism stupid far, and it is just so confusing. And it is all over Android right now.

Example, from Citymapper, an independent app maker:

When I look at the title bar of this screen, I see a control to click to go back to the results screen. That is actually not right, Results is the title of this screen, and that left arrow is to go back to whatever you came from, if you remember what it was. But that is not my first impression, nor the whole gestalt of that title bar, to me it says ‘go back to Results and god knows what it is you are looking at here.’

This is actually not the result of an independent app maker breaking interface convention: Google, owners of the Android experience, actually meant for this arrangement. Here, a screen shot from one of their workhorse apps, GMail:

To me this title bar says: tap the arrow to go to the Compose screen. It isn’t, we are looking at the Compose screen here, and that left arrow goes to whatever.

iOS, while hideous at doing it, actually gets this right:

I see where I am right now, and I see where the arrows are, and where they will take me. Yes, it is a busy title bar, with a lot going on, but I am not left in the dark. The worst is how unnecessary Android’s confusion is; with just one tiny adjustment this could have been so much better:

That’s it. That’s all it takes: moving a label to the right and adding a single line of white pixels. Done. We know what is title and what is control and how related to each other they are (they aren’t). Ok, so the arrow still doesn’t tell you where it goes, but the back arrow on Android has been a messed-up magic mystery tour since its inception anyway.

Last year I consulted some on hiring decisions: what kind of UX person do different start-ups need? It certainly is not a one-size fits all decision. Even if the all of us were perfect blends of insightful user researchers, interaction designers, amazing illustrators and graphic designers, and hardcore coders (also known as ‘unicorns’ since they do not exist or are very rare), we would still not all fit everywhere. In fact, for most start-ups that combination of skill at that high level would be completely over-specified and those unicorns would be both bored and overworked. Bored because not all the work would be at the level they like to do, over-worked because invariably they would be asked to do the work of 3 people.

From observing start-ups you certainly want someone who can grow with the company, has the right energy and endurance for start-up life, but also brings the right mix of skills at the appropriate level for where the company is. And just like as a founder you would research (if not already know) the various disciplines that go into creating working, maintainable, source-controlled code so that you know what you need, you also need to either be well versed already in, or at least research, the various design disciplines. The sentence “Well, we need the interaction made simple, but they could also design the logo and slide templates” makes me worry.

On top of that, “design thinking” as a system to create new and better products at start-ups is very fashionable, but it means more than hiring a Graphic Designer early, or even as a co-founder. If you do not have a background in design, learn who these people are—even if by asking an expert.

Founders who are tech experts really need to evaluate designers, interaction or service or visual, by the same lines as they would coders. What level would they hire, how much do they think they can teach or need already be supported by? Would you really pay a lower salary for someone who brings the look, the feel, the ease of use that sets you apart, the experience that makes your site memorable and instills trust in your website so clients spend money on your services? I was a little surprised at one point when the salary range quoted was equivalent to one for a junior coder.

If you are a Designer Founder yourself, you can grow together with a junior or mid-weight, but if you re a Dev or Biz Founder, you will not be able to really grow your junior designer; in contrast to what many think, “Make it pop!” or “Make it easier!” or “Make it like Facebook” are not actual design critiques that will get you a good result from your new worker nor will it make them better at what they do over time.

The level and experience need to be the right fit, but so does the approach to problems, and it actually should be different from the code or biz team, creating a frisson from which new ideas and directions will spring. Evaluate this from the portfolio, but mostly by asking how problems were approached, and approaching a current issue in the start-up together. Never ask a designer to do a lot of homework for the interview for free; in the current market it comes off as exploitative. Pay a free-lance rate for a few days to solve a bigger problem together and try. And ask other friendly UX Designers for help in evaluating.

In his latest blog post, Boon Yew Chew bravely and honestly discusses the reluctance he has to use the term User Experience Designer for himself. We have talked about this a little bit more on Twitter, but there are certain elements of his post I wanted to think a little more about, and why not think aloud, right? We UXers ask that of our user-testing populations all the time, after all.

What do we know?

Much of the insecurity I read and see, when UXers talk about their advanced cases of Impostor Syndrome, is actually because we do not have a canon. There is no basic shared knowledge that is indispensable to have in this field, there are no rules and laws and basic theories from which the rest of our craft flows, really. There are tons and tons of ideas and guidelines and processes with deliverables and artefacts, but there is no underlying model that we need to know in order to do good work, and therefore there is no hook for us to hang our security in our craft on. Yes, I have studied Fitts Law and I know about the 7+-2 rule, but guess what, I almost never use them in actual practice. To the point that I can barely tell you what Fitts Law even is, and as a mobile-first designer, I actually do not even care anymore because all my targets need to be visible and fingertip-sized anyway.

Back in the very early nineties when I started studying this field, people who had been tasked to make user interfaces for their companies but felt they had no guidelines and no background, asked me if there was a unifying or basic theory of User Interface Design, or Human Factors studies as it was called. Twenty years ago I had to say no, because what that basically was asking for a fundamental theory of mind and cognition, and neuroscience hadn’t come up with one. We still do not have that in what is now called the UX community, we just have compendiums of thought like “Don’t Make Me Think” and “The Lunatics Are Taking Over The Asylum”, but a basic theory what makes a good User eXperience, statistically solid and lab tested, or even a simple process that practitioners can follow to get significantly better results? All we have is variations of research-produce-test rinse repeat, which is what all the new Lean UX or the About or Our Process pages of Digital Agencies come down to. Just look for the diagram with arrows in a circle.

It is hard to feel secure in what you are doing when what you are doing doesn’t really have strong fundamentals like, say, Medicine or even Economics. For all the flack Economics gets, a lot of thinking has been done about basic theories of what actually is money, what are good exchanges, or on capital and work. And it may often have shaky predictive value, but the field can at least talk about models and predictions, something UX as a discipline can not. I remember work done in the 70s and 80s–I even did my thesis based on some of that–about systems to tally concepts in a command-line User Interface so as to be able to predict whether it would be easy or time-consuming to learn, whether a user would be fast or slow in it. That work has now completely fallen by the wayside in the larger practice of making web pages and mobile apps. Can I call myself an Economist without being able to explain how Marx saw the relationship between work and capital? Not very credibly. Can I call myself a UX Designer without knowing the inventory of ways to visualize repeated data sets as explained by Tufte? You bet. Many UX Designers have no idea what happened before 1998, and rightly so as there weren’t learnings fundamental or rigorous enough to stand even the test of time, never mind any actual lab test, in our ever changing computing environments.

Next week everything will be different

We publicly pride ourselves on how our varied backgrounds, the many routes we all took to become UX practitioners, makes us stronger when we work in teams, but it does mean that the field therefore has a lack of coherency, or even shared values beyond “we want to do right by the user”. Then the field changes in five years in some fundamental fashion, and some new people feel their current process or insight isn’t covered by the existing field and we all need a new fashionable term to go to. (I remember when Information Architect first popped up. I have to admit my first, and in hindsight vicious, first thought was “Card sorting as the whole of a job description. Nice work if you can get it.” And then it took off and I had a new title to collect. And yes, I have seen the error of my ways.)

Or our tools change, and because everyone is so insecure, or because they are recruiters trying to make money in a field they just walked into without any knowledge, we all pretend they are vital to have had forever. Little secret: when I arrived in the UK in 2008 from having designed and delivered sites and desktop applications since 1995 in the USA, I had no real idea what Wireframes were. I had to look the term up when I saw it in job ads. As someone who worked in User Interfaces–oops, sorry, User eXperience, there was one of those shifts again–from a software engineering background, whenever I had an idea or a design for a UI I would just code it up and see if it worked. At most I would sketch on paper first. Seriously, this whole in-between wireframing stage did not exist for me, and I had to study it.

So I took some of my old work and made some wireframes for them retro-actively. Can you wireframe? Oh yeah you bet! and I got me some gigs. I have now spent considerable time working with this deliverable, but I can’t say it has advanced my thinking or my results beyond my pre-2008 process. Yet this deliverable has become so important that you can get or lose out on jobs depending on whether you know the exact wireframing tool in use inside the company. Wireframing as a deliverable is now less fit for purpose than ever in a world where the transition from one state to another in a website or app is the real interaction deal-breaker, which wireframes suck at demonstrating. I am wireframing in my current gig, but only secure in the knowledge that the programmers to the right of me will code up an interactive element for testing when I verbally explain to them how it will work in the flows, and the amazeballs colleague with a Visual Creative background to my left will turn our collective ideas from the prototypes and wireframes into a deliverable that does make sense to people. I may user-test my ‘frames, but only with me doing the test with the user as I know all the caveats. I am sure wireframes will fall out of fashion and be replaced by something else (please!), and then recruiters and hiring managers will talk as if Everyone Has Always Done This In Our Field about the new thing.

We are about tearing ourselves down

User eXperience Design is the art of making things that are so blindingly obvious everyone wonders why this would take longer than an afternoon to come up with. Everyone except the people who made it, that is; they know how they went through iteration after iteration. And the only way to do it by constantly exposing what you sweated over and thought about, to ridicule and scorn for being too difficult to use, in user tests. User testing in all its forms is all we got, and we have to do it, but as a practitioner it is actually not that fun to have to go down in flames repeatedly. In front of your colleagues. And manager. Who may not understand that this is what the current UX Process requires, because we have no models to work to, and you end up wondering if they are wondering why they are paying you if you can’t get it right the first time already.

We end up in the strange position where we have to advocate to the organization to make resources available for us to find out how bad we are. I once, at a start-up drinks meet-up, explained this process to an accessories designer. She couldn’t believe her ears and didn’t think she could have gone through with it. Throwing yourself to the wolves in public every time? “Well, yeah, kind of. You never get it totally right on the first try, and there is no other way to know which part you got wrong.”

So yes, when you can’t get full buy-in to make proper testing happen–we have no time, we need to get to market, this is so simple, we’ll release it as a beta, it’s Customer Development, we have no money, can’t you just make it simple the first time?–sometimes it takes having to be in a UX community to remind you that you must still test somehow. It’s easy to let that slide. I have raised plenty of eyebrows by judgementally proclaiming that “If you are not user-testing your design, you are not doing UX, you are just doodling” but even truly believing that I have to sigh hard and steel myself before every time my designs will be seen by fresh eyes that have instant opinions about everything. How hard we worked, in the end, doesn’t matter, just the result.

We don’t really do this in the best circumstances

Even though I try to explicitly style myself humbly as a co-designer–“I am not a guru. I have done research but I do not know everything about this field. You in my team are the experts, and have lived with your ideas for a long time, longer than me. I am just a conduit to take all your ideas and shape them into something usable by other people in your field”–instead of a designer expert sent from heaven, I still end up in many situations where I feel “I should have seen that coming.” I was talking to some very respected colleagues today about a situation where I, with the team, after a week of sweating over some interactive function, collating all ideas into this one workflow, got shot down on a phone conference at Friday 5PM with a remote division manager who had a far simpler idea.
–“And of course now I am thinking, he’s right, he’s just right. And wondering what he thinks of me that I as a so-called User eXperience expert didn’t see that solution myself.”
And my friend correctly says: “He could only see that solution because you made an artefact that showed him the problem.”
–“I still should have come up with [that simpler solution] myself while making the artefact.”
“So why didn’t you?”
–“I was too close, I guess,, too enmeshed”
“Exactly, and he was far and gets to see this once a week. You need distance for these insights. We don’t get the time to take that distance when we are on a project.”

And in reality, especially inside Digital Agencies, the client doesn’t want to co-design all that much with you UX expert. They want to give you some knowledge and then have you show them a solution like you promised you would in your tender, for that specific amount of money. Innovation? As long it fits in that one week you budgeted between research and wireframing the home page, and by the way, budget is shortened because the dev team says they will cut more, so that week is gone, just come up with that Wow-On-The-Richter-Scale (actual client quote) while you wireframe. Digital Agencies work best when they have a close, iterative relationship with the client, but they only get that when they prove themselves in the first project which, guess what, happens with the agency frantically trying to find out what the client knows so deeply it actually can’t articulate it to outsiders, and only getting to it by showing designs to the client that the client will initially be unhappy with. Client churn is basically a given. It’s only if you have a stellar Account or Client Services manager on board, who can make the client understand this is how the process works, that you get a second gig.

It is really no wonder that we are so loyal to, and count ourselves lucky when we end up in, a business or even division that truly puts the user first, over profit or retaining the client: the people running them know what we go through.

What we end up with

So, we don’t have a truly shared body of knowledge and predictive theory to feel secure in, just an ever-changing field that keeps making stranger and stronger demands on us as the devices that provide user experiences explode and span the gamut from whole walls down to wrist-watches. Our job, when we are allowed to do it in a way we consider right, is about breaking our own hearts and having our babies killed in plain view of everyone in our teams and labs, repeatedly, until we get it right already. When we don’t get the tools to do this process, we labor under the knowledge we are probably making utter crap, mediocre at best, unless our colleague at the desk next to ours, if we even have one and aren’t the lone UX designer, will be brutally honest when we let them take a look. We are surrounded by people who have opinions and of which most think just making the right pixels prettier will solve everything. There is constant in-fighting in our field about what it is we should know (coding? visual design? taxonomy management?) mostly by people who don’t know one area and thus need to be heard saying that the area is not necessary lest they end up without a job. And we hardly ever have the luxury of time or space or variety. It’s not surprising we often end up measuring victory by getting one little good piece of innovation included in what is yet another mediocre site. It’s basically what Dribble was made to showcase.

It is also not so surprising then that many UX designers can hear themselves asking their friends and colleagues “Am I really a Designer? Am I a crafts-person? With no theory or real process? And if not a Designer, am I the best UX person I can be? Can we all do better? Is this new book / pamphlet / site about ourselves / process / intermediate step with pretty pictures going to be the key to stop us from flailing and make us get to good results like an arrow?”

Honestly, I wouldn’t sweat the name and field much. That you care about making software and services a little less heinous to use is what makes you a UX practitioner. Document your ideas and solutions into a portfolio, go to some workshops and meet-ups, and most of all, talk to other UX practitioners about the work. If with all that you have enough of a story you can get someone to pay your bills doing the UX work, then just call yourself whatever is in the job title for a while.

Every job, every field is a racket. We are all winging it, from brick-layers to CEOs. We might as well then wing it in an area we love.

You know, the thing your users actually come to your website for? Here are some guidelines from actual experience, both in my day job and these consults.

1. If you have a content-heavy app or site, plan for making content as soon as possible. I don’t mean make space on the project chart about when you will make the content, I mean go get the content first. Go get it made, go get seed content from proto-users, trawl all the free content you can and suck it in to use, go copy some content from a competitor that you will replace before going live, and for god’s sake, most of all, if you need to get your content from other sources, go close your content deal first and know how you will pay the source so at least you can design the space for banner ads or interstitials well.

   You can’t wait with this. If you do not have the actual actual content ready to go when the experience is being designed, your design will be half-assed mediocre, just like most websites we see today, because the content and the design and the visuals and the everything are not coming together into seamless story-telling experience, but are being slotted together and then the seams papered over in a way you may not be able to see, but can feel as you use the site.

2. This goes double if your app or site has to adapt to many screen-sizes. Designing for multiple screen-sizes and modalities, whether called fluid, responsive, adaptive, whatever, leads to nasty nasty surprises during testing, at best. At best. If you are not designing and testing with actual content, you are not in the ‘at best’ situation, and you will get burned.

   Maybe you can design with content that will be just like the content you think your users will make or your content deals will close, but oh boy, you’d better be right or there will be a lot of last-minute pain, and again, a mediocre site for quite the number of people on some of the screen sizes. You simply can’t make good decisions about what is important or not, what can be hidden on what screen, with Lorem Ipsum.

3. Oh yeah, Lorem Ipsum, the fake content we designers use to fill space. Avoid like the plague. It is too seductive to mix and match and edit it to make it fit into exactly the space and alignment we want. This is especially a huge liability sites with user-generated content. I remember the time I got a design for an experience that I was supposed to implement—when I still did front-end dev—and thought “This design is not going to survive contact with reality,” so neat as it was, so nicely as the purported users wrote paragraphs, allowing for an even rhythm of elements. Of course it didn’t the moment actual users wrote single-line posts and ranting comments.

   Copy content from competitors while designing, if you do not have any of your own. Release a provisional ugly site, a test experience of some kind, to get example content from your target audience. Beg your friends. Anything. Just stay away from Lorem as much as possible unless you really really know your stuff and users.

4. No brand names or technical terms as headlines or menu entries. I can’t tell you how many designs I have tested for clients that fell completely flat because users could not immediately guess what a menu or page or paragraph under some smashed-up-words term would lead them to. EcoFlight. VariPump. GlossTram. Those kinds of words.

   I know you paid an agency buckets to come up with these perfect words to capture some aspect of your product, but believe me, they do not invite exploration. People will not be tempted to read deeper to find out what your term is and they won’t open the menu that has that as a header; instead  they will flee to a site that doesn’t make them feel unwelcome and think so hard. I made this mistake myself, and 12 out of 12 tests I had a user just blankly staring at me, at my site, back at me, back at my site, and telling me they didn’t think this whole site was for them so they were already turned off. Learn from my mistake.

5. Get either content, or get approvals from the stakeholders to make your own, but get one of the two. I know, this is utopia in a client-agency-designers environment, but if you really want a kick-ass digital experience, you need one of the two. If everything being made has to be written by group A and then signed off on by group B who actually have to punt it through to group C higher up first, then tested to find to not work for users—too many brand names in the title copy and menus and voice-overs—and then have to do it all over again and again, you will either blow past deadlines, not test enough to make sure the experience connects, or end up hurting some aspect of the design.

   If you have to make a new lawn-mower site, get the understanding, the deep knowledge, the love, the differentiators of the lawn-mower first—or at least the copy. Don’t go designing wireframe pages of lawn-mower image here and Lorem Ipsum there ‘to be filled in later’, because you will not be telling the story of this lawn-mower as effectively as you could, and your site or app will simply not make the makers of the lawn-mowers happy and they will get irritated and stingy. Know this lawn-mower inside and out, be able to sell this lawn-mower better than the makers, and only then go plan their mobile lawn-mower app. Yes, you will want a copy-writer to tell the lawn-mower story well, but they should already be deep into the lawn-mower prose and getting it approved, or getting the internal prose first and reworking it, before you start working on this app. If you are not guided by the Content in your design, what the hell are you being guided by?

   You want actual utopia? Get the stakeholders to make the content with you, be in the room as you make the site, or a Skype or email away, the actual people who have the power to sign off, not their delegates who will have to pass things up anyway.  Get the people who designed the lawn-mower and put their heart and soul into it. The reason start-ups so often can make such awesome tightly-designed experiences is not because they have no baggage, it’s because everyone is in the same room co-designing: the people who know the product so well they can sell it together with the people who know how to tell a great story digitally. If the people who all tell the story are not together, things will slow down or hurt.

6. Don’t re-use content and hope for different outcomes, like a better website or app. If the content didn’t work the first time after a lot of effort, more effort won’t help much. If, as a client who wants a new digital experience, you feel your current site or catalog or app is shit, don’t cut corners. Get your new content done, get your agency or in-house designers deeply embedded in the feel of what makes your product great, and only then let them start.”Just use the copy / images / video of the old site to lay out the pages, we’ll get the new stuff later in place” is just not going to get you anything new and great.  Seriously consider dropping a gig that has this as its premise. Trust me on this.

7. Can’t make any of the above happen? Shell out for really experienced people (hi there!) and make room in the plan to in Phase 1, yes, 1, do everything over again.  Or choose to be mediocre. One of the two. No, don’t think the great redesign will happen in Phase 2. The only companies that have Phase 2 are Agile software companies. Nobody else ever has a Phase 2, not for an external digital project, and not for an internal one in a waterfall environment.