Quantcast
Channel: Lasse Koskela » scrum
Viewing all articles
Browse latest Browse all 5

Iterative UX

0
0

My personal interests have shifted through a number of phases since I found the iterative and incremental world of agile methods in the beginning of this past decade. While my intent with this article is to share some of my thoughts and experiences with merging the discipline of user interaction design into agile methods, I find it useful to first explain how my interests have evolved over the years to the point where I stand today.

My journey from code to design

At first my attention was consumed by the engineering practices that XP imposed on the kind of cowboy programming I had seen around me – and performing myself – both in the context of ad hoc and of supposedly highly disciplined methods. I forced myself to write my code test-first, I asked to pair program with others, and I checked in code in far smaller batches than before.

Looking back at around five years ago I can see my interests starting to move towards team work and project management. There was still plenty of improvement to make as far as engineering practices went but that work wasn’t consuming as much of my learning cycles as it had before. I routinely ran classes on test-driven development and spent a lot of time pair programming with clients, coaching them in writing better unit tests but I was increasingly more curious about the kind of insanity and waste I observed happening outside of an individual programmer’s sphere of influence.

Since about 2005 the majority of product development efforts I’ve been involved with have been “Scrum projects”. Considering the Scrum trifecta of a development team, a Scrum Master, and a Product Owner, I can see a slight trend of my work starting from the more technically oriented end of a development team through the more team work and facilitation-oriented domain of Scrum Master, and lately more and more towards the prioritization and product design-oriented world of the Product Owner.

The constant through this change

The single common thread throughout these years has been that my goal has been to help clients succeed with their product development efforts. At first I saw severe problems with code quality and discipline that I could help alleviate with certain engineering practices and processes. Later I saw dysfunction in collaboration between people in different roles and strived to improve that collaboration with facilitation and coaching, applying methods like Scrum. Then I saw dysfunction in the Product Backlog and around the Product Owner’s role, seeking to help the people involved understand the system and how they can influence its behavior in more productive, more effective ways.

Other people have had the same goal of helping clients succeed with their product development efforts for at least as long as I have. I work with some of those people. Many of those people also have had a vastly different approach to reaching that goal. After all, we all have our individual experience, skills and quirks that we must play with and make the most out of them.

Introducing user experience

In 2005 we hired a couple of professional interaction designers. They brought in just such vastly different skills. Up until then we had survived with our engineering-oriented, albeit multi-disciplined, staff, every now and then reaching for outsourced help with interface design. We had almost invariably been disappointed with the results from such outsourcing and yet we knew that we weren’t delivering the best user experience we could for our clients. Not that the clients were complaining but we knew and we do have a thing for perfection.

From the beginning our interaction designers were loudly proclaiming that “programming should only start when the interaction design is done.” Essentially their message was that interaction design was the king. That didn’t go down too well with the XP/Scrum-minded folks who were almost 100% programmers and very much into short iterations, incremental development, and generally allergic to big-design-up-front. After all, most of us have worked for major consulting companies and even the smallest hint of waterfall would give us the chills.

After a while the exaggerated soundbites started making room for more constructive discussion and more open-minded search of a Better Way. From one project to another our engineers and designers grew experience and formed a way of working that seemed to yield the best of both worlds, accommodating iterative and incremental development without a big design up front and the kind of smart user interface that truly was fit for purpose. We started being more and more pleased with the approach. We had a gold standard for how we want to run our application development projects.

We still had a problem as we only had a couple of interaction designers and plenty of projects that desperately needed their precious attention. We have found ways to alleviate that bottleneck – including hiring, of course – but we’ll come back to that topic later. Right now, I’d like to explain how we execute UI-intensive software projects today, combining user interaction design and agile methods into what I personally consider the best way I’m aware of to build such software products or applications.

Just enough design up front

Some of our engagements don’t involve any code to be written, some of our software delivery projects don’t involve a single graphical user interface, and some of our software delivery projects have a user interface that quite frankly isn’t all that important. When we do engage in a project where delivering a great user experience is essential, this is how we work.

