Leading experience design for RubyMonk has been a rewarding experience. It is delightful to be working with a product and engineering team that is committed to understanding what motivates a student to learn programming, and is willing to do what it takes to deliver an engaging learning experiences.
I published this article along with my colleague, to share how we applied the principles of persuasive design to RubyMonk.
http://uxmag.com/articles/learning-programming-by-persuasion
As agile software delivery becomes mainstream, it is interesting to see the impact it is having on UX as a discipline. It seemed like agile started off with an almost complete indifference to user-centered design, but, as it gains maturity, there is more commitment to making design work within agile delivery, so much so that “lean product development meets user-centered design” is the new mantra for product success.
It now seems widely accepted within the agile/lean community that there is a need to nurture design facilitation skills. So, what is expected out of a design facilitator in a software delivery organization: Making it easier for the team to come up with high quality of user interface designs. Traditionally, design has been the forte of some people considered to be creative, and has been somewhat intimidating to the logical mind of an engineer. A design facilitator’s role is to help the team overcome this intimidation, and make sure that the disciplined application of methods and tools that inform the design process, and lead to a good user experience.
Many interaction designers who’ve experienced success with agile delivery seem to be making a move towards being a part of software delivery organizations, and are taking an active role in coaching delivery teams in lean UX principles and practices. I notice this trend with some leading names in design – Jeff Gothelf’s role at New Context, Lane Halley’s move to Carbon Five, Tim McCoy at Pivotal Labs, Janice Fraser’s work at LUXr – there’s a pattern here – they are all evangelists of lean UX, and I hope they will play strategic roles as design facilitators in their organizations.
A good number of design facilitators come from other areas like product management and engineering as well – those that have had the skills and the passion for design, but, were restricted in their contribution due to strictly defined roles and titles.
There is a need though to coach and help more designers in becoming design facilitators. Towards this, I suggest focusing on five areas of facilitation, to start with:
Facilitating education
Interaction design calls for a disciplined application of methods and tools used to gain customer insights, for modeling all the information that become available, to communicate design, and to test for usability. A design facilitator can help select the right methods, and educate the team on applying those methods to the design challenge at hand. Some methods need more practice and immersion than the others. But, a design facilitator should take the effort to help the team understand what goes into the design process and help the selection of methods and tools to support the various parts of the process.
Facilitating empathy
This, in my mind, is the single most important role of a design facilitator. Some of my favorite empathy tools are Empathy Maps, and Personas, but I have used several others from IDEO method cards, Luke Hohmann’s Innovation Games and Dave Gray’s Gamestorming. It can be a lot of fun and learning when the team works on those methods together with someone facilitating the activity. Both Luke Hohmann and Dave Gray conduct classes for facilitators, they are immensely helpful in growing into a facilitator. By the way, I think Luke is particularly a master facilitator himself, attending his Innovation Games facilitator class was one of the best lessons I have had in becoming a facilitator myself.
Facilitating collaborative design
Steve Jobs was not a designer by education or profession. Neither was Aaron Patzer of Mint.com, who did masters in engineering. It is the design facilitator’s role to help the Steve Jobs and the Aaron Patzers of every organization to contribute to the design process, through collaborative design techniques. Collaborative design also helps in the synthesis of design ideas from a varied set of participants. Facilitating collaborative design with customers/users if often a powerful means of getting customer insights that are often missed during verbal communication.
Here are some good references on collaborative design (please share any others you have)
Introduction to design studio: http://uxmag.com/articles/introduction-to-design-studio-methodology
On keeping ownership and egos out of design: http://uxmag.com/articles/humble-experience-design
Frog design on how they collaborate with their clients during the design process: http://www.slideshare.net/frogdesign/making-clients-part-of-the-design-process
Remote collaborative design session by Jeff Gothelf: http://www.jeffgothelf.com/blog/remote-collaborative-brainstorming-and-sketching-part-i/
Facilitating the UX roadmap
In a fast, iterative development environment, teams are often challenged by not being able to visualize meaningful releases. This is why many agile teams struggle with creating shippable software with every iteration – features are not shippable unless they help the user carry out a goal. A design facilitator can help define the features that support a meaningful user experience. I use a combination of Adaptive Path’s Sketchboarding (http://www.boxuk.com/blog/using-sketchboards-to-design-great-user-interfaces) along with Jeff Patton’s Story Mapping (http://www.agileproductdesign.com/presentations/user_story_mapping/index.html) as a means of driving the product vision and the UX roadmap.
Facilitating the feedback loop
The success of agile delivery and lean product development hinges on the team’s ability to receive feedback and iterate on it. Be it through site usage analytics, usability testing, or any other means of feedback to the team, a design facilitator has a key role to play in helping the team understand and appreciate the usability challenges with the product, and in coming up with solution to usability issues. If the design facilitator can select and apply the right feedback mechanism to engage the team in the feedback process, the results can be amazing.
After 13 years of helping companies of all shapes and sizes design products and applications, I joined C42 Engineering a couple of months ago to start our experience design practice, based in the Bay Area. I’m not sure if the phrase ‘design practice lead’ reflects what I do, but I’ll get to that later. As you can imagine, for a young start-up in India that is making significant investments in developing products, it is challenging to support my market salary in the US. So, I chose to earn a variable income, with the optimism of growing our business in the US market, offering services in software design and development.
My decision has been met with a variety of reactions – some positive, and a lot skeptical. For me, this move was the most logical next step, and a no-brainer. The main challenge so far has been explaining its rewards to a husband who is a mergers and acquisitions consultant, and I’ve come out in flying colors on that one. Here’s why I think C42 is going to be an organization of choice for other designers as well:
At C42, the whole is greater than the sum of its parts
“In order to achieve high-quality user experience in a company’s offerings, there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design” (quoting Nielsen Norman). I know this is true from having practiced collaborative design in a variety of environments. But, I am yet to see another organization where personal agendas and turf wars have not got in the way of achieving this seamless merging. At best, you might have engineering, product management, and design teams having regular meetings, and more commonly each of them throwing deliverables over the cube to each other. Ultimately, the product suffers, and the user’s experience is compromised. C42 being a small team seeded with talented engineers who aren’t sniffled by silos and roles, is extremely well positioned to deliver products and solutions that are beautifully designed and engineered by a multi-disciplinary team.
At C42, it will be as beautiful as possible, even if it’s inside the box
I’ve met several designers with great ideas for product designs, frustrated that those designs just show up in their portfolio, and haven’t made it into the hands of the user. At C42, you will experience the satisfaction and joy of seeing your design ideas get delivered. What’s more impressive is the passion and commitment with which the team writes beautiful code. If you’re a passionate designer, you can relate to what Steve Jobs said about the PC board “I want it to be as beautiful as possible, even if it’s inside the box. A great carpenter isn’t going to use lousy wood for the back of a cabinet, even though nobody’s going to see it.”
C42 Labs is design thinking in action
The empathy with which C42′s first product (rubymonk.com) was designed, the extreme collaboration and iterative prototyping that’s gone into its releases – is design thinking in action. If you are interested in leading through design, I invite you to see how C42 Labs develops products. If design thinking is more doing than thinking, then, the team does one heck of a lot of design thinking. It provides a solid platform for professional growth and thought leadership in the design community.
So, if you are someone who cares about the user more than your design portfolio, someone who believes that user experience should be second nature to software engineering teams, someone who is committed to making the power of extreme collaboration work in creating great products, you want to talk to us.
It’s not a new subject, but it’s certainly far from resolved, or even understood well. For a long time, I remained indifferent to all the chatter on the topic. However, as I started to be responsible for hiring and building UX teams, it became important to resolve this at least in my head, and share where I am coming from in more than 140 characters.
I have learnt to code as part of my computer science education during college years, I am not intimated by it, I just chose not to continue with it. Here’s why:
I have been involved in more than a dozen projects with similar challenges, but, I think a couple will help see my point -
In my first job as a business analyst on a CRM and BI implementation for Citibank in Europe, I spent more time running SQL queries than really understanding what the business wanted. CRM tools are highly strategic investments for any organization. I think most of my team members would tell you I did a great job as a business analyst, but, I know I could have been a lot more innovative and valuable to Citibank if I had a better understanding what CRM meant for them, and how they expected it to transform their business.
On my first web design project at Cognizant where I had to come up with a knowledge management portal, I spent more time doing an HTML prototype than understanding the impact of what I was doing on my users. Knowledge management systems can be fairly complex in their information architecture – particularly if you are designing for a company with 50,000 users distributed across the globe who expect the search experience to match those on Internet search engines! If I had done something as simple as card sorting, or spent any time at all understanding the user’s mental model, I am sure the information architecture for my site would have been a better experience – to design and to use.
Subsequently, I was fortunate enough to work for some people who were passionately committed to user experience – who encouraged me to spend more time understanding the user and the context, performing task analysis on complex functionality, facilitating collaborative design sessions, “an hour a day” on site usage analytics, formal and guerilla usability testing. I spent significant time in gaining experience using methods and tools to help with experience strategy, user research, information architecture, interaction design and usability analysis, and I know I am far from done. Thanks to my association and learning from folks from companies at Adaptive Path, Coopers and IDEO (they help me justify my Bay Area mortgage!), and other individual consultants who have made significant contributions to this field, I have grown into a designer who is much more aware of how my designs influence my user. When I say I create empathic designs, I also mean that anything else is a compromise.
It’s only when I poured myself into such methods and tools, I realized the positive impact of those on the quality of the interactions I designed. On the other hand however, my HTML/CSS skills were turning rusty, and I started to see that my designs were no more limited by my design skills, but by my coding skills. I started to get better results pairing with UI developers who were really good at what they did, and helped me stay in touch with newer technologies for web and mobile application development.
What I’ve learnt from my experience is that something’s got to give, and it’s more often design, not code that gets compromised – When someone’s doing design and development, higher chance that they would spend more time coding than engaging in activities to understand the users, and validate their designs. I would really like to know how many designers who code are able to get the time in even running usability tests, or analyzing site usage analytics to validate their designs. There’s a higher chance that a designer who focuses on just design has a system in place to constantly refine the interactions based on qualitative and quantitative feedback. I am basing this inference out of my interactions with friends in the field; it would be interesting to do a formal survey on this.
Some have made a good case for designers to code based on what Silicon Valley start-ups are asking for in their job descriptions. I get why sometimes working backwards from job descriptions can help someone who is starting off in their career, but, if job descriptions were a way to go, then agile and lean development would not be where they are today. Settling for lower quality of experiences because an employer wants to get two for the price of one is not where I want to go.
Being a believer and practitioner of empathic design, I look to build a team of designers that is committed to understanding the user and the context of usage, ideate through a variety of designs, facilitate collaborative design with the team, take the effort to get feedback on the product from users, find innovative ways of creating a faster feedback loop. Whether they come with coding skills or not is immaterial to me, I would rather that they have the right attitude in collaborating with developers.
I have spent a significant amount of time with users of enterprise systems at large companies who I’ve seen weep at their desks because of what they’ve had to navigate through in order to do their jobs. Customer service reps who had to use at least six different applications in order to complete one customer request. Call center agents who would be so scared about the system’s dependability that they would print every single screen they enter data into, just in case they get stuck at a point where they just have to shut down, and lose all the data when the customer hangs up.
I remember when I first moved into our new office building at a company I worked for, the “ergonomics” folks came to check on the comfort of my chair thrice in the first two days. Agreed, a bad chair can hurt me, but, if companies really cared about the comfort of their employees at work, shouldn’t they also be taking care of the usability of software tools that employees use to do their jobs? Do users actually have to complain about software design torture and claim disability before any effort is taken to make internal software tools less painful to use? (Note – I did not say easier to use, right now, I think they would settle for just less painful)
I was in a discussion with Jeff Patton and Alan Cooper recently when I shared my thoughts with them, Alan Cooper then sent me this picture and said if we had allowed our chairs to be like our software at work, may be this is how it would look. I could not resist writing a blog just to be able to use the picture! While I agree it’s a harsh comparsion, it depicts two things relevant – the person using it is compelled to be sitting on it and although it looks like a chair to sit on, it could be used for torture. The flaw in this depiction is that while here the torture is intentional, internal users are often provided with software that just happen to make them miserable.
No matter how well we design the customer experience, no matter how well the developers code the design, one thing is certain – things will go wrong. And when they do, we will leave our users frustrated even when we provide them with an otherwise well designed system or product.
Proactively designing the user experience for errors and exceptions is a need and an opportunity. As in our personal relationships where we form strong bonds during crisis times, how a computer handles a potentially frustrating moment for the user is an opportunity for us to show the user that we care.
When twitter came up with the “fail whale” error message image illustrating several red birds using a net to hoist a whale from the ocean captioned “Too many tweets! Please wait a moment and try again”, it created the failwhale fan club.
I fear that we are getting too used to designing for the “normal path” and are often impatient with developers and testers who design their code/script for exceptions. This seems more common in an agile development environment which is all about “just enough”. But, a lack of early focus on handling errors and exceptions might result in losing credibility with our users. I would rather tell my user very early in my interaction with them that “I am not perfect, but, I know when something could be frustrating to you and I will make every attempt to help when that happens.”
There are two aspects to handling errors and exceptions – (1) Anticipating what could go wrong and proactively designing to avoid the situation and (2) When something goes wrong, designing responses with empathy
I know that some companies and agencies have come up with their own standards for handling errors and exceptions. I hope some of us from the UX community can help lead an effort to establish some guiding principles and some specific practices for handling errors and exceptions on a larger scale, so we can help the users with something consistent and predictable, in an area that is quite frustrating when not handled right.
An often asked question on projects is ”Can we afford to apply UCD (user-centered design) practices on this project? We are agile and we really don’t have all that time?” I am often lost when trying to respond, not because I don’t know, but, because I don’t know where to start. To me, being user-centric is the same as being quality conscious. Can we make quality an optional element of a project? So, this question to me is like someone asking if we could afford to apply quality standards to a project…
Peter Drucker is quoted as saying “Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. That is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality”
Thank you, Peter Drucker!
Practitioners of agile, who have had a laser beam like focus on giving the customer value for money by continuously improving the efficiency of development are somehow missing the inefficiency and lack of “quality” when it comes to user experience. It seems somehow that it’s ok to leave user experience standards out of our measurement of quality. We try to overcome that by giving the user the “opportunity” to provide feedback. But, the feedback that is provided by the user is in smaller portions of functionality, rarely if ever gives us an understanding of what the user experiences with the product till the very end when it may be too late.
Producing software iteratively does have tremendous benefits. Getting feedback and refining the software as we go has tremendous benefits. But, expecting the user to experience the entire product iteratively is not only close to impossible, but quite unfair.
User-centered design facilitates an understanding of the user in the context within which they use the software. It makes us empathetic to the user and facilitates building software, testing it and deploying with the user and the context in mind. All the practices suggested in UCD are meant to achieve exactly that – understand the user within the relevant context, communicate that understanding to everybody involved in delivering the solution and use that understanding in performing any activity in software development. We might chose to apply or not apply some of the tools and practices within that discipline depending on the type of solution we are building, but, I doubt if we can obtain a good understanding of the users’ experience with the software by exposing them to it in bits and pieces.
I don’t believe iterative development can really substitute for the discipline applied in UCD, but, I believe it is a great a way to refine our understanding of the user. We do need to make sure the software development team understands the user and the context and builds software with that understanding, in order to make iterative development meaningful to the customer. Agile’s success with gaining efficiency in software development will see it’s true value when it can ensure quality of the software developed, and I don’t mean zero-defect code, I mean (borrowing from Drucker):
- A product the customer pays for
- A product that is of use to the customer
- A product that gives the customer value
The power of UCD in an agile environment has the potential to deliver what Peter Drucker calls quality. Our willingness to live with one without the other might become a huge opportunity lost.
I have tried to address the issue of “taking internal users for granted” as a technology issue, but, I am realizing that it is actually a human issue. Providing people with software tools that does not take their self esteem away is a human thing to do. Addressing this seems like a huge losing battle, user centered design in corporate IT sometimes seems like fitting a square peg into a round hole. How did we get here?
More than 50% of software being built is for internal use. But most of the effort towards creating better user experience is put into consumer facing software. The forces of economics are at play, understood. But, can we afford to create a bad work environment for our own colleagues? We have to realize that a bad software tool makes an unhappy employee. If this employee happens to be the customer service agent, we are now transferring the impact of this to the agent’s interaction with the customer. Phrases like “empowerment of front-end employees” and “Customer Relationship Management” have no meaning if our front-end employees are disgruntled…
If you don’t know much about Innovation Games®, I highly recommend you read the book and/or take the class. But, here is an extract from the preface to the book – “Innovation Games are fun ways to collaborate with your customers to better understand their needs. You can use them to discover new business opportunities, drive strategy and product road map decisions, improve the effectiveness of sales and service organizations, fine-tune marketing messages, and create more intimate, durable relationships with your customers”.
From amongst the many games that Luke offers, I have a specific set of games that I propose we “play” as part of new software development in corporate IT environments – to help us decide what build. I believe that these games will enable a high level of collaboration between business and IT, and will help huge strides towards designing software applications with a user-centered design. It’s great that many of these games are now available online for virtual collaboration as well.
As powerful as these games are for enabling collaboration and helping decide what to build, we have to keep in mind that designs should be informed, but not solely determined by the data collected. If the data collected from these games are by themselves used as a substitute to traditional requirements analysis workshops, it would be an opportunity lost in creating an environment of collaboration and trust. Use the outcome of the games to better understand your customers and have fun while doing it! I like how they say “A seriously fun way to do serious work – seriously!”
As always, would love to hear your thoughts, please post your comment here or write to me at anu@goagilepm.com
On one of my projects where we built a large software application on an agile scrum framework, we were a team of six product owners, and 20 developers. It was a highly competent group and I could not have asked for a better team to lead on an agile scrum based delivery. The problem though was each one of us looked at the project from one lens:
- The designers wanted to make sure this was the “coolest” application in the company, their reputation (read portfolio) was associated with it!
- Three of the product owners were excellent business analysts who would chase down every bit of information they could get with regards to a user story and write detailed acceptance criteria so that the test cases were close to perfect
- One of the product owners was responsible for ensuring that we had all the functionality for processing business rules and were integrating with other interfacing systems effectively – for him, all that mattered was whether we were processing all the rules correctly and we had every data element validated while doing a transaction in our system
- As the product manager, I was responsible for release planning and tracking progress to plan to report to stakeholders, so, I had to ensure that the development team had a good pipeline of work, whether we had the acceptance criteria detailed for the upcoming sprints so that the product owner team did not become the bottleneck for the developers
- The development team often negotiated for sprints dedicated to technical debt and/or refactoring
- My boss, the most agile minded person I have ever worked with had to ensure we were all collaborating with each other and the project was surviving the intense political drama that was very much part of any project in the company (I never envied his job!)
We did a lot of things right. Each one of us was trained with excellent tools to do our job. For me, use-cases were a great way to keep the big picture in mind and user story mapping was a powerful tool for release planning. The other product owners drew from other set of skills and strengths to do their jobs well. We structured ourselves in a way that gave each of us decision making in our own areas of work while also having reporting relationships to ensure alignment and visibility into the project. We had divided the development team into four teams and assigned one product owner for each team. We ran effort of managing the backlog of what to build parallel to the development track and ensured we were ahead by a few sprints all the time. I was crazy enough to ensure that happened!
We had some pretty frustrating problems though:
- Every time one of us added a story to the backlog that potentially impacted dates or scope of delivery, we were never quite sure if this was something we missed because we did not take the effort to understand the customer at the outset or whether we discovered something from the last iteration that gave us a better understanding of what to build
- If had to re-prioritize the backlog based on feedback from a sprint review, my boss was left to think about who he needed to meet for lunch to damage control for what we decided not to build to make our dates
- Every time an interfacing application or program was getting impacted, we were in a quandary – none of our prioritization techniques helped anymore, we were chasing a moving target that not only moved, but often changed directions
- Although we tried to stay ahead of the development team, every time we encountered a significant change in functionality, our user interface design had to be revisited for its usability – our developers hated it!
- Whenever the development team had to re-factor or clear technical debt, the issue of deciding what to build took an entirely new meaning with far reaching consequences that the product owners could not even fathom (I am sure that has never happened to any of you!)
Sounds familiar?! I remember one of the agile coaches calling the product owner a superman, a superman was what we needed to keep this going – the only reason we survived was the incredible commitment of every one of us to the project and to our work. No forum on agile product management, no training on business process management, no discussion on how to make UX work with agile was helping. We did have a project manager helping us manage the many moving parts, but, when it came to “deciding what to build”, the product owner team was on its own!
Right now, there is still a lot of focus on helping organizations transition from waterfall to agile. I am optimistic that soon, the dust will settle on agile adoption and it will become the norm for software development. But, when that happens, the very principles of agile will become the challenges to deal with – how do you not lock down scope at the very beginning of the project and still retain your sanity for the rest of the project. How do you not design everything upfront and still not lose velocity in development. What is “just enough design”, what does “just enough analysis” feel like? What makes waterfall easy is that it does not leave any of these questions to subjective answers – you are done with requirements when everybody “signs-off”, you are done with design with it can be traced back to the “signed-off requirements” – simple solution – yes, we know it does not guarantee good products, but, it did not ask for me to hire a team of supermen in my product owner team. It’s not often, but, sometimes, I do put my sanity over my product!
A holistic approach to deciding what to build means we move beyond principles and best practices to scalable and repeatable solutions. To look at the problem from the lens of just UX or engineering or product management or project management is IMHO making it appear that the problem is going away when it might be getting worse.