Category Archives: Dev

What Developers Want

Posted on by

If you are a Development Manager here are 5 things that your Developers will thank you for.

1. Quiet: Developers want and need quiet uninterrupted time to write code and solve problems. The need for continuous hours of quiet, uninterrupted code writing is crucial. Uninterrupted means absolutely uninterrupted. Do all you can to restrict direct access to Developers.

For the definitive answer on quiet, and why it is a Developer priority, see Paul Graham’s post: Maker’s Schedule, Manager’s Schedule.

2. GSD: Cut the non essentials and Get Stuff Done: Read Getting Real, by Jason Fried and David Heinemeier Hansson (37 Signals, now Basecamp).

3. Trust: One good Developer will accomplish more than 10 average Developers. Find your top-10 Developer(s). Trust him/her to guide you in the right direction. Don’t manage developers by committee or consensus.

4. Flexibility: Developers are unique individuals. Developers will get more done working at home than when working in the office. They will thank you if you can solve simple life problems, like suggesting work at home while waiting on a delivery. Learn the unique ways to reward each developer.

5. Professionalism: There are 2 types of Developers: (Type B) those that go home after 8 hours and (Type A); those that code at home for fun, read about development, go to meet-ups and conferences, teach others, and contribute code to the open-source community. Promote and protect your Type A professionals.

One last idea for the non-Developer Development Manager. Learn how to code and learn the language that your Developers speak. If you take this as a homework assignment to do on your own time, you will better empathize with the Developer who is working after hours or the one on call for production code.

“One really good person will get done in a day what ten not-so-good people will never get done.”
~James M. Spitze, SCC Sequoia

Breaking Development Conference
Nashville July 2014

Posted on by

Breaking Development Conference – Nashville – July 2014  #BDCONF
Gaylord Opryland Hotel and Convention Center Nashville TN, July 29-30, 2014

THE VENUE
The Opryland Hotel and Convention Center is an immense hotel and conference center, with 40 acres of shops, gardens, and restaurants under roof. The hotel boasts 2,884 rooms. It’s fun just to find your way around the hotel and an awesome place for a web development conference. Over 152 meeting rooms; 600,000 sq. ft. of total meeting space. One ballroom alone has capacity for 7,050 people.

CONFERENCE FORMAT
I really like the format of Breaking Development conferences: Best-of-class speakers, top sponsors, and all sessions in one room, one at a time, with everyone hearing the same thing at the same time.

Attendance is limited and not crowded. I estimate 175 were in attendance, plus speakers and the terrific conference folks from Unmatched Style. You didn’t have to scramble from one track and session to another and don’t miss one session in favor of another. Great way to run a conference, with plenty of time to meet with both other attendees and speakers.

#BDCONF used MailChimp’s Gather App to send txt updates to attendees throughout the conference. This was a great way to keep everyone in synch, especially about evening meetups, etc.