To start with who’s involved, there’s a dedicated development team made up of generalist software developers capable of turning requirements into working software. There’s also a dedicated user interaction designer who’s capable of interpreting what different people are saying into a functional user interface design.

We start with what some might call “just enough design up front” where, over a time span of a couple of weeks, the user interaction designer digs into the problem domain and carries out a number of interviews with different people. Those different people may hold titles such as Product Owner, Product Manager, VP of Product Development or, if we’re lucky, titles such as Junior Sales Associate or Cashier. We want to talk to users, not somebody who pays the bills. Sometimes this luxury is available and sometimes we’re not that lucky.

Based on this work the user interaction designer identifies and documents the essential usage scenarios that represent the most significant, most valuable use of the system. With these scenarios to work with the designer starts iterating toward a user interface design that supports these scenarios with the best possible design, starting with just one scenario and incrementally expanding and editing the design one additional scenario at a time. At some point the designer starts involving the client’s staff to help validate the designs, which at this point are generally sketches or paper prototypes.

When the designer feels confident enough that the main cruces of the problem domain and the main usage scenarios have been solved, the design is considered stable enough to start programming. Up until this point in time, the development team has usually set up their infrastructure or worked on specific bits of implementation that do not involve the user interface.

The very reason we don’t start implementing the user interface on day one along with the user interaction design work is that it’s much, much more expensive to iterate in code than it is to iterate on paper. There’s a lot of rework to be saved by investing some time up front on this work.

Working with the designs

Once implementation begins, what the development team works with is a Product Backlog derived from general system requirements and the functional design – the sketches and paper prototypes – provided by the user interaction designers. By the iteration planning meeting the Product Owner and the user interaction designer have identified vertical slices of end-to-end functionality that could be implemented in the next iteration.

Sometimes those vertical slices are straight from the designs, e.g. a panel that displays information. Sometimes, those vertical slices are a stripped down version of the design resulting from a decision to down-prioritize a particular usage scenario. Sometimes, however, there’s a need for an intermediary design that introduces partial functionality with the intent that this is a temporary solution. In those cases, the development team and the user interaction designer are looking for a compromise that delivers the best user experience feasible with the boundaries of implementation effort and iteration length.

During an iteration the interaction designer reviews and validates the implementation as it progresses and serves as a quality gate – “reviewed by interaction designer” is often part of the team’s Definition of Done. Essentially, the interaction designer’s attention is split between this iteration and the next iteration(s), very much like that of the Product Owner’s. Just like the Product Backlog continues to live and evolve our user interface designs continue to live and evolve.

Beyond the bottleneck

As I said before, we hired a couple of trained professionals in interaction design back in 2005 and that wasn’t even remotely enough to staff all of our web development or desktop application projects with a full-time interaction designer. I also said that we’ve found ways to alleviate that problem.

The most obvious solution is, of course, to hire. That has proven to be somewhat difficult and even though we received almost a thousand applications last year only a tiny fraction of those applicants have had the right profile. Instead, we’ve had to find ways to source that talent from within.

A couple of years ago we started an internal apprenticeship program and a handful of solid programmers jumped on the user interaction train. Our experienced interaction designers taught their apprentices in regular training days and mentored them almost on a daily basis. In practice this meant that our senior designers had to take on much less work than before. On the other hand, we immediately had a wider spread of limited knowledge and skill – enough to fulfill the immediate needs of a development team – and bigger designs would still be reviewed together with a senior colleague.

Seeing the apprenticeship program become as successful as it has makes me wonder at the courage and drive of the individuals who saw the importance and dared to make the leap. Others have also taken part in the trainings and the whole company is more or less familiar – at least on a theoretical level – of how user interfaces are designed with our iterative method.

Personal touch

Some time ago I was a developer on a software project where we had an apprentice user interaction designer on staff and a senior designer paying us a visit one or two days a week. It was a relatively big project for one designer, however, with multiple teams working on an application where a good user interface was considered crucial for commercial success. Our sole full-time designer frequently had her hands full when a larger UI change was approaching and user stories would pile up towards the “interaction designer’s review” column on our story board.

I took part in one of those larger UI changes in a small team of four developers. The whole thing had bubbled through the Product Backlog very quickly and we didn’t have a single sketch or prototype to work with. We could’ve said, “no, we can’t do this before the designer has time” but instead we said, “yes, we can do it.” After all, it’s not a problem for us to take collective ownership of code given that we all know a bit of everything in the code base so why should the UI be any different?

Art of the possible

We decided to take the reality by the horns and make the best of what we had. We started preparing for the upcoming implementation between ourselves, trying to verify that we really do understand the big picture, identify the relevant usage scenarios, and sketch solutions that would support those scenarios as best we could. Stepping outside of our respective comfort zones wasn’t anywhere near as frightening as it had sounded a couple of weeks earlier.

Once we had agreed about the overall design with the team I set off to create a more detailed design for one particular user interface geared at managing orders and their logistics. I looked at the usage scenarios and specified what kind of information does the user need at which stage, what kind of information does the service provider need, and what kind of a workflow and interface design would tie it all up such that all of the scenarios would be supported and that I wouldn’t be leading our team down the front end programmer’s equivalent of Dante’s Hell.

That was hard. Not because I couldn’t have designed a user interface but because nobody from our team knew what the people in logistics actually do, how they work currently, and what kind of a user interface would best support them in their task. Our Product Owner knew something about it but he also had just second hand information from the management of the logistics department. This was when it finally sunk in for me how crucially important it is to get to talk to actual users – I had no idea what the warehouse dudes actually have to do before Tom’s new mobile phone and Jean’s shiny new iPod leave the premises with the correct transport manifests and everything.

Again, I knew that I could only do my best with what we had. Besides, I had been through the basic training on user interface design, I’d read Alan Cooper’s classic about inmates and an asylum, I’d read “About Face”, I’d familiarized myself with user interface design patterns, and I’d seen many designs created by our awesome interaction designers. It wasn’t difficult to design a good user interface. Maybe not a great user interface but it’s perfectly doable to design a decent solution by following our method, focusing on the usage scenarios, and iterating the design, simulating against the scenarios.

Creeping insecurity

At this point I had a design that I thought was good but I also knew that I’m relying on the hearsay and babble of the Product Owner, which shed some insecurity into my doing. I had just leaned back in my chair, looking at the sketch in front of me and wondering whether it really is good enough when our senior interaction designer walked in. He wasn’t supposed to be at our disposal – he was there for another project – but I thought, “screw it, he’s there and this will only take a few minutes.” After all, I might get an opinion back in two seconds that could be compressed into something along the lines of “that’s the crappiest solution I remember seeing” but at least I would know so I walked over and asked if he had a moment to take a look at my design.

I explained the usage scenarios for which the design was made and what kind of widgets and behavior I had drawn in it. He asked me some clarifying questions and I did my best to answer them. Most of the questions were related to what happens at the logistics department when orders are coming in and how the logistics people juggle the orders internally, alone or collectively, grouping by customer or by product, whether the delivery address influences the way they are processed, etc.

After some five to ten minutes I walked away having crossed over one panel that wasn’t actually necessary for the scenarios and with a couple of other minor changes to make. We didn’t only have a better design but also a good feeling about having done our best despite our lack of availability for user interaction design expertise. We had likely done a good job (which later proved to be a correct assumption) and most certainly better than the CRUD-crap that we’d seen some competitors produce in the past.

Parting thoughts

It was definitely worth taking that step outside of the comfort zone. Looking back at this experience, it has provided me with a lot more perspective and tools for my coaching work with Product Owners. In fact, I’m certain that it wouldn’t hurt for a Product Owner to invest some time and effort to learn about user interaction design. After all, it’s all about product design, learning and knowing what your users need, working that knowledge into the Product Backlog, and refining your designs to allow for iterative and incremental implementation of that Product Backlog.


Viewing all articles
Browse latest Browse all 5

Latest Images

Trending Articles





Latest Images