Working as part of an agile development team for the first time can be difficult for UX Designers. You need to adjust the way you work and find a different rhythm.
This transition can be difficult to make as it’s often about subtle differences rather than a complete change of job. You’re still solving the same problems and doing the same tasks. The difference is in the way you structure your workflow.
For some designers this change comes naturally. For others it can be challenging, confusing and frustrating. I’ve seen some designers figure it out in just a couple of iterations. Whereas others have struggled through projects for a year or more before finding their groove.
The good news is that it’s a transition worth making. Once you’ve experienced the benefits of working collaboratively in an agile team, you can never go back. Once seen your ideas come to life while the ink it still wet on your mockups, the idea of working any other way will seem ridiculous.
Over the last few years, I’ve been through the transition myself and helped coach other designers through it. This is the approach that works for me. It’s not prescriptive, nor perfect. Every individual is different. Every team is different. You have to find their own way, but this is the advice I wish someone had given me to ease the transition.
Start by setting a vision
Set a vision, then iterate through the details. Don’t try to create a prescriptive end-state before development starts. Being agile is all about working iteratively and adapting as you learn. It’s about putting a marker on map and working through the challenges required to get there. Don’t try to list out turn-by-turn directions for every step of the journey before you’ve even started.
Designers play a key role in helping the team start with a shared vision and mental model. Our ability to think visually and articulate an experience can help a team start heading down the right path together.
There are lots of different ways to communicate a vision. Customer journey mapping combined with low fidelity prototyping tools are usually my default approach. Hand-drawn sketches showing the core page-flow gives a tangible view of the experience we’re trying to create.
This is just one approach. Other useful tools include design principles, empathy mapping, value proposition canvass, service mapping, story mapping, the list goes on. Regardless of the tool, what is important is not overinvesting or trying to lock down the details. Set the direction then let the details emerge as the team builds the product.
The caveat with all this is that sometimes a little upfront design is required. Sometimes it’s necessary to delve into the details a little, usually for estimations and resource planning. If you need to do this, consider depth versus breadth. If you need to, spike out one feature in detail to get sense of the details. That can help you extrapolate the effort required to build the rest of the product. Just don’t let it turn in to Big Upfront Design by spiking every feature in detail. A good focussing question for this is “what is the minimum we need to know to start building?”
Don’t try to build the full vision
Start simple. Then iterate and enhance the product over time. Business owners and designers usually jump to what the mature product could look like one day. They see the end-point once every feature idea has been built. I call this ‘blue sky designing’. It’s jumping ten steps ahead of yourself.
Mature products take years to build. Chances are that is what is contained in the vision that is up on your wall. That’s good, it means you have an ambitious goal to work towards. But every journey starts with one step.
Don’t start by trying to design the perfect end-game solution. Ask the question “What is the simplest possible way we can meet a customers needs?” Design and build that first. It’s a harder design challenge, but more efficient product plan. Once you have this simple, yet valuable product in place, you can continue to progressively enhance it over time.
Communicating your vision using a design wall
Put all your design work up on a wall where everyone can see it and use it as a blueprint to build from. This becomes your design wall. Rather than creating complex documentation, print everything out and map it out on a wall.
Start with rough hand-drawn sketches or whatever you have. As designs become more polished layer them on top of the initial sketches. As you learn new customer insights or discover usability issues add them with post-it notes. Design walls can take any form or structure that is necessary. Map it out by customer journey, product structure or site map. Whatever makes sense.
The best place for it is right next to your team card wall and backlog where it can help provide clarity for conversations. A good design wall becomes a central point for conversations with the team. It also communicates where you are at to your stakeholders.
Managing stakeholder expectations
This focus on a simple product and lack of locked down details can make a lot of stakeholders nervous in the early stages. The key to overcoming this is to take them along for the journey. Ensure they contribute to the initial vision and see their inputs on the design wall. That gets them excited. A lot of business people are never included in that stage.
Most stakeholders get nervous during the first month or two of a team ramping up. It usually looks like the team is making little progress. The foundational technical work isn’t tangible and screens look rough. The only way to placate those stakeholder nerves is to demonstrate progress.
As a designer you can help by showing the movement on the design wall and seeking stakeholder input. As you work through one feature at a time, the design wall incrementally evolves. Showing how each small step fits in the bigger picture will calm their nerves.
This also allows stakeholders to contribute and influence the process. Seeking their feedback and putting it into action gives people a sense of control over the process.
Be part of the team’s workflow
Don’t consider yourself a unique snowflake. Be one with the team. Work within the team’s iterative cycle and workflow.
When trying to fit in to the agile teams, designers often try to create their own separate design process or backlog of tasks. They want to add separate design story cards or do design work that isn’t related to prioritised user story.
Global elements, such as website homepages or navigation, have a habit of triggering this. Designers see these as a design task that they need to do upfront. Write these as a user story and prioritise them along with everything else.
Here’s an example of how you could write them as a user story:
- Homepage: As a user I want understand what a website is when I arrive at it so that I know what I can do on it.
- Navigation: As a user I want a consistent way to navigate through the site so that I can find the content I am looking for.
These global elements are usually (but not always) considered a must have. But yet, they might not be the best place to start building a new product. Often it makes more sense to leave them until after you’ve built a few features or some content first.
This is a natural instinct as designers try to think about how a page design will play out across other functions. The problem is it means you’re trying to separate yourself from the rest of the team. Focus your design work on the stories the team has prioritised. Making those parts work well first, then let the bigger picture build and emerge over time.
Get to know the flow of work through a development team
If you know how it works you can figure out how to become part of it. Every other role in the team is part of an orchestrated flow of work. Business Analysts, Developers, Testers and Product Owners all have a place. Designers are no different.
Agile development teams have a tried and trusted process that focuses on delivering value. Pieces of work (i.e. a user stories) are prioritised from a backlog and pulled in to play. They move into analysis, development, testing and are finally released through to production.
Designers do the bulk of their work in the backlog and analysis phase. This is where wireframes and visual design takes place.
Designers also play a role in the development and testing stages as well. The best time to fine tune the details of a new feature is when a developer is actively working on it on their local machine. Sit down a pair with them to tweak those pesky pixels into place.
It’s also important to check new features once they move in to testing. But be aware, there is a time cost if they have to move back in to development. This is why it’s important to pair with devs as they are doing the work.
The iterative design cycle—research and envision for features
I find I design at two different levels: feature sets or individual stories.
When starting work on a new feature, I start at a high-level by mapping out the user flow and page elements on a whiteboard. This is usually a collaborative conversation with whoever has been driving the product vision. This could be the Business Analyst, Product Owner or Tech Lead.
Share ideas about what this new feature should do and how to build it. Usually the UX Designer and Business Analyst are the ones driving the product vision. By including the Product Owner in this conversation we ensure that it will meet the business needs. By including the Tech Lead we head off any potential technical problems or ideas that just aren’t feasible.
Once we’ve reached an agreement, we can then break it apart in to user stories and discuss what should be in and out of scope for now. The stories in scope can moved into analysis, whilst the out-of-scope stories can be moved to the backlog and left for another time.
This process is typically a 2 week – 2 month cycle. It can cover 1 or multiple iterations.
The iterative design cycle—design for individual stories
Try to design screens for the specific stories and their requirements. Don’t add in elements that aren’t part of the story criteria or are out of scope. Don’t try to design the entire experience in one go.
This just confuses the team. It’s hard for devs to work from set of wireframes or visual designs that include every piece of functionality you ever considered. It’s confusing to figure out which page components they should or shouldn’t build for their story.
Here’s an example of one of my early failed attempts to work like this. I designed pages that included every feature we ever thought about, regardless of whether they were in or out of scope. As a guide for devs I tagged page elements with the corresponding story numbers on a pink post-it. I thought it was innovative, but it thoroughly confused the devs. In hindsight I should have kept all those extra little design ideas hidden away in a separate file somewhere. Instead I should have output wireframes that only included what was within scope.
[A good example of how not to communicate your designs to the team.]
Build pages and your designs story by story in the same way the devs will work through it. Remember, you are creating inputs for their coding work (unless you do the coding yourself). Produce assets as the devs get need them. Wait until they are picking up a story and ask them the specs about what they need.
This is where Lean UX and Emergent Design come into the conversation. By only designing for what is going to be built, you are being lean and allowing space for the product details to evolve and emerge over time.
Sometime this cycle leaves you twiddling your thumbs a little. Be patient. Find other ways to add value such as doing some research.
Don’t try to make your designs 100% perfect
Be willing to compromise and adjust your designs once you get into code. You can’t know every scenario until a dev starts building it. There will always be some hidden gotchas.
Aim for 80-90% complete and allow time for some collaboration in code. Be ready to sit down and pair with devs to answer questions and fine tune the pixel perfect details. Don’t get caught up in making everything perfect in Photoshop, that’s not the final medium the product will exist in.
Always prioritise questions from your devs. You want them to reach out and collaborate with you. If they ask for your time, it’s an opportunity to have a direct control of the fine details.
Embrace the concept of UX Debt
The term Technical Debt is a way of describing features built in a way that is quicker but comes at a longer-term cost of rework required. Tech debt is usually captured on a story card and added to the backlog of work to be prioritised.
UX Debt is just like Tech Debt. Sometimes you need to compromise on the ideal solution to get something built. Sometimes the perfect design is much harder to build than a slightly compromised version.
Rather than becoming upset about it, capture these compromises as UX Debt and add them to the backlog. Quantify it if necessary. Be respectful if devs raise challenges and issues with your designs. They’re not trying to be difficult, they’re just trying to manage their own work and figure out how to build stuff.
Be patient about seeing these sparkles added to the product. Often products will be built in a way that starts with a bare bones structure, covering core functions first. Other more exciting details are then layered in later. This can produce anxiety in designers as their pet features don’t come until later. Too be fair, sometimes time runs out and they don’t get done at all. But you need the core structure in place first before you can enhance it.
This is all a question of scope management and prioritisation. Choosing to build a new feature or spending time polishing an existing one is a valid choice for a Product Owner to make. Both add value to the customer experience, just in different ways.
Where does research fit into this process?
Research should be a continuous activity. You should aim to bring customer insights or feedback into the team on a regular basis, when it can be more directly acted upon.
I usually research at the the feature or story level, just as I design. Researching customer needs at a feature level helps test your ideas and understand what should be in or out of scope. Whilst testing story level designs identifies usability issues.
On a practical level, both of these can be done at the same time. A lot of people advocate for testing whatever you have with a couple of users every week. In these sessions you can both test designs or talk about their customer needs. Sometimes it is necessary to go into more depth for a particular areas of customer needs or behaviours. In this case it might be worth doing a more formal set of sessions with users.
There is no right or wrong with this. The key is understanding what you need to learn about and structuring your research accordingly. Here’s a simple framework to work from:
- Need to learn about customer behaviours and needs? Conduct in-depth interviews
- Are you validating ideas? Test using lo-fi prototypes
- Are you testing page designs? Run task based usability testing
Being the odd one out
Agile development teams usually have somewhere between 4-8 devs and one UX Designer. This is where it can be hard for designers as they feel like the odd one out. Unfortunately only large projects tend to need two or more designers in a team. Just remember, the benefits of working with people who can build your ideas outweigh those of sitting next to other designers.
Most designers are used to working surrounded by other creative folks, not techies. Whilst you do miss that, there are other ways to collaborate with like minded designers. Reach out to designers in other teams and buddy with them. Attend or organise community meetups. There are lots of ways to connect with people outside of your daily workflow.
Be physically part of the team
If you want to be part of a team, sit with the team. Right in the middle. Co-location is a key agile principle. Don’t let yourself be physically isolated by sitting around a corner or at a different desk. Sit right next to everyone else and be part of the team conversations. It’s a symbolic thing.
Never put on headphones. Again it’s a symbolic thing. It’s a cliche that gets a knee-jerk response from developers. If you want to listen to music, do it as a team. When you need that uninterrupted time to tackle a design problem move to a different space. Go hide in a room for a while. Communicate that is what you are doing and why you are doing it. Be deliberate about it and, as above, don’t do it by default.
Technology is no longer an expensive monolith that needs to be overcome for businesses to succeed. In the emerging digital economy companies are learning new ways to leverage technology. They are reshaping their business models and the relationships they have with their customer. The list of industries being disrupted by digital technologies is growing. The recording industry, banks, retailers, telcos and taxis are just the beginning. Any industry yet to be disrupted need only wait until the digital native generation becomes the majority.
Any company that ignores the need to adapt risks going the way of Kodak. To embrace this new digital world, companies have to change their practices and the way they use technology. The traditional IT focus on systems and infrastructure is fast becoming an outdated approach. It’s no longer enough for companies to have a segregated IT department, hidden in a basement somewhere. Technologists need to do more than just provide services to other parts of the business. Technologists need to be part of the conversation before technology becomes the solution. Technology is becoming an enabler to try new ideas, rather than a handbrake slowing down progress. They can help explore business challenges and discover new ways to solve them. Companies that know how to do this are realising the benefits of living in the digital economy. This is the source of digital disruption – along with the solution to surviving it.
Close collaboration between business people and technologists produces a greater and more innovative result. Smart companies realise this. The rise of the Chief Digital Officer is a sign of the shift in mindset.
The key tool that enables digital innovation is Design Thinking. Design Thinking fuels a collaborative approach to problem exploration. It “uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
For years Designers have been using their research skills to understand customer needs. Just as Developers are trained to code, Designers are trained to reframe and solve problem. This fuels alternative thinking, inspiring new creative solutions. These are the skills required to survive and thrive in the ever-changing digital landscape.
Where Designers often fall short is that they (just like Business people) often see Technologists as a blocker. Instead they should be seen as a collaborative partner to craft great solutions with.
Designers have long been guilty of removing themselves from the larger process. Choosing to hide away in colourful design agency offices with their headphones on. Only deeming Technologists worthy of seeing the solution as it sails over the metaphorical wall. And not until it is perfectly crafted with a ribbon wrapped around it.
To get a competitive advantage, breakdown this functional divide. To get ahead and stay there, Business people, Designers and Technologists have to join forces. Working closely together is the only way to unlock a company’s enterprise potential.
Being innovative in the digital space requires creating something that viable (Business), desirable (Design) and feasible (Technology).
So, how do you change the way a company works and embrace digital technology?
Start-ups have it easy when it comes to multidisciplinary collaboration. When there are only a handful of people involved it forces everyone to work together. At the enterprise level bureaucracy gets in the way. This can be overcome. Start small. Focus on individual teams or projects. All it takes is a desire to share and learn from other disciplines and invite them into the conversation.
There are a few obvious ways to do this. Designers embedded in delivery teams are becoming commonplace. This is often driven by the need for UI design. It provides an opportunity for them to bring the voice of the customer and their feedback into the team on an ongoing basis.
Take technologists and business people out into the field for user research. It is perfect opportunity for everyone to learn about customers together. This means that everyone can become a customer advocate, not just the Designers. Where collaboration becomes harder is when exploring and defining business problems. It’s common for Designers and Business people to work together on problems. This is usually well before technology becomes a consideration.
Often budgets and resourcing become reasons not to bring technologists in to this space.
This is a missed opportunity. Technologists bring a different mindset. They can reshape the thinking about how technology can help. They can provide useful tools or head off paths that aren’t feasible. If nothing else, it’s an opportunity to share the problem context. This creates a better understanding of the business goals once the project moves into the delivery phase.
Change your measurement metrics
Focus on providing value to the customers. Measure customer value, not individual activities.
Traditional organisational hierarchies are structured and segmented by skills-sets and functions. This model is a legacy of 19th century Fordism management theory It was designed for mass-production factories. In this structure managers focused on measuring and improving the performance of individuals. (Freedom From Command & Control, Pages 15-23, John Seddon).
This model breaks down for knowledge workers. When performance measurement focuses on individual activities, it focuses employees on internal targets. This encourages individuals to game the metrics and compete and against their co-workers. Instead they should be using their skills and creativity to deliver value to customers.
Multidisciplinary teams should focus on delivering value to customers, not internal hierarchies. Create teams that have a clear external purpose, along with the mix of skills required to achieve it. This breaks down barriers, creates efficiencies, and fuels collaboration.
Collocate teams and create physical space to collaborate
Sit teams working together in the same area. Remove the barriers in the physical space. Pull-down partitions. Use bench desks where people can sit directly next to each other. Provide more flexible spaces that teams can adjust to suit their needs. Open up more wall space where teams can post and visualise their work. Create information radiators that share ideas.
A collaborative team space can spark a change to the way teams work without the need for an organisation restructure. Collaboration comes naturally to people. Create a suitable physical space and it will organically happen.
This doesn’t just mean creating one big open plan office. A diversity of allows different types of working activities. Break out spaces a required for smaller two or three people discussions. Sometimes a quiet space is needed for focused thinking – or just to take a phone call. What is important is for teams to be able to easily communicate, with minimal barriers.
Become agile (with a small ‘a’)
Agile software development methodologies (such as Extreme Programming or Scrum) have revolutionised the industry. Once seen as a hippy alternative, Agile has gone mainstream and is now used by most large organisations. The ability to release software early and often has changed the game. It delivers business value regularly, rather than taking years to launch a product. Iterative software development puts the control back in the hands of the business owner. It is a big part of why technology has now become an enabler rather than a blocker.
The down side is that Agile methodologies have become industry buzzwords. People have become fixated on arguments about the practices and techniques. Don’t worry about whether you do stand-ups or scrums. Focus on validating your ideas, shortening your feedback cycles and adjusting to new learnings. The true purpose behind being agile is being adaptable and responsive to change.
Taking lots of small bets
Think big, start small. The simple trick to being innovative is take lots of small, cheap chances. Don’t bet your house, car and boat all on black. When you have too much to lose you become trapped to one concept and fight for it well after it’s proved to be flawed.
We learn by doing. The only way to see if/how something works is to try it and see. Trial new ideas as inexpensively as possible. If you haven’t invested too much in it you can embrace the the learnings and move on.
The same principle applies to trying new internal practices or building new products. If the answer to a problem was obvious someone else would already be doing it. Being innovative and pushing the boundaries means pushing into the unknown.
There is a science to doing this. It’s starts by being willing to fail. Then learning how to fail-fast. The better you get, the shorter your feedback cycles. The quicker you learn if something works, the quicker you can cut your loses and try something else.
There are all kinds of lean learning tools out there. Guerrilla research, innovation labs, rapid prototyping. They all focus on learning as quickly and efficiently as possible.
Stop ignoring the divide between the Business, Designers and Technologists
As with any addiction, the first step is to admit you have a problem. Just because it’s always been done this way doesn’t mean it’s the right way.
The model of an IT department siloed off from other parts of the Business creates a permanent disconnect. It stifles collaboration. Just like the Business outsourcing all their creative thinking to an external Design Agency. This just formalises the divide.
Once you admit that this approach is flawed it allows the conversation and search for alternatives to start.
To be a winning team, we must all join forces – Business people, Designers and Developers. From this collaboration of complementary skills comes a truly competitive advantage. It allows us get on with the job of working together to delivering value to your customers.
The question is, do you need to stop denying that there is a divide?
This article is part of the InfoQ series “Design And Technology: Joining Forces For A Truly Competitive Advantage Content”.
Do you have a great idea for a product that could make millions? Chances are the answer is yes. Everyone has a great idea up their sleeve. But not everyone has made millions of dollars from them. In fact, far more people have lost money on an idea than have made it.
Why is that? Quite simply, ideas are free. Delivering them is expensive and hard.
Anyone can come up with a great idea without putting in any effort. Inspiration striking in the shower does not lead directly to making money. Ideas have no value until they are turned into a successful product – which takes skill and hard work. Added to this is the challenge of identifying the good ideas from the bad. An inspired idea is not necessarily a profitable idea.
One of the keys to dealing with ideas is to minimize the amount of effort you invest until it’s proven to be a good one. The earlier you kill bad ideas, the less money you pour down the drain.
The lean startup culture has popularized methods for doing this. Minimum viable products, the build-measure-learn cycle and pivoting. These all focus on minimizing the amount of money invested into an idea. They are all about proving or invalidating an idea as quickly and as cheaply as possible.
This same principle applies in larger established companies as well. It’s just not as diligently used. Without the pressure of limited capital to burn through there is less pressure to be lean. Often new projects kicked-off without a validated purpose and defined measures of success. Nor are lessons learnt from unsuccessful projects.
All in all this leads to lots of time and money spent on ideas that should never have become more than a scribble on a piece of paper.
So how do you deal with and manage ideas? How do you sort the good from the bad? These simple practices can help minimize the investment in bad ideas and maximize the focus on the best ones.
Start by Taking 20 Minutes to Define the Idea
Before spending any time talking about an idea, take some time to define what it is and what problem it is going to solve. Some time doesn’t mean hours or days. That’s too much investment. Taking 20 minutes is enough to make sure the idea has been thought through, but not so much you become attached to it.
This isn’t about introducing more bureaucracy. It’s about applying rigor. That little bit of time spent upfront allows informed and targeted decision-making.
Here some points to consider when defining an idea:
- Why – What problem will it solve? What is its purpose? Which strategic goal will it support? A simple one-sentence problem statement provides a strong clarity of purpose.
- Who – Who is the target audience? Who will use the outcomes of this initiative? These could be either internal or external customers.
- How – What are the goals? What behaviours need to be changed? What will a successful outcome look like? This isn’t about diving into the detail, it’s about defining the proposed method of solving the problem.
- Measures of Success – How will we measure if this idea successfully delivers value? How will we know when it is done? Clear, quantifiable metrics are important to measure how effective an idea is. Avoid trying to use general measures (such as NPS), which are affected by various factors. What is your One Metric That Matters? The more a particular impact can be isolated, the clearer the results will be. If you cannot identify a specific measure then you should question the business value of an idea.
- When – Are there any particular dates or timeframes in which this initiative needs to be completed? What are the consequences or risks of delaying it? Measure the Cost of Delay.
- Resources – What skills or resources are required to deliver the idea? Quantities aren’t required at the idea stage. Flagging which resources or other areas of the business will be needed helps inform decision-making.
Defining these details shouldn’t be a long exercise at the idea stage. A simple one-pager with a few dot points on each of these is enough to inform a discussion.
Prioritise Your Ideas
Create a backlog of ideas and with a clear view of which is the highest priority to start working on next. When new ideas come up evaluate them against the existing priorities. Either bump something else down this list or put the new idea in a parking lot.
As part of your prioritisation process you should stop more ideas than you start. People coming up with ideas is a good thing, but it shouldn’t be a given that they will be worked on.
A regular ‘idea pitch’ session is a good way of discussing and prioritising ideas against each other. This doesn’t have to be a long drawn out process. Once you get good at it, this can be a 10 minute conversation. If it needs to take longer, then it is time well spent.
If you are starting a program of work use a simple planning poker exercise to establish priorities, just as you would with features and epics. Use the simple calculation to measure value:
This quantified value will allow you to prioritise an objective value rather than the HiPPO decision-making principle.
Prioritise Ideas Along with Other Work
When resources become available decide whether to explore a new idea or start a different piece of work. If you have a program of work in play, it’s a simple matter of resource and backlog management. Exploring an idea doesn’t come for free. It takes times and resources. Time and resources that could deliver something else of value.
If a new idea comes up that is urgent, consider if should you stop something else already underway and reassign the resources. This comes with a context switching cost but is sometimes necessary as circumstances change.
What you shouldn’t do is just start working on a new idea top of the existing workload. If you do you should expect it to come at either a productivity or human cost. Having too much work in progress at one time reduces overall throughput and burns people out.
Spend Time Exploring the Problem Before Delivering the Idea
People often want to go straight from having a moment of inspiration to starting to build it. They skip the discovery phase and jump headlong into execution mode. This is a recipe for months of hard work spent on a project that doesn’t deliver the value it promised or tries to solve the wrong problem.
The first step in working on an idea is to understand the problem it aims to solve. With this clarity you are able to evaluate and select the best solution. A well-understood problem also provides clarity of purpose and helps focus the scope of work. It’s an important first step in starting any piece of work that is going to be successful.
A simple framework for understanding the different stages an idea goes through is the Double Diamond.
Ideas are the trigger that starts the process of defining the strategy. Take some time to understand and define the problem. This allows you to evaluate potential solutions and chose the right one.
This time spent in the initial discovery phase is a worthwhile investment that will save time. However, it doesn’t always have to be a lengthy process. Sometimes it can be an hour spent sketching on a whiteboard. Other times it could require months of research to explore and understand the problem. It all depends on the context and size of the idea.
It is important to be deliberate about which mode you are in. Are defining the idea, exploring the problem, or executing the solution? Your approach and tools should adapt accordingly.
Starting to Deliver an Idea / Switching to Delivery Mode
Once you’re ready to start executing the solution, you need to create a vision and plan. The best way to do this is with a collaborative kick-off workshop. Get the project team and stakeholders together in a room to discuss it and come up with a plan.
Start by revisiting the original idea brief. Share the Why, Who, How and Measures of success. Refine as necessary and reach agreement.
Then frame the workshop with a simple focusing question: What do we need to know to get started? Here are some of the subjects to cover:
- Goals – What are the proposed outcomes of the project. It is important to prioritise these, as they might not all be required to drive the necessary change, nor feasible to aim for. SMART Criteria are a useful tool for defining these.
- Target Audience – Use a tool such as Personas or Empathy Maps to create a shared understanding of who the target audience is.
- Behaviours you Want to Change – Think about how you want your target audience to change their behaviour. This will make you think more laterally about possible solutions and priorities.
- Features and Tasks – Define the pieces of work required to change the behaviours and influence the measures of success. Again, prioritisation is important for these.
- Resources – Who, what and how much is required to deliver this piece of work. Once you have an estimate it’s important to revisit the question of whether the return on investment is worthwhile.
- Iteration Plan – What is the project timeline, key dates, MVP, feature plan, etc.
- RAIDs – What are Risks, Assumptions, Issues and Dependencies that the team needs to address and make stakeholders aware of.
Impact mapping is a useful tool for structuring these workshop activities.
Covering these will give everyone a shared mental model of the problem, goals and solution. It is the best way to prepare everyone to work together to build the idea and deliver a great result.
Originally published at www.thoughtworks.com on June 1, 2015.
Today, constant innovation defines our marketplace. Businesses must respond to customer expectations for better digital experiences. How do leading organisations launch successful new products and respond rapidly to external change? How do they move beyond the desire to innovate to actively be innovative every day?
“Innovation” is such a big word that people often overcomplicate. They put too much emphasis on producing the “next big innovation” and become attached to their ideas and outputs. Instead, the opposite is required. To be innovative, you need to be responsive and adaptable. You need to be willing to try an idea, assess, adjust, and continue moving forward.
These concepts of learning by doing, failing fast, and adapting to change are all core Agile practices. They are the reason why iterative development exists, and the reason it can be so effective.
These proven Agile principles and techniques can enable product innovation. Using lean thinking, fast feedback cycles, and iterating, you can consistently – and rapidly – bring new ideas into the market.
What is innovation?
The cliché view of innovation is a genius inventor having a light bulb moment. It rarely happens that way. Instead, most innovations are a culmination of small ideas incrementally built upon other ideas, often in unpredictable ways. Steven Johnson describes this as the Hummingbird effect. He says:
“Change almost always comes as a surprise because things don’t happen in straight lines. Connections are made by accident. Second-guessing the result of an occurrence is difficult, because when people or things or ideas come together in new ways, the rules of arithmetic are changed so that one plus one suddenly makes three. This is the fundamental mechanism of innovation, and when it happens the result is always more than the sum of the parts.”
Where the rubber hits the road in a commercial context is when a company is able to translate a new idea into a product or service that customers are willing to pay for.
Thomas Edison wasn’t the first person to invent a light bulb. He just improved it. He was the first astute businessperson to create a longer lasting light bulb and put in place a power grid. When combined together this enabled people to use a light bulb in their homes, whilst paying him money for the service.
How do we do innovative things?
All the well-known historical examples of innovation are the result of many hours and years of hard work. They resulted from smart people rolling up their sleeves and taking practical steps forward. Here are some small practical techniques that you can do today that will produce innovative results.
Understand and reframe the problem
A lot of people just jump straight to designing and building a product, which stifles innovative thinking. You need to ensure you understand the problem you are trying to solve. Start by understanding your customers’ needs. Go out and talk to them. Observe them in their own context. See what they say or do. Observe the problems they face. This will challenge your assumptions about their needs.
Identify and define what your challenges are. Take the focus away from the solution for a while. “How might we…” statements are a great tool for this. Using the light bulb as an example: “How might we…allow people to see at night”.
These are deliberately open statements. They explain the goal, not a prescriptive solution. They will often reframe your understanding of the problem and open up new possibilities.
Generate lots of ideas
Once you understand the problem or the challenges that your business is facing, you can start looking for ways to solve them. A big blocker at this stage is getting stuck on one cherished idea. Whether it’s one person’s pet idea or just the way a company has always done things, it’s the same result – it stops you trying new things.
They key to doing this without becoming fixated on one idea is to generate as many as you can. Surround that one idea with lots of other good ideas.
Collaborative Design is a great tool for generating ideas. This involves getting everyone in a room together sketching, sharing, and creating a vision. This process embraces divergent and convergent thinking, which is a core part of the creative process. This involves ‘going wide’ and exploring lots of ideas, then converging down to one or two refined ideas.
Design is a team sport. Get everyone involved. Designers, developers, product owners, business stakeholders, and executives. Everyone has good ideas to contribute.
Turn your ideas into insights
It’s important to recognise that ideas are just thoughts. Smart business people don’t spend their money on ideas. They test and validate them, proving which ones work and which ones don’t. Turn your ideas into knowledge. You need to prove that customers are willing to pay money for your ideas, as quickly as possible.
There is a plethora of rapid prototyping tools out there. You can create interactive prototypes in a matter of hours. This means you can generate an idea in the morning and have it in the hands of a customer that afternoon.
Be deliberate about what you test
There are many different layers and levels that make up a user experience, some more obvious than others. People often jump straight to testing the more obvious UI levels like the appearance or interaction. When creating a new innovative product, it’s important to test the proposition or concept first.
You need to start with the questions: “Do people value my proposition?” and “Are people willing to pay money for my concept?” Different prototyping techniques allow you to test different levels, either validating or killing them.
Testing one idea usually inspires more ideas. Learning is an ongoing journey. Continue to test and try new ideas as you build a product. These could be for improvements, additional features or an entirely new product.
Fuel the feedback cycle. The shorter the feedback cycle, the sooner you can act and adjust your direction. You should be aiming for days or weeks at most, not months or years.
Don’t be scared to fail
Failure is often seen as a dirty word. This paralyses companies and prevents them from trying something new. Failure is an opportunity to learn. Culture needs to be changed to embrace the opportunity that comes out of failing.
Take lots of small bets
Think big, start small. Take lots of small bets. Experiment in small, inexpensive ways. The other way to say this is to ‘fail fast’. The trick to failing fast is to do it in a constructive way. Do it as quickly. Don’t bet everything on one idea. Embrace the learnings.
Get it out there
Launching a live product is the ultimate way to get feedback. You can only test some ideas by putting them in the hands of paying customers.
Be ruthless about what your Minimum Viable Product includes. What is the smallest set of features you can get in the hands of customers? This isn’t about being perfect or profitable. It’s about how can we get our customers using our product and how we get their feedback.
Prepare to learn and adapt…quickly
Innovators in today’s digital world aren’t the ones hiding away in research and development labs, privately tinkering away on an idea for years. Nor are they the ones who take two years to build and launch a product to the market.
Innovators are the ones constantly trying new ideas. They are the ones who are hooked on the feedback cycle and can’t get enough of that learning fix.
Originally published at Agile Australia in April 2015.
UX designers, we need to change the way we work. We need to stop wasting so much time. We have a well-deserved reputation for retreating to creative studios for lengthy design phases – only choosing to resurface once we have perfected solutions that are pretty, but not necessarily practical. We need to end the pursuit of design perfection and focus on delivering value faster. We need to embrace the Lean movement and streamline the way we work.
The Toyota Production System is essential reading for anyone serious about improving their craft. Everyone can learn from the lean manufacturing principles that Taiichi Ohno and Toyota developed.
Along with Agile, the Lean movement has helped revolutionise the software industry. These practices have transformed digital technology from a monolithic beast, into a disruptive force. This new digital world is reshaping our lives for the better.
Lean is all about continuously striving to improve your effectiveness and efficiency. It’s a focus on delivering value to customers and reducing waste. The Lean UX movement is a set of techniques that have emerged out of a recognition that UX Design practices can and have to improve.
I’ve drunk the Kool-Aid on Lean. I wholeheartedly agree with and embrace the Lean principles. They have changed my mindset. I could never go back to my old way of working; designing in my ivory tower, oblivious to the larger process I was part of. I have learnt to to focus on the value I deliver rather than the techniques I use. I’m actually embarrassed looking back on some of the projects I worked on. Thinking about some of the pretty, yet pointless documents I spent hours crafting makes me cringe. They may have made the client happy at the time, but looking back now, I know there are far better ways to work.
The rise of the Lean UX movement is a formal recognition that our discipline has fallen behind the rest of the digital industry. Traditional UX practices waste a lot of time and money compared to newer, more collaborative ways of working that the digital industry has embraced.
To be fair, these wasteful practices are a historical legacy. We have traditionally had to focus on pixel perfection in big upfront design phases. Once handed over to developers, our designs were never to be tweaked again. Or at least, not until after they launched six months later.
Times have changed. Now designers are the ones guilty of choosing to work in isolation. We often hide behind the ‘creative process’, using it as a justification to separate ourselves from the larger context in which we work. Instead we should be including our business and technical partners in the creative process. We should be using our skills to facilitate collaboration and inspire creative thinking in everyone.
We need to take the focus away from stand-alone UX methodologies and place it on delivering business value.
Here are 10 signs to watch out for that your practices aren’t as effective, efficient or as collaborative as they could be.
1. You start mocking up a solution before defining the problem
People love jumping into solution mode. It’s easy to get excited by an idea and want to play around with it. However, it comes with a risk that you lock in the wrong solution, rather than being open to alternative ideas. You become a hammer looking for a nail.
This doesn’t have to be a long-winded process. Sometimes it can be a 5-minute conversation. Other times, it can be a project in itself. It is important to be deliberate about what you are setting out to achieve and choose your tools and approach to suit the purpose.
2. You have committed to a lengthy interview schedule before you’ve even spoken to one user
Detailed UX research is an expensive overhead that you can often – but not always – live without. When going through the messy problem definition stage, talking to one or two users can provide the insight required to leap forward into concept development. Other times, it opens up a Pandora’s box of other questions to explore. Plan for the opportunity to do some initial interviews. Then consider where to go next.
If you start every project with a statistically significant number of participants, you miss the opportunity to streamline the process.
3. Your research findings report contains 10+ pages of text
This is a great way to produce shelfware that no one will ever read. No amount of text or slides will ever replace the richness of observing your target audience first-hand. Take your client/team out in the field with you, or you’re greatly reducing the value of your research. Seeing a user point out the flaws in your product is the quickest way to convince a CEO to drop his pet feature.
4. The person who came up with your product strategy isn’t involved in building it
This is another great way to lock in the wrong solution. If strategy is seen as a separate, stand-alone activity, you lose the ability to pivot or adjust your concept as you learn.
5. You spend more than one week designing an idea before seeing a user try it
Great ideas are great, but proven insights are better. Over-investing in an idea before confirming what your customer wants it is taking a gamble. It’s setting yourself up to waste a whole lot of design effort. Putting some rough, hand-drawn sketches in front of a user can be enough to confirm a good idea or kill a bad one before you invest in it.
6. Your design mock-ups have version numbers
If you need version controls for wireframes, you’re spending too much time in the upfront design stage. You should iterate in functioning code. Design in the actual medium it will be experienced in.
Okay, sometimes version controls are necessary in large, distributed teams with more complex workflows. However, there is still a point where you need to reconsider your approach. If your version numbers hit double figures, that is the probably the right time.
7. You have perfected your solution in Photoshop before sharing it with a developer
Designers often defer bringing technologists into the process as long as they can, rather than including them from the start. Technology should become an enabler, not a blocker.
Work with developers. If you’re not already designing with them, you are just wasting time. You can never specify everything in a design mock-up or wireframe. You never know exactly how something will work until it is in working code.
Architecture, Industrial Design, Engineering, Fashion. These industries all have ways for the people who design things to collaborate with those who build them. This allows for the differences that emerge when going from paper to the actual medium. Digital technologies should be no different.
8. You don’t know the developer who built your design
See previous point. Add double the guilt – particularly if you complain about them bastardising your design.
How do you expect them to deal with the details/oversights that weren’t captured in a static design mock-up?
Note: The answer to that is not adding more annotations to wireframes.
9. You design UIs and don’t feel an enormous sense of guilt that you can’t code
If you are one of those unicorns that can do both, you can skip to the next point (but know that I am jealous).
I wish I had the capacity to learn how to code. I wish I could design in code. Just imagine how empowering it is to build your own design rather than relying on someone else’s skills. Unfortunately I cannot.
I console myself with knowing enough HTML to at least have a basic understanding of how a page functions in a browser. Without this knowledge, I couldn’t sit down and pair with a developer to tweak a functioning product. It also means I know enough to have a conversation and understand why the design detail I suggested would take so much effort to build. This is an important bridge to collaboratively get to a better, more efficient solution.
If developers roll their eyes every time you approach them, it’s probably because you make their life hard. Learn a little bit about code. It will help a lot.
10. You don’t care what time your day ends
Work smarter, not harder. Working long hours is not sustainable and leads to tiredness and poor quality work.
I love working with people who have a life outside of work. That means they have motivation to get a job done and get out of the building. This creates a focus on the outcome and a desire to be efficient.
We work in a world of commercial realities and limited budgets. If you don’t value your own personal time, chances are you don’t value your client’s time either.
Originally published at www.thoughtworks.com on April 1, 2015.
The role of designers is changing. The growing adoption of Agile development practices has created an opportunity for designers to take the lead. Design thinking skills allow us to take ideas and quickly turn them into clear product visions that put users first. By stepping up as project kick-off facilitators, designers can drive rapid, customer-centric product development and make stakeholder management far easier.
If you want to learn more, come join my Agile Australia 2015 workshop on 16 June at the Hilton Sydney.
See detailed descriptions and register at www.agileaustralia.com.au/2015/workshops. Earlybird registration closes on Friday 24 April 2015, and get a further discount using our promo code, AA15-TW
I’ve just been confirmed as a speaker at the Designing for Mobility 2014 Conference coming up on Friday 14th March in Sydney, Australia.
I’ll be co-presenting with Mr Toby Pritchard who I have been working closely with over the course of the project.
I’m looking forward to sharing the journey that we went on and some of the lessons we learnt along the way. Hopefully I’ll see you there.
Here’s the summary of our talk:
Building a bank’s biggest branch
Building an app is easy, right? 16 year-olds build million dollar apps in their garages every other day. But things get a little trickier when the app you’re building is for a bank.
Designing and coding an app with lots of cool new features is the easy part. Creating a whole new customer channel, that is effectively the bank’s most highly visited branch, comes with a whole different set of challenges including:
- Shifting the businesses mindset from a one-off project to treating mobile as a first-class channel that needs to be supported and evolved on an ongoing basis.
- Provide all the features that customer’s expect from web banking and deliver those in a lean fashion, with a mobile first approach.
- Balancing security and fraud constraints whilst still making the app easy to use for customers.
- Pushing the boundaries of traditional brand guidelines that didn’t translate to native mobile environments.
With a conservative financial institution that’s just beginning to understand how mobile is going to revolutionise its business, you have quite a mountain to climb before your designs can see the light of the app store.
This is the journey that Toby Pritchard (Suncorp) and Ben Melbourne (ThoughtWorks) have recently been through. In this case study presentation they’ll share the highs and lows they went through while rebuilding and launching the new Suncorp Mobile Bank App.