The "Think System" or Systems Thinking

The Music Man (1962 film)

Some Agile coaches come in promising that if you just trust in the old Agile Methodology everything will magically happen. I’ve seen this happen twice with the same coach at large companies. He’d been coaching since the earlier days of Agile, when it was more appropriate method for small start-ups or small teams trying to get something quick out the door. Over the past decade Agile has become a common mantra of big organizations who are trying to solve the time-to-market issues of their old approach which is usually associated with the Waterfall Method. Because of the pains and complaint they get about time-to-market, they’re easily sold on the idea that if you just trust it and don’t look outside of your 2 week sprints, once you’ve done it long enough you’ll end up with a wonderful magical new system that just works. Both times, what the coach had sold the organization failed and the teams realized a need for a comprehensive approach. Something akin to knowing that you’re taking a road trip to somewhere and estimating how long you might drive each day; without falling into the trap of either a) planning every mile down to the minute or b) taking a Kerouac-esque trip to… we’ll know when we get there.

This rage against Waterfall reminds me of The Think System, from the old 50’s musical The Music Man. A bunch of townspeople are so eager to hear that their children are musical geniuses that they believe a talentless con-man who tells them that if their kids just “think the notes really hard” they’ll be able to play them. Only to leave town with the money before the first concert. This reminds me of those Agile coaches who are more interested in “coaching” you than in your result. Not saying that all Agile coaches are bad, some are quite excellent, but the truth is in whether they are more interested in getting you to practice the method and trust them than worrying about the fact that you’re actually building something specific with critical real-world applications that will make or break your strategy. Just like if you hire an agency to design your product for you; they’ll potentially be more interested in impressing you and getting that quick win, than integrating Design Thinking into your entire organization. If you're not starting out with something akin to Systems Thinking (see Wikipedia), you probably don't have a good idea of where you want to go. And unless you're Kerouac, that's probably not a good thing.

So, if you’re trying to build a $100 million system or if you’d like to achieve a great User Experience using this pure Agile concept, I’m sure you will perhaps get there after about 10,000 sprints. But that goes against the whole reason for adopting the Agile Methodology in the first place. The point is, getting something out the door for a quick win can’t be your main goal, unless you're boot-strapping the next big thing in a shed near Silicon Valley. Speed is critically important, but unless you have an idea of the complete eco-system, including your User Experience Strategy you are bound to keep fixing problems instead of innovating and building towards a greater whole. And your product will undoubtedly suffer.

If you know what you're trying to achieve (in the big picture) and what your priorities are (in context), you're going to be be able to plan and deliver better than either of the other options.

Good UX is all about 'Innovation'

Good UX is all about 'Innovation'. This is not to say that UX has to be innovative to be good, but it does have to evolve properly to achieve the right result. 

One of the things I've learned, from designing products and systems for a wide variety of companies over the years, is that the initial expectation is that you will come in and churn through a few requirements each day; putting each brick in place and finally arriving at a complete product. This is usually done once they realize that there is a need for UX and isn't always done with a lot of forethought. While this is certainly a proven way to get a job 'done', it's just as likely to produce the least innovative result. In many cases delivering little more than a reprogrammed/refreshed version of what they might have already had. Being able to fundamentally re-think how a user interacts with a system means understanding both the system and the interaction as a whole, not in a step-by-step basis. We live in a three dimensional world, not a one dimensional one; so why do companies naturally approach their UX as if it always follows a one dimensional 'wizard' like flow?
Some companies prioritize the guaranteed and predicable method this gives you because of their size and the amount of money they invested in the project in the first place. In other words, they're so afraid to fail they forget the true meaning of innovation. There are of course other reasons for this approach, like tackling the limited set of requirements that business has already signed off on and the immediate need for delivering UX artifacts to the developers in waiting. (Whether development has other building blocks they could be working on is a separate discussion.)

This would probably explain one of the reasons smaller companies (or even more often, start-ups) seem to be able to innovate so easily while others try and try again to replicate the same results. Leading to the frequent need for the larger, more established companies, to acquire the smaller ones for their innovative solutions to help put them back on the fast track. 

Many larger companies have started to adapt the Agile Development Method in order to try to capture the magic that allows smaller shops to bring better stuff to market faster. While it works for getting stuff done, I have yet to see a case of pure Agile Development of a multi-million dollar project leading to an innovative User Experience without some major advance planning of where you want the UX to go. You either have to plan ahead or you will no doubt end up with some major UI rework at the end, which often forces a project to go well over-budget.

Some companies of course are more hampered by an existing customer and partner base so vast that it has little choice but to keep the status quo while trying desperately to also add innovation to an already complex suburban sprawl like environment. This complexity aside, it is always possible to look to the future and set your company on a path to more innovative and up-to-date customer experiences.

So, how does a larger company innovate and still stay on the safe path?

The solution that most often works for me sounds quite simple. UX is holistic; so designing as you code isn't really much of a UX strategy. Since much of the perceived bottleneck (or pain-points) of a UX team is producing the wireframes themselves, especially in Agile, you need to change the understanding of wireframing. It's not something you do to merely illustrate where buttons and info go on the screen. If that is all you're doing, you're doing it wrong; well, at least in the context of User Experience. 

When it comes to wireframing, if you truly want to be "agile", you should sketch out the general functionality in advance of development in an iterative way. The goal being to understand the users and the system goals in context of the whole experience. If you think of your wireframing stage as a mini-"Agile" design phase you can more quickly visualize and test out the intuitiveness, simplicity and complexity of the system cohesively. This allows you to more quickly verify the fundamentals of your UX in the same way that you test out your code at the end of each sprint.

In most cases, the up-front iteration on your wireframes is more than made up for by avoiding the constant daily struggle of trying to solve UI problems (and later re-work those same things) within your scrum teams. It is also an extremely efficient way to manage your UX Strategy and User Interface when you're dealing with several development teams working on different parts of a much bigger project.

Rethink Simplicity

Some say that UX designers live, breathe and eat product design.  One thing I know for certain is that we can't not analyze everything we interact with.  Whether it's a door handle or a car radio.

Recently, I started working on a project for a large hospitality company.  Since our project wouldn't be widely used for 1-2 years, I found myself pondering what types of systems our users would be interacting with by then.  The logical answer is of course that tablets would be well part of the mix by then.  For several years, I've been advocating including tablets in the standard design process for corporate projects (ex: the challenge with rollovers on touch devices) to ensure that you at least have a basic solution that covers them, but in this case I found myself planning for them as part of the standard environment for any of our personae.  This led to a whole bunch of new thoughts (most of them to be documented later).

As everyone who has ever stayed in a hotel can tell you, the first steps of booking are always to enter your check-in and check-out dates (or the number of nights of your stay).  The same would go for anyone taking your reservation.  This has traditionally been presented as a text field with an icon next to it for each date, which pops up a calendar.  This adds quite a few steps and clicks to the beginning of any reservation and seems a bit tedious for a hospitality rep.  When you switch a mouse cursor with a fingertip, the process seems even more tedious.

So the natural question was: How can we change the approach to make it more natural (and much quicker) to select a range of dates when using a touch device, but not make it more difficult when using a mouse?

Why not just let the user point and drag?

Seems like a no-brainer to me.  What say you?