CONFERENCE TAKEAWAYS
Emphasis was on mobile design and UX. I saw 2 main themes: (1) the state of mobile web and how we are struggling to move our design mindset from large screen to small, and (2) new approaches to managing web design/development projects and getting to done (#GTD) faster.

~~~  ~~~  ~~~  ~~~  ~~~   ~-~  ~~~  ~~~  ~~~  ~~~  ~~~  

Following are links to individual session notes from Breaking Development Nashville July 2014:

If you missed the conference in July, the next Breaking Development Conference is in Orlando November 3-5, 2014

Other Takeaways from Breaking Development Nashville – July 2014:

  • Expectations of device: location, context, voice, …
  • Lotsa bashing of the Hamburger Menu. It’s only intuitive to designers/developers.
  • Don’t use Carousels. They don’t convert to click-throughs.
  • Tip: Collaborate on a Google Doc to share note taking.

“If you want to go quickly, go alone. If you want to go far, go together.”
~African Proverb

Content First UX
Steph Hay

Posted on by

Breaking Development Conference – Nashville – July 2014
Conference Session: Content First UX
Steph Hay

Steph Hay presented a fresh approach to web site design by way of defining all of the content and information architecture up front, before you make the first wireframe or comp. The result is an outline of the site’s IA, which resembles a sitemap but is a complete definition of the site and actual copy. This reverses the typical process of adding content after design.

The process follows a user journey/dialog that is approached as a conversation. Elements of gamification are used to help the user seek goals and reinforce the learning experience along the way. Hay spent time in her presentation on this aspect of the process, which I cannot do justice here – but it’s important to the process. My main takeaway is her rethinking of the site development process. Putting content first makes absolute sense if we believe that content is the foundation of website experience.

My Notes:

  • Content First: Create the content and information architecture first, without tradition wireframes and other design techniques. This is a design-agnostic methodology.
  • Feels like a conversation. Promote user engagement.
  • Write all the content and structure in an outline [yields sitemap byproduct].
  • Greatly speeds up the overall a development process by improving front-end definition time.
  • Note: more than one speaker stated a ratio of ~3-to-2 | definition-to-build/activate.
  • Content First is inherently low risk, low res, and low cost. Promotes greater collaboration and helps define the end result more quickly without getting bogged down in design (speculative) considerations. Will result in faster overall development and launch.
  • Use with analytics to determine audience and solve the right problem.
  • Make a content workbook.
  • Language Boards: Core messaging; Choose Your Own Adventure style.
  • Ben &Jerry’s content written from a single statement/tag line.
  • User is Hero; Iterate until you win.
  • Conversation rather than structure. Hero journey; next steps…

Book reference: Make It Stick: The Science of Successful Learning (not Made to Stick) – some degree of difficulty in learning improves retention; applies to user journey as well.

Other conference notes on Steph Hay at BDCONF can be found at: http://www.lukew.com/ff/entry.asp?1899

Steph Hay on YouTube | How Two Startups Used a Google Doc to Plan Their User Interface

“Content Defines Structure, not the other way around.”
~Steph Hay

5-Day Rapid Prototyping
Daniel Burka – Google Ventures

Posted on by

Breaking Development Conference – Nashville – July 2014
Conference Session: 5-Day Rapid Prototyping and Testing – Build for Speed
Daniel Burka – Google Ventures

I’m not sure which Breaking Development session was my favorite but I could really relate to the information about rapid prototyping presented by Daniel Burka of Google Ventures. I was first introduced to rapid prototyping in 1986. The concept is the same today but we have now learned to include the client and customers directly in developing the solution in order to be successful. Amen.

This was an excellent session on rapid prototyping and, more importantly, about quickly getting to a high quality decision on the viability of an idea. Daniel Burka is with Google Ventures, the VC arm of Google. He has prior history with Digg and Milk, both of which are startups by Kevin Rose. Rose is a General Partner of Google Ventures.

A 5-day Rapid Prototype sprint can be applied to many different business ideas, technical or not. The presentation at #BDConf was based upon applying the process toward improving overall sales at Blue Bottle Coffee, based in San Francisco.

5-day Rapid Prototype:

Day-1: Put pressure on the team up front. On Monday, invite 5 prospective/customers to evaluate the prototype on Friday. Five is enough to provide an adequate evaluation and to complete the eval in one day.

Analyze: Dig into the design problem through research, client interviews, and strategy exercises. The client also participates. Listen and learn. The team includes both client and Google Venture folks. Build user flows, look for patterns and thoroughly understand the problems, constraints, and goals.

Day 2: Start to design solutions – but don’t group-think or brainstorm. Rapidly develop as many solutions as possible. Create multiple, individual solutions. By end of day two you want 10 to 20 divergent solutions. Actually write the copy, make sketches that can be matched to real images for build, and sketch out and document each idea thoroughly so that it can be directly prototyped.

Day 3: Select from among the ideas, as whole solutions or an amalgam of ideas. This is not a democratic process. Everyone votes with blue dots on mock-up sketches. All ideas compete and are pitted against others in a bake-off. Executives and leaders who are most responsible get extra/super-votes (e.g. red dots). Being democratic will water down the ideas, just like brainstorming creates design-by-committee solutions. By end of day three you want your three best options.

Day 4: Build the Prototype, usually as a website and/or mobile site mockup: Burkas demo of a low fidelity prototype was actually very graphically rich. Keynote or Power Point make good prototyping options (Keynotopia). Make the prototype clickable, with design elements to simulate real web pages. Use a technique that also makes the demo viewable on a smartphone, tablet and laptop PC.

Day 5: Validate: Show the prototype to the people you invited on Monday to learn what works and what doesn’t work. Again, keep it simple. Burka talked about using a USB camera to view and record phone interaction, over-the shoulder of the customer/test client. No 2-way mirrors and lab coats.

~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  ~~~  

You may also want to read about Google Ventures’ Rapid Prototyping process as documented by Google Ventures and at Venture Beat:

The Product Design Sprint, 5-day Recipe for Startups (Google Ventures Methodology)
Jake Knapp – Design Partner Google Ventures

How Google Ventures Does Rapid Prototyping ‘Design Sprints’ With its 170 Startups

Here’s a link to a video of the presentation: Video: 5-Day Rapid Prototyping – Google Ventures

“We can’t solve problems by using the same kind of thinking we used when we created them.”
~Albert Einstein