Apple announced the iPad on 27 January 2010 and shipped it in April at a starting price of $499. The reaction from enterprise IT was close to unanimous: a device with no keyboard, no file system, no removable storage and no management story was a consumer toy. By the third quarter of 2010, the iPad had already entered the top five devices in enterprise mobility deployments tracked by Good Technology, alongside the iPhone and the first wave of Android handsets. Nobody had procured them. Executives bought them personally, brought them to work, and asked for email access. What followed reshaped collaboration software more fundamentally than any enterprise product launch that year.
What the Form Factor Actually Changed
The tablet did not replace the laptop. It replaced the moments when no computer was open at all. A laptop is a commitment: find a surface, open the lid, wait, sit down. A tablet is picked up. That difference put software into the gaps of the working day — the walk between meetings, the site visit, the queue, the sofa at nine in the evening — where previously nothing had been used at all. The consequence for collaboration tools was immediate and awkward. The applications people wanted in those moments were consumption-and-response tools: read the document, approve the request, comment on the draft, check the number. Enterprise software of the period was built almost entirely for creation and administration at a desk, with dense screens, hover states, right-click menus and multi-column forms that were unusable on a touch screen. The iPad did not create a demand for mobile software. It exposed how little enterprise software had been designed around what people actually do when they are away from a desk.
The Design Lessons That Stuck
Touch removed the pointer. Hover has no equivalent. Tooltips, right-click context menus and small targets all fail. Interfaces had to surface actions rather than hide them, and hit areas had to grow. Screen space forced prioritisation. A dashboard with forty widgets cannot be squeezed onto a tablet. Designers had to decide which three things mattered, which turned out to improve the desktop version too. Sessions became short. Desktop software assumes a continuous work session. Tablet use is two-minute bursts. That drove autosave, resumable state, and interfaces where you can accomplish one complete thing without a setup ritual. Connectivity became intermittent. Offline behaviour stopped being an edge case. Applications needed to hold state, queue actions and reconcile later — a requirement that pushed a generation of enterprise apps toward better data architecture. Notification became the entry point. People stopped navigating to systems and started responding to prompts. That inverted the design problem: the question was no longer how a user finds work, but how work finds a user. The firms that responded well did not shrink their desktop interface. They asked which tasks genuinely belonged on a tablet — approvals, review, comment, status, capture — and built those properly, leaving complex configuration and bulk work where it belonged.
The Governance Problem Arrived First
The iPad also delivered the clearest early case of consumerization outrunning policy. These were personally owned devices, holding corporate email and documents, with no management agent, no encryption enforcement, no remote wipe, and no separation between work data and a family photo library. IT departments that said no discovered that the request had come from the executive team, and that the answer had to become how rather than whether. Mobile device management products that had been built for a single managed handset platform were rewritten for a heterogeneous, employee-owned estate. Containerisation — separating corporate data into a managed workspace on an unmanaged device — emerged directly from this period, as did the practical version of bring-your-own-device policy. Those questions were not solved in 2010. They were merely identified, which is more than most organizations had managed before the devices appeared in their boardrooms.
| Context | Question for the test |
|---|---|
| Touch | Are actions visible and reachable without hover? |
| Interruption | Can work be resumed without losing state? |
| Offline | Does the interface show pending actions and conflicts? |
| Notification | Can the user reach the relevant task directly? |
| Personal device | Are ownership, data separation and wipe rights agreed? |
| Actual setting | Does the task work standing, one-handed and in poor connectivity? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Designing for Mobile Collaboration Properly
- Pick the tasks, do not port the product. Approve, review, comment, check status, capture. Everything else can stay on the desktop, and pretending otherwise produces software nobody uses in either place.
- Design for the interrupted user. Assume the session ends mid-task. Autosave, restore state, and never require a multi-step setup to accomplish one small thing.
- Make notifications the front door. If the work cannot be reached in one tap from an alert, the mobile experience will be abandoned regardless of how good the app is.
- Handle offline honestly. Say what is cached, queue what is pending, and resolve conflicts visibly. Silent failure is worse than no offline mode.
- Separate corporate data on personal devices. Containerisation, conditional access and selective wipe. Full-device management on an employee-owned tablet is a policy you will not be able to enforce.
- Write the BYOD policy before the devices arrive. Ownership, support, wipe rights, expense treatment and what happens at termination. Retrospective policy is negotiation, not governance.
- Test on the actual device, in the actual context. Standing up, one-handed, on poor connectivity, in bright light. Most enterprise mobile design is evaluated on a desk, which is the one place it will not be used.
Why It Still Matters
The tablet moment established a pattern that has repeated with every subsequent device and interface shift: hardware arrives from the consumer market, employees adopt it individually, the experience gap in enterprise software becomes obvious, and the software eventually rebuilds itself around the new interaction model. Phones did this to email and messaging. Tablets did it to review and approval. Conversational AI is doing it now to search and reporting — people expect to ask a question in natural language rather than navigate a menu structure, and enterprise systems designed around navigation feel antique in exactly the way desktop-only software felt antique in 2011. The design lesson from 2010 transfers directly. Do not bolt the new interface onto the old model. Work out which tasks genuinely suit it, build those well, and leave the rest alone.
Common Questions
When did the iPad reach business use?
It was announced in January 2010, shipped in April, and was already appearing in the top five devices in enterprise mobility deployments by the third quarter of 2010 — largely through employee-owned devices rather than corporate procurement.
Why did enterprise software struggle on tablets?
It was designed for pointer input, large screens and long continuous sessions. Touch removes hover and right-click, screen space forces prioritisation, and tablet sessions are short and frequently interrupted.
Which tasks suit tablet collaboration?
Approval, review, commenting, status checks and content capture. Complex configuration, bulk data entry and multi-window analysis remain better on a desktop.
What governance did tablets force?
Bring-your-own-device policy, containerisation of corporate data on personal devices, conditional access, and selective rather than full-device wipe — questions that most organizations first confronted because executives brought iPads to work.
Mobile Collaboration Strategy — Outpace identifies which of your workflows genuinely belong on a mobile device, designs them for interrupted one-handed use, and puts the data governance in place before the devices arrive.