Design Agility for Startups
•Télécharger en tant que KEY, PDF•
8 j'aime•4,984 vues
An overview of how Betaworks develops products, and general principles designers and startups should consider.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (16)
Similaire à Design Agility for Startups
Similaire à Design Agility for Startups (20)
Dernier
Dernier (20)
Design Agility for Startups
- 1. Design Agility for Startups Or, how design gets done at betaworks Neil Wehrle VP User Experience, betaworks
- 2. betaworks
- 3. Invest + Build
- 4. not
- 5. stem cell for the internet
- 6. big data + real-time + social
- 7. how we work
- 9. UR UR UR IxDIxD IxD Web Mobile VisDVisD VisD CSS CSS CSS
- 10. Product Fit Scale Hallway Test Business Audience Evolution Test
- 11. 2008 2009 2010 2011 2012 Chartbeat Firefly Newsbeat Downfly SocialFlow Bitly Pro Bitly Twittergram Twitabit Switchabit News.me Findings Swirl
- 12. what it looks like
- 13. “At Pixar…production only begins after the company has critiqued a story in reels, or roughly animated storyboards, six or seven times. They edit and reedit before they film.” - The New Yorker
- 14. detail use case end-to-end
- 18. Observe
- 20. have a POV
- 21. Chartbeat First Principles •We do the hard work •Easy to understand •Immediate •Shallow •For the front line •Real-time •Actionable
- 26. culture matters
- 27. “Software design is a cultural experience” - Agile Experience Design, Ratcliffe + McNeill
- 28. agile, not Agile
- 29. demo culture
- 30. sit together
- 31. <hacker> culture
- 32. detail core use case end to end iterate like crazy: sketch, whiteboard, wireframe, prototype have a POV and stick to it observe users but don’t get used culture matters more than you think
- 33. Design is how it works. – Steve Jobs
Notes de l'éditeur
- \n
- Betaworks is a unique kind of environment for a designer to work in. Its not a startup in and of itself. Its not an agency or an incubator or a talent show. Before I tell you more about what I do there, its important to set the stage by telling you how it operates. \n
- Betaworks is unusual in that it both invests in and builds companies. Typically, it invests in seed-stage startups, meaning really small, early stage companies. We also build products, almost always from our ideas generated internally.\n
- Betaworks is emphatically not an incubator. An incubator typically takes in startups and provides them with a set of services for an amount of time in exchange for equity. You&#x2019;ll see more about why this distinction is important later on.\n
- Betaworks is more like a stem cell for the internet. Stem cells are these amazingly powerful cells that have the ability to create other, more specialized cells, without losing their abilities. Betaworks is only about 10 people, and we&#x2019;ll grow a bit before spinning off a team into a separate company.\n
- Betaworks has a particular focus to date that holds that big data, real-time, and social are significant drivers for the foreseeable future. Big data: extremely large, often times unstructured data sets. Real-time we feel is much more than just regular stuff speeded up, that it can be valuable by itself. Social gestures by users are very powerful signals that can provide another level of structure to data.\n
- \n
- Cameron Koczon of Fictive Kin coined (I think it was him) the term &#x201C;Design Stack&#x201D; to refer to the set of capabilities designers should have. Its a reference to the IT or Tech stack that developers use to build. I&#x2019;ve abbreviated mine here to represent the core set I use most often.\n
- There are 3 of us on my UX team at betaworks, and we work across multiple products simultaneously. The distribution of skills across my team shows a nice overlap and complement. I&#x2019;ve mapped it to web and mobile since that&#x2019;s a significant distinction for us, as we&#x2019;re doing more work in that area.\n
- We don&#x2019;t really have names for the phases of work we do - things are pretty fluid and are subject to the dynamics of each product team. Typically Betaworks starts with a core idea that fits into our view of things, and progresses through a series of stages - hallway test, a beta or audience test, evolution of the business, and scaling up the product, the team, etc.\n
- Putting what we&#x2019;ve done to date on a timeline reveals some interesting things. Early on, there&#x2019;s quite a bit of exploration and investigation into use cases that will endure. \n
- Ok, enough diagrams - what&#x2019;s it look like to work at betaworks? I&#x2019;ve put down some thoughts in the story of start of Chartbeat, a real-time analytics product. \n
- \n
- One of the first things we do at Betaworks is to identify the core use case and build it end to end. Focus on what we know, what&#x2019;s in front of us, and build it so we can get a clear idea of what its like to use it. We have some rough metrics around 100 days and certain budget to get it up and running. These typically are technical prototypes that my team works with an engineer on. \n
- This is really the beginning of the Chartbeat family tree - something we called Firefly. This was a product that let users chat in realtime on a website. The site owner would put a bit of javascript on their site and users could click on a switch that would put an overlay on the site. Site owners loved the data they could get, that showed the number of clicks, duration, were users typing, mousing, etc. on their site. We found that because it was real-time, there had to be a significant number of users on at the same time, or else the experience was lacking. Users at first loved using the tool, and were pretty freaked out about chatting with strangers. \n
- The quality of the conversation invariably declined. We took notice of the site owners enthusiasm and decided to dodge the more difficult task of satisfying a general user audience and built a dashboard for site owners.\n
- This is the first beta version of Chartbeat. While its a bit rough, building it out end-to-end allowed us to get a clear sense of what was possible, and what users wanted from such a service.\n
- \n
- THe next thing we did was start watching people use the site. We were after insights on multiple levels - tactical usability stuff, but also a better understanding of who would use this. We started off thinking it would be a tool for bloggers, but realized that low traffic made the tool uninteresting. Large publishers and businesses, however, were starting to grasp the &#x201C;viral loop&#x201D; that existed where they would send out content, and see the immediate effect on their site. They could see how many people, where they were coming from, and where they were going in real time. This was important when the lifespan on content online is measured in minutes and hours, and people needed to decide whether to double down on an article or not.\n
- What I call a POV is a strong, easily articulated point of view about what you are trying to do. This becomes your success metric - adhering to this helps guide you when user feedback gets too granular, or you&#x2019;re trying to distinguish yourself from the competition. \n
- For Chartbeat, we regrouped at this point and came up with what I think is one of the most critical elements of a successful startup. This is a subset of the whole set, but there are a couple in here that I think are at the heart of the product - making it for front-line users, and making it actionable. \n
- This is a actual manifestation of those priniciples - the F-shaped information hierarchy lets people find the 3 most critical data elements in a pattern they are accustomed to.\n
- Models are incredibly powerful for fast-moving teams because they force you to articulate ideas and test them out in a cheap and easy manner. \n
- Sketching, wireframing, mockups, clickable prototypes all help move ideas forward, and become a shared space for the team to come together and understand what it is they&#x2019;re building. We spent a good amount of time on this for Chartbeat, and it still happens now. \n
- Just to conclude this part of the story, this is what Chartbeat looks like today. There are derivative products, and they all still adhere to the core principles set out early on. This is a single page, made for front-line workers, that provides them with actionable data to make decisions about their content. \n
- As someone that works across a lot of different teams, I get to see a huge variety of management styles, leadership, team dynamics, etc. Some founders exhibit a strong presence in product development, others are happy to get help and focus on other aspects of a busy job. \n
- It won&#x2019;t go without saying that software design is a cultural experience. Hiring the right team is crucial - finding people that &#x201C;get&#x201D; product will save a ton of work. The best teams I&#x2019;ve seen view UX as everyone&#x2019;s job, and they feel free to raise issues and contribute. \n
- I like to describe the way work as agile with a lowercase &#x201C;a&#x201D;. Methods like this in particular are an important part of the culture - it is tangible, visible, transparent - and becomes another touchpoint for the team. Daily standups help everyone understand who is doing what, when, and whats been accomplished.\n
- Betaworks has a really strong demo culture, where teams stand up weekly and present their work. Each team may do it a little differently, but constantly presenting and seeing what everyone is up to helps promote understanding and teamwork. \n
- At Betaworks proper, and at each of the teams and the more mature companies, everyone is co-mingled and sits together. \n
- Almost everything at Betaworks started out be someone hacking - looking at the Twitter or Bitly firehose, or combining APIs in novel ways, experimenting with ideas. We have a small team, but there are backend and frontend hackers who aren&#x2019;t assigned to any product that float and work on most everything. My team too, operates this way, so we can cross-polinate ideas that work well into other teams.\n
- To wrap up, these are some of the key factors for UX designers when working in product development. \n
- \n