Ask The UXer

A Free Clinic In London To Cure Budding Cases Of Bad User Experiences

Category: Uncategorized

Agile and User Experience: The Real Problem Is Handing Over

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.

Agile and User Experience: Two Streams

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.

Untitled.002

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.

Agile and User Experience 1: Sprint 0 / Sprint Ahead

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.)

Spint0_SprintAhead

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.

Things I’d Like to Not See Again In User Interfaces

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:

Settings screen

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:

Screenshot_2015-02-20-13-50-15 copy

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:

Screenshot_2015-02-24-16-25-05 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:

IMG_0879 IMG_0880

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:

Screenshot_2015-02-24-16-25-05 Screenshot_2015-02-20-13-50-15 copy

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.

Selection

Maybe I am too deeply connected to the Lean Startup / Lean UX / Agile UX circles in London, and what I am about to say is patently untrue because of confirmation bias, but one reason I haven’t written here much is because I have gotten very few requests of the “I am totally uninitiated in UX for my start-up” kind. It seems like tech start-ups are convinced of the value of UX from the start; the only wrangling I am dealing with know is how much to invest in it.

Still, how much to invest? What level of person to get? I have complained about it before, but I think I need to repeat it: if you are investing heavily in developer talent, why are you trying to go on the cheap with a junior or part-time UXer? You seriously want to spend your investment in dev talent to make software of which you have no idea if it will function for your target population before you release it? You want them iterating on a confusing implementation of the core idea, without proper guidance and process how to break out of this rut and start making software that fits you market?

Looking for a UX Designer just based on whether they can tart up your app or site is not going to get you the best value. It may seem cheap to get an up-skilled digital graphic designer, but the value in UX is knowing the processes with which you find out how your idea is viably brought to life, which includes helping decide for whom it is, how to find out what is important and what is secondary in your product, how to track what is hitting the spot and what isn’t, what many forms on inquiry to use to get insights, and how to translate those into something to build. There is actual science, craft, and experience-based lessons to answering these questions. Can you afford not to get good answers?

I was recently asked by a founder how to screen for a good UXer if you aren’t in the field yourself. There are plenty of heuristics, and besides the standard question of making sure you find someone you want to spend 70 hours a week with, I recommended the following:

  • Make sure the portfolio tell stories of how the questions I mentioned above were answered by the candidate in their projects. If all you see in a portfolio about projects is wireframes and finished screens, this person does not understand what UX is supposed to bring to the table, and they were just a cog in a big machine.
  • When looking at the portfolio, make sure you feel a mix of both recognition (“Yes, this looks pretty straightforward”) and a sense of innovation, and sometimes even both in the same project. You want someone whose thinking you can relate to, but who will augment you and your team in ways you currently lack.

Since I am answering fewer questions for start-ups, I will probably open this blog up to discuss the practice of UX more–as much as I can working in a big agency that wants to keep its secrets, of course.

Adding A UX To Your Startup

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.

Notes From The Field: Insecurity Behind The UX Curtain

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.

On Content

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.

Swipely Pages, A Working Demo Of A More Capable “Off Canvas” Multi-Device Layout Pattern

In his blog entry about Multi-Device Layout Patterns, Luke Wroblewski describes different layout patterns for web-sites that adapt to the device they are being shown on. These layout patterns are a central component to making a website that can be said to have a Responsive Design. Using such a pattern is not the only component to a site that has Responsive Design, server-sniffing to serve up only the right size images, for example, is just as necessary to not overwhelm small devices. The layout pattern, however, is the heart to deciding how the site is going to feel for users as they interact with different devices. All Responsive Design sites should equally make sure to send the right images for the size and density of the screen, or not try to do too much with fonts or frameworks on devices with slow connections, but different patterns are only appropriate for specific sites; and there are choices to be made.

Luke mentions the “Off Canvas” design pattern, a design pattern where the content is adapted to work on smaller screens by pushing non-essential content off-canvas. It is used well in Facebook’s mobile apps for example. The description really only discusses how the pattern works on a small screen, and doesn’t scale it up for tablets or desktops. I became interested in this pattern since I wanted something similar for a portfolio site that needed to show well on all kinds of devices.

The portfolio site is much like Facebook’s mobile experience of a central menu with different pages of content: the portfolio has a central menu of pages, in my case projects, to choose from, and then the actual project pages itself. It would be easy to follow this pattern for touch devices, but what should happen on less capable phones? And how should it scale up? Because yes, for a proper Responsive site, it is necessary to think about the least capable device first, and then scale up for better devices from there.

Re-using the work of Torkil Johnsen in making an implementation of a 3-panel “Off Canvas” design, I made a template experiment for this called Swipely Pages, it is now available on GitHub for anyone who wants to check it out. The design scales as following:

Simple phone, no scripting

On a device with little or no scripting capabilities, the menu page and subsequent pages are shown by themselves, and the user jumps between them by clicking links.

Swipely Pages menu shown in the browser of a Nokia E71.

Swipely Pages content shown in the browser of a Nokia E71.

 

Touch phone, scripting

On a device like an iPhone or an iPod, the menu loads the first page of content into a panel that can be swiped in and out of view. By selecting Menu on the content panel the panel slides to reveal the menu, and tapping on a menu entry will load the page into the content panel.

Swipely Pages menu as shown on an iPod Touch. Note the content panel on the right to swipe into view.

The main panel can be swiped into view, and swiped away to reveal the menu again

 

Tablet

On a Tablet, the JavaScript in the menu page senses a bigger screen, and loads all the links in the menu into panels that are arranged horizontally. The user can swipe between the panels, and every swipe left or right neatly aligns the panel being swiped to with the left edge. The Menu button at the top of each panel is a quick shortcut back to the menu.

Swipely Pages menu on an iPad, with content pre-loaded in panels off to the right of the screen.

Every swipe to a panel neatly aligns it with the left border. The navigation in the <header> tags in each panel is-reused to make short-cuts at the top to go to the menu or move to the next panel.

The user can still scroll vertically with a touch in each panel separately.

 

Desktop

On the desktop the visual behavior is much like on a tablet. However, swiping with the mouse or touchpad has not been implemented yet, so the user has to use the Next link to go to the next panel. Before deploying this template, the positioning of the Next link should be tested with users, and proper swiping with the mouse should probably be implemented.

Screenshot of Chrome browser showing multiple panels and a menu in one swiping page.

As said, this template and experiment is available for download on GitHub. It needs work to be used in production, but I hope it accurately shows that more can be done with Responsive Design than just re-stacking elements into the viewport.

Acquiring Talent Is Not Enough: You Have To Be Willing To Listen

Recently I spoke to a company, very technology and features-driven, around for a little less than a decade, about their need for a UX person and what they wanted out of the role. My primary contact said that they were coming to the conclusion the company “needed their own Johnny Ive”, better known by his full name, Jonathan Ive, SVP of Industrial Design at Apple.

Finding your own Johnny Ive isn’t that hard: just throw money at an executive search of top-of-their-class grads with stellar subsequent careers. However, if what you are after is Johnny Ive-class results, finding this person is not enough. History shows that Mr Ive had started work for apple in 1992, and yet, as talented as he obviously was as shown by his current output, for the next five years Apple steadily slid backwards with a confusing, unimaginative, and mediocre line-up. It was only after Mr. Ive started working for someone who put good design above all else that his output became so stellar. In 1997 Mr. Ive had been empowered by a CEO Creative Director From Hell who, for example, was willing to move heaven and earth at great cost to make the outward appearance and feel of his product better six weeks before launch, while all his competitors were satisfied with the status quo. In that kind of environment, a designer can shine and the products end up spectacularly well designed, because spectacular design has now become the end arbiter of what gets made. Not ease of production, not time-to-market, not check-box features.

It’s not just the hire that matters, but how they fit in your culture and process, what you will give priority to as a company, how you will change to get the results you are after with this hire. When asked about how they saw their new “own Johnny Ive” fitting into their company, the team was very clear they wanted the “low-hanging fruit” picked up first, instant measurable ROI, features put out there before they were “perfect”, and fixing the current user interfaces without asking for fundamental changes to the existing code-base. Basically what they had been doing already. Only if  that was in place could they tolerate the design research to be done for their new products.

I warned my contact he had more work to do for the new desired results than finding the right person.