Swivel

Swivel was founded with the conviction that when citizens, businesses, and governments can see data better, they would make better decisions. I designed Swivel's identity and interaction models for social data exploration and storytelling.

Swivel

Swivel was founded with the conviction that when citizens, businesses, and governments can see data better, they would make better decisions. I designed Swivel's identity and interaction models for social data exploration and storytelling.

1. Context

[↓] Swivel started with a story about the problem we wanted to solve and the things we thought we'd need to build to bring it to life. My job as Swivel's first designer working with the company's founders was to give the story a shape.

2. Definition Document

[↓] We undertook a set of activities to home in on the mission of the company: workshops with the founding team, user interviews and user needs analysis. I assembled this work into a definition document that described the company's vision. This document was used to secure VC funding.

3. Interaction Planning

[↓] The scope of the product was daunting. I worked to create a hierarchy of interactions with the product while suggesting areas to begin tackling.

4. Site Inventory

[↓] I created a site architecture for the product. We were going to need to move quickly and staying organized was critical.

5. Task Flow Diagrams

[↓] Swivel involved creating web-based charting and spreadsheets. Getting this working in the mid-2000's involved building these technologies from scratch. These diagrams were used to help the developers understand what behaviors they would need to build.

6. Wireframes

[↓] I sketched the wireframes for the product using a Wacom Cintiq tablet and Adobe illustrator. Charting, spreadsheets, and data reports formed the heart of the product.

7. Visual Design

[↓] When Swivel was launched in 2008, it was unclear whether business users would be willing to rely upon cloud-based applications. I designed the product to feel like a productivity application rather than a website in the hopes that we could encourage them to make the transition.

1. Context

Swivel started with a story about the problem we wanted to solve and the things we thought we'd need to build to bring it to life. My job as Swivel's first designer working with the company's founders was to give the story a shape.

2. Definition Document

We undertook a set of activities to home in on the mission of the company: workshops with the founding team, user interviews and user needs analysis. I assembled this work into a definition document that described the company's vision. This document was used to secure VC funding.

3. Interaction Planning

The scope of the product was daunting. I worked to create a hierarchy of interactions with the product while suggesting areas to begin tackling.

4. Site Inventory

I created a site architecture for the product. We were going to need to move quickly and staying organized was critical.

5. Task Flow Diagrams

Swivel involved creating web-based charting and spreadsheets. Getting this working in the mid-2000's involved building these technologies from scratch. These diagrams were used to help the developers understand what behaviors they would need to build.

6. Wireframes

I sketched the wireframes for the product using a Wacom Cintiq tablet and Adobe illustrator. Charting, spreadsheets, and data reports formed the heart of the product.

7. Visual Design

When Swivel was launched in 2008, it was unclear whether business users would be willing to rely upon cloud-based applications. I designed the product to feel like a productivity application rather than a website in the hopes that we could encourage them to make the transition.

1. Context

Swivel started with a story about the problem we wanted to solve and the things we thought we'd need to build to bring it to life. My job as Swivel's first designer working with the company's founders was to give the story a shape.

2. Definition Document

We undertook a set of activities to home in on the mission of the company: workshops with the founding team, user interviews and user needs analysis. I assembled this work into a definition document that described the company's vision. This document was used to secure VC funding.

3. Interaction Planning

The scope of the product was daunting. I worked to create a hierarchy of interactions with the product while suggesting areas to begin tackling.

4. Site Inventory

I created a site architecture for the product. We were going to need to move quickly and staying organized was critical.

5. Task Flow Diagrams

Swivel involved creating web-based charting and spreadsheets. Getting this working in the mid-2000's involved building these technologies from scratch. These diagrams were used to help the developers understand what behaviors they would need to build.

6. Wireframes

I sketched the wireframes for the product using a Wacom Cintiq tablet and Adobe illustrator. Charting, spreadsheets, and data reports formed the heart of the product.

7. Visual Designs

When Swivel was launched in 2008, it was unclear whether business users would be willing to rely upon cloud-based applications. I designed the product to feel like a productivity application rather than a website in the hopes that we could encourage them to make the transition.

8. Impact + Takeaways


Swivel collapsed under the weight of its own ambitions. The problem we set out to solve was too poorly defined (and too naive) to be successful. The product scope was far too large for a small team.

  • The designs I created far outstripped the development team's ability to deliver. While vision is useful when you're inventing something, it's important to stay focused on the value you're trying to deliver to customers.
  • How quickly and cheaply a product team can learn is far more important than attempting to "get things right" from the start. Teams (and designers) learn fastest by shipping.
  • It's critical to recognize when the idea for your product makes too many unfounded assumptions about what must be true. So many startups fail because of this. We did too.
  • I applied the lessons I learned to the next startup. Apigee succeeded where Swivel failed.

8. Impact + Takeaways


Swivel collapsed under the weight of its own ambitions. The problem we set out to solve was too poorly defined (and too naive) to be successful. The product scope was far too large for a small team.

  • The designs I created far outstripped the development team's ability to deliver. While vision is useful when you're inventing something, it's important to stay focused on the value you're trying to deliver to customers.
  • How quickly and cheaply a product team can learn is far more important than attempting to "get things right" from the start. Teams (and designers) learn fastest by shipping.
  • It's critical to recognize when the idea for your product makes too many unfounded assumptions about what must be true. So many startups fail because of this. We did too.
  • I applied the lessons I learned to the next startup. Apigee succeeded where Swivel failed.

8. Impact + Takeaways


Swivel collapsed under the weight of its own ambitions. The problem we set out to solve was too poorly defined (and too naive) to be successful. The product scope was far too large for a small team..

  • The designs I created far outstripped the development team's ability to deliver. While vision is useful when you're inventing something, it's important to stay focused on the value you're trying to deliver to customers.
  • How quickly and cheaply a product team can learn is far more important than attempting to "get things right" from the start. Teams (and designers) learn fastest by shipping.
  • It's critical to recognize when the idea for your product makes too many unfounded assumptions about what must be true. So many startups fail because of this. We did too.
  • I applied the lessons I learned to the next startup. Apigee succeeded where Swivel failed.

Thanks for viewing my portfolio.

© Jess Ruefli 2025