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.
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?”
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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. To 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.
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:
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.
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.
How do you encourage customers to repeatedly choose your brand in the face of alternatives?
Traditional loyalty programs are built on mechanics from the 1700s. Around this time, American retailers started to give copper tokens at the point of sale that could be redeemed on a future purchase. Fast forward three centuries and modern loyalty programs actually haven’t changed too much. Sure, now there are more advanced ways to collect and redeem rewards, but the points for prizes model is still fundamentally unchanged.
A Reward Program is Not Enough
Conventional programs enthuse in the beginning, but bore over time. In 1993, Wolfram Schulz, a professor at the University of Cambridge ran an experiment with a monkey named Julio. Julio was placed in a room with a monitor. If he touched a lever when a squiggle appeared on the monitor, blackberry juice would run down a tube and into his mouth. Over time, this became a habit. Julio came to anticipate the juice and it was less of a reward, and more of an expectation. The same logic can be applied to traditional loyalty programs. A new program often triggers a flurry of attention – they’re shiny, new and exciting. After the initial hype customers come to expect benefits. The program ceases to delight as rewards become expectations.
Most programs don’t achieve their promise. According to a 2013 McKinsey study, North American companies spend $US50 billion ($AUD68 billion) a year on loyalty, but for many the return on investment is negligible. Companies with a strong focus on loyalty programs had weaker sales growth and margins than companies with less focus on loyalty. Why? It may well be that these companies dedicate their resources to initiatives that erode margins and don’t actually encourage shoppers to choose their brand over alternatives. For example, consider the common habit of providing coupons for customers on products that they would have bought at full price anyway.
How can brands avoid this expensive ‘design, launch, promote’ cycle and move towards ‘continuous loyalty’? We propose new principles to create ‘whole brain loyalty’. The kind built on feelings of trust, affinity and habit – not reward programs. The most successful retailers move beyond functional benefits and concentrate instead on creating desire with meaningful and pleasurable interactions.
Personal: Build 1:1 relationships at scale. These must take into account customers’ unique interests and provide them with opportunities that resonate with them as individuals. Nike is focusing on personalization in 2016 with its new Nike + app. The tool is designed as a VIP training and retail experience. In addition to a personalized product feed the app allows customers to book a one on one in store consultation, find running groups nearby or chat with a training and fitness expert.
Relevant: Build loyalty by creating a sense of shared value. People care about different things: for some customers it’s about price, for others it’s convenience, for others it’s exclusivity, prestige or uniqueness. Make a concerted effort to build up an understanding of what’s important to your key customers and allow them to shop on their own terms. Harvey Nichols takes their traditional rewards program up a notch by letting customers choose their rewards each quarter. The company conjures up a list of enticing rewards every 3 months, from casks of premium wine to express pedicures to avant garde dinners. If nothing appeals, customers can opt for vouchers instead.
Contextual: Truly understanding context allows for the definition of moments of influence and moments of delight. What are the broader problems that they are trying to solve? What are they trying to achieve? Starbucks gets context. They embed coffee effortlessly into the broader setting of their customers’ lives. For situations where time is of the essence, customers can use mobile order and pay to shave minutes and seconds off the rushed coffee run. For a more leisurely brew, the brand provides a relaxed atmosphere with free wifi and charging stations so that customers can comfortably linger. They understand different contexts and build their brand experience to support them.
Connected: Connect people in two ways – by taking advantage of interpersonal connections and using technology to make a connection at meaningful moments. For example, Domino’s Pizza Mogul platform is groundbreaking because it rewards customer advocacy rather than dollar spend. A Mogul can earn money with Domino’s without even purchasing a single pizza! Moguls create pizzas, promote them and receive a royalty for each pizza sold. This highly engaging program turns the brand’s most loyal customers and followers into particularly effective fans.
Customer-centred: Companies that put the customer’s needs and life context at the heart of their loyalty programs consider partners that can offer an extended ecosystem of complementary products and services.
A New Paradigm: Four Steps to Building Real Customer Loyalty
Step 1. Define the Customer’s Why
A key theme of the breakfast series was ‘Understanding the customer’s why’ as it leads to new ways of thinking. For example, instead of focusing only on how to make a shirt cheaper (a functional benefit), the focus turns to how to create a more uniquely personal shirt that the customer can’t wait to wear on the weekend (an emotional benefit).
Step 2. Design the Experience
Don’t focus on a single touchpoint. Build an entire customer journey, where each touchpoint contributes positively to building loyalty. This takes into account ways to influence behaviour from pre-purchase through to the use of products post-purchase.
Step 3. Take Action: Test and Experiment. Gaining insights as part of an ongoing dialog with customers allows retailers to be more creative and responsive in delivering initiatives that actually build loyalty. The process of continuous testing and learning supports the notion of an adaptive brand experience. Great ideas evolve over time, informed by greater insights as customers respond (or not) to new initiatives and solutions.
Step 4. Continuous Loyalty: Loyalty is nurtured. Retailers should create capabilities that evolve with the customer. To do this, your organisation needs the right platforms and structure to test with customers and refine new ideas based on feedback, data and insights. This allows businesses to follow a repeatable model that drives speed to value by developing a consistent process for developing and delivering innovation.
Today only few retailers around the globe are running loyalty programs that actually win customers’ hearts as well as realise positive financial returns. New technologies coupled with a dizzying pace of change mean there’s a golden opportunity for retailers to rethink their approach to loyalty. Retailers that embrace the Continuous Loyalty approach are most likely stay relevant with rapidly evolving customers.
While coding in XP ways for the past few years, I have realized that in any Agile project which crosses the one year mark, there is a definite chance that the code base is not as flexible as it was during the start of the project. As releases happen, more and more stories are churned out by the developers. This accounts for a lot of additional code – a lot !
As the application evolves, so does its architecture. It becomes so important to look for ways to enhance the existing design rather creating one for every new feature or advancement. Patterns emerge and are handled to ensure maximum reusability and code quality.
But not without challenges! Over a period of time the reasons behind key decisions may be forgotten. Critical tech debts may be uncleared. Lack of context and ambiguity may slow down the pace of development.
I have outlined four simple and practical methods that will make the adoption of incremental design for a project that much easier. What’s more is that three pertinent target groups – the individual developer, the team lead and the team at large can use these four methods, just as effectively as the other.
It is of paramount importance that team members understand the business requirement.
One should ideally avoid creating ‘execution flows’ for each use case. The goal of good design is to produce maximum code reusability and simplicity. Trying to identify the minimal set of responsibilities for each component or layer and creating abstractions, accordingly, is a recommended best practice.
One could ask themselves, this question – what is the least that this component should accomplish? For any thing else, should we create a separate component or unit of responsibility? The answer can help identify the common/reusable logic. This practice also prevents big, bloated components that have virtually zero reusable code, within them.
I have seen strict TDD be compromised, many times. A test that’s written after all the code is already written, reduces chances of it being effective. Why does this happen in the first place – Sometimes because of release cycle pressures or sometimes to prevent clean test helpers and builders from getting too complex or because of a poor safety net that exists within the code base leading to disinterest.
Though none of these scenarios are reasons enough to stop a developer from practicing strict TDD, it’s at these points that stepping up can make a significant difference. The team should not lose hope and boost their morale against such ‘forces’. This is because incremental design may never happen without strict TDD.
The design of the application evolves all the time. During code pairing, it is the role of the ‘navigator’ to look at the larger picture. There are instances where I have seen both the paired up developers taking on the role of the ‘driver’ i.e only looking at ways to solve the problem at hand. And that’s not the quality of collaboration, recommended.
Another best practice for project members is to take major changes in design or architecture to a ‘white board’ discussion. This brings in collective thoughts and feedback. Also important is refactoring becoming a regular practice of each story. Else, time would be expended with frequent re-design and this is not refactoring!
Developers could have frequent dev-huddles. This will enable the team to put up related stories to play upfront, discuss possible design approaches – all this helps keeping abreast of what is to be expected in the days ahead. Also, tech-debt is something that the entire team should be monitoring and it helps to ‘pay’ them off!
The team could carry out an exclusive tech retrospective, after every release to have a clear overview of the architecture’s evolution, the kind of tools that helped them and the practices that have been effective, etc.
Identifying future spikes that may be necessary both, from a tech-debt and future requirements point of view alongside the entire team’s feedback is valuable when shaping the course of the project.
While building and maintaining enterprise level applications is a whole other ball game with a different set of challenges, keeping the bigger picture in mind makes every challenge surmountable.
What do Go and Swift have in common? These open source languages are great examples of how some of the most influential software in production today is coming not from traditional software companies, but from industry leaders like Google and Apple, through to disrupters like Uber, and tech industry giants like Netflix, Facebook and Twitter.
The result is that open source is eclipsing the traditional software vendor companies (think Microsoft, IBM and now-defunct Sun Microsystems). Why?
Open source as a platform is driving a virtuous loop in the ecosystem of today’s companies.
Here’s how it works: By opening up their software tools to the public, companies advertise their tech credibility and can better compete for top talent. In turn, these talented programmers drive innovation at their employers, improving their open source platforms and creating new open source, and closing the virtuous loop.
This plays out on two levels. First, developers who are considering a new employer can gain a deep understanding of the companies they are considering working for by taking a test drive on their open source platforms. Though not everything is open to the public, the open source offerings of a company are a good indicator of the level of innovation, professionalism and opportunity taking place behind closed doors.
Secondly, the level of commitment to open source goes a long way toward showing how an organization lives out the ethos many tech companies aspire to, which is to make the world better, by making software better one step at a time. By opening up the code, architectural decisions and other programming techniques, companies are helping programmers across the globe solve software problems every day. Many programmers want to work for organizations that live out that mission, and having a robust open source library supports that ethos.
Consider, then, that two of the most influential open source companies are considered destination employers by developers: Facebook and Twitter. Facebook routinely has multiple blips on ThoughtWorks’ Technology Radar; major open source platforms include React Native (cross-platform native apps), Buck (a build system) and Flux (UI).
Twitter also ranks high for open source, with Bootstrap (a complete website framework), Zipkin (distributed tracing), Bower (package management), and Cascading (Big Data and Hadoop).
Looking ahead, the open source mindset is playing out in interesting ways across the globe.
It’s important to understand why open source even exists as a concept. Many traditional business people wonder why these companies are giving away something that they could be charging for. Or, they question why an organization would share ways of doing things that could take away their competitive advantage.
In reality, even the most open source friendly companies do not provide open source access to their most competitive products or offerings. Those projects continue behind closed doors and might only be released as open source once they are mature technologies and they have moved beyond the leading edge.
But for many companies driving open source, the software is no longer their business differentiator, even though it may have been in the past. Netflix is a good example: when Netflix was figuring out how to stream video content, their competitive advantage was the technical know-how to make that work at scale. Now, though, many other companies have figured out how to stream, and it’s a commodity capability.
Partly as a result of that shift, the real business differentiator for Netflix now comes from its licensing deals and content creation strategy. Certainly, being technically forward-looking is integral to the business (which is why they must continue to attract and retain top tech talent), but the real competitive advantage for the enterprise has moved beyond software.
Not surprisingly, then, Netflix is a powerhouse when it comes to open source, in particular with Simian Army (arguably its most famous open source tool, for testing failure in production), Hystrix (for building components that tolerate network latency and failure) and Spinnaker (Continuous Delivery to multiple clouds).
Likely the greatest effect open source has on business is how organizations use software to advance their business goals. In the past, enterprises contracted with a technology vendor such as IBM or Microsoft that supplied them with the software platforms, tools and libraries they needed, trained their staff and managed maintenance releases. As new or improved technology came along, the vendors offered new features and drove innovation on their platform.
Though the vendor relationships still exist, it’s no longer an exclusive relationship. It is now “business as usual” for companies to choose an open source tool or platform instead of one provided by a vendor. In some cases, open source is actually preferred because of the extra flexibility it offers.
One of the best examples of this phenomenon was shown by Twitter’s Bootstrap, an open source platform that allowed people to quickly build a very richly interactive website, the likes of which were previously available only by working with a trained designer. Almost overnight, this open source tool raised the bar for organizations. Suddenly, it was necessary to have a good website and an app, no matter the size of the organization or the reach of the product.
Major open source players have some of the most influential frameworks and libraries in the industry. Much of the explosion in open source has been driven by publicly available project hosting and collaboration tools, the most important of which is GitHub. The “social coding” model of GitHub allows programmers to follow projects and other programmers, to discuss software features and proposed changes, and even to directly review new code submissions.
In my recent article, Macro Trends in the Tech Industry, I wrote about the phenomenon that developers are communicating primarily through code, using tools such as GitHub. This allows increased efficiency and productivity, and is giving rise to “internal open source” within organizations looking to boost their output.
This open source trend is likely to continue across companies. Microsoft continues to embrace open source with the .NET platform, and it will be interesting to see if they consider any of their other flagship assets as potential candidates for open source. We’ve highlighted the “new wave” of openness at Microsoft—for instance, their release of Office for iPad—and we expect this trend will continue.
At the same time, newer players are embracing open source. Uber, for instance, has five open source projects on its site. Square has eight, including Dagger (a dependency injection framework). Certainly, Uber and Square rely on technology for their business, to move people and goods (for Uber) and to process credit card payments (for Square). But software is not their only differentiator, and so it makes sense for them to participate in open source. In other cases, open source will advance one project at a time, just as the tech community makes software better one step at a time. Software providers need to continue to listen to their customers or their consumers, and adapt.
For instance, at ThoughtWorks, we recently released GoCD, a Continuous Delivery tool, as open source. Our clients said they wanted this not because they didn’t want to pay for a closed-sourced tool; instead, they asked for us to open it up so they could do more with the product and make it their own. For us, this was a no-brainer: By providing GoCD as open source, we were actually providing more value to our clients and making it usable by more people.
The energy surrounding open source is not going away, and we are looking forward to seeing how more organisations can contribute to the overall health of our industry, collaboratively making software better.
This is the scene; on one side, we have the Android platform developers and on the other, the hackers. Just as with any software system, Android has its list of security problems. And it’s a pretty close race between the two sides.
In spite of the world’s most accomplished security professionals working on the Android platform’s, there have been cases where a user should not have ‘trusted’ the released application.
The flexible platform works on heavy collaborations between applications and dependencies can range from simple to complex. In this scenario, the dependencies are bound to be exploited to acquire data, passwords, and eventually control over the application.
In this article, I share my learning around security measures developers must take into consideration to avoid introducing vulnerabilities in our Android apps. Let’s look at a typical Android application. On studying the diagram, if asked to list down the components that could leak some kind of data or capabilities from Android, what would be the answer?
Every single component!
Yes, every component could be exposing data if we are not taking the necessary precautions.
I am sure, you say, the Android permission model is in place and therefore we should not have to be so scared. Yes, it’s often easier to write a secure app in Android than it is to write an insecure app but only if one knows what’s safe and what’s not safe.
In this first post in the series, I share some dos and don’ts and a few tools to help one develop a secure app.
Be careful while dealing with intent-filters.
Requirement: Need to start the same service for two different jobs.
Implementation: Code can be found here. Say this is App1.
To understand the difference between explicit and implicit intents, read –https://developer.android.com/guide/components/intents-filters.html#Types
Because an intent filter signals to the Android system that you want these components exposed to other apps, it’s a good idea to make an explicit decision whether to mark a component as exported. Android doesn’t require you to do so, but as you see, there are security repercussions to not doing so.
If you choose to set the value of “exported” = “false” in your intent filter definition, you can prevent accidentally exporting internal components.
In the AndroidManifest.xml
Think about it – If you didn’t intent a component to be exported in your app and maybe some months later you or a colleague adds an intent filter for something they need, they might inadvertently export that component and it could cause a security vulnerability later.
Note: If you do wish to make your components available but only for limited use, there are permissions you can grant in the AndroidManifest.XML.
The above solution will help solve the Confused Deputy Problem.
Let’s take an example:
Android OS has a Wi-Fi manager which is inside the system server. Now our app has a service that talks to the Wi-Fi manager.
But what happens if your app is exposing a component (say through an exposed intent-filter) that is part of the Wi-Fi control and the attacker decides that it can ask your app?
It is being “deputized” by the Wi-Fi manager and it has leaked information to the other app without the correct permission.
You can avoid your app from being deputized by a malicious app by: