Building the Activity Stream. Part 1: Product Design

We recently launched our new Activity Stream. What began as a small idea turned into quite the large engineering undertaking. The results are astonishing, but it was a lot of hard work. In this part we’ll share how the design took shape.

 

Whiteboard and paper drawings

Each larger project at Small Improvements begins with a rough written draft, and a kickoff meeting that involves PM, developers, designers and a customer-team person. User stories are extracted, prioritised and then broken down into manageable MVP plus one or two “expansion releases” so it’s clear they are not part of the original release. Then the product design work starts (and if needed, we’ll conduct  some code exploration too to rule out major obstacles)

We use whiteboards and paper drawings to try out ideas, discuss and iterate quickly. Here are some of the many initial ideas for how to represent complex concepts like our cycles in a changelog:

as-paper.jpg

Wireframes

Lots of future problems can be avoided by coming up with good quality wireframes. So after the paper scribbles were done, we went to paint proper wireframes. Here are two examples of how we described the overall architecture of the activity stream, then followed by an actual sample wireframe.

wireframe 1.png

wireframe 2.png

 

We don’t take wireframes too seriously of course. Wireframes are a plan, not a committment to the future product, and everything is still up for change.

Also, quite often the real challenge lies in the user flow, not just in screen design. Some flows can be simulated at the whiteboard or by moving paper pieces around, but we typically move to InVision quickly. Using a web-based tool allows us to create actual clickable prototypes, and get insight from other (possibly remote) staff easily.

 

Mockups

A high fidelity image can raise unrealistic expectations (“oh look we’re almost done”) or draw attention to the wrong details (“why are there 20px margin, shouldn’t it be 30px?”). But on the other hand, the more realistic our mockups look like, the more and better feedback we get from outside the core team.

It’s not about pixel perfection at this stage, everything can still get adjusted. But it is about making things feel “real” sooner than later, so that staff feel encouraged to give feedback about the flows, and so that early access customers feel they are actually commenting on something we are serious about. So we quite like our high fidelity mockups!

 

mockup-comment.png

(The above is just a screenshot, but we typically make mockups clickable so it’s clearer what action takes you where)

Code level prototypes

We prefer to not write lots of “real” code before there has been some agreement on the flows between screens. Yes we’re agile, and yes we can make changes down the track. But starting to code user flows without first sketching them has failed us too often.

So once we start coding the frontend, we have a somewhat good grasp of a feature, and this makes coding quicker, and styling is also more fun when you don’t have to fear everything changes totally next week.

As designers we love to get down and dirty at the UI level too. But it’s not scaleable to be positioning every button ourselves. We invest time teaching design principles to frontend developers, and make everyone follows our living style guide, so we can focus on the advanced stuff, not on placing basic buttons.

 

User testing

Once a feature has been developed to alpha stage, it’s time for user testing. We aim for conducting some some 5 to 10 “successful” user tests for larger features or changes. If user tests show there are major problems in our designs, then we reset the counter, keep adjusting the design, and schedule further user tests.

We prefer a combination of tests. On one hand we like watching experienced customers explore their existing content with new features enabled. On the other hand we like scenario-driven tests where we present users with concrete tasks, using a synthetic demo content setup (so people aren’t afraid to break things). Both have their place, but usertesting is such a complex beast that we’ll blog about it separately. 🙂

 

Launch

When the tests confirm that a feature works, it is time for the polishing phase, and we’ll gradually enable features to our beta program customers. After another round of feedback, answering questions and polishing, it’s time for a wider rollout to clients who didn’t sign up for the beta. Now proper documentation needs to be written, blogged, and announced in-app using Intercom or home-made hints.

And then it’s time to roll out for real and celebrate!

celebrate.jpg

 

SI Process Hacks – The Internal Product Changelog

Development is hard. But communication is even harder – especially across departments and continents. Our SI Process Hacks series will highlight a few simple hacks  we wish we had known right from the start!

The problem

We deploy many times a day –  bugfixes, feature improvements, new options, changes in user flows etc. As a developer, you know when you committed, and you can see your commit go live in real-time:

Screen Shot 2016-07-03 at 13.23.56.png

But as the developer on another subteam, or especially as a non-developer, git-hashes are not really your preferred way of looking at things. It’s tricky to know when what change goes live on what day. Knowledge of changes is crucial, you don’t want to demo the product to a potential client and get caught off guard by that new button on a core screen.

We tried using Slack to keep people in the loop, we considered using a special Trello board, or including even tiny changes into our Release Notes. But everything was just complicated and never quite flexible either.

Continue reading

Introducing Development Team Leads

The challenge: Scaling

Our dev team has reached a quite impressive size these days! Unfortunately I just don’t scale to this size. I can’t possibly conduct 1:1s, listen to feedback, give feedback and help people grow in a flat team of 12 people. While I don’t code anymore these days, and have assigned most project management tasks to Feature Coordinators, lots of new responsibilities of a growing company are now on my plate. I just have to lean on others so that every dev team member gets the attention they deserve.

That’s why we introduced the concept of Team Lead two weeks ago.

Continue reading

The current state of DevOps

In course of the DevOpsDays 2015 in Berlin, Small Improvements is going to host a Docker meetup with John Willis of Docker Inc on October 26th!

John’s presentation covers the current state of the DevOps movement as presented by one of the original “Core Organizers” of the movement. The presentation will look at some of the taxonomies that have been used to describe DevOps such as CAMS and ICE. It will also cover the recent 2015 Devops Survey and we will end up with a discussion about how DevOps is being adopted in the enterprise.

Though the event waitlist is already packed, you can still try to visit our office – only if it becomes too crowded, we’ll have to give the Docker Berlin members priority. The event starts at 6:45pm, all details can be found on the Docker Berlin event page.

Introducing Feature Coordinators

Our company bootstrapped from one developer (me) into a team of 12 developers. The transition was not always easy: More people means more dev power, but also more communication and alignment needs.

When we reached a team size of 10 in July, we decided to split them team into 3 fairly independent subteams. Last month was the time to get a more serious about managing those teams’ deliverables. We introduced a rotating role called “Feature Coordinator”. In short it’s a rotating form of project management – but it’s also a bit more than that!

Continue reading

Hackathon3: iCal Integration

We conducted our 3rd SI Hackathon on Feb 19th to Feb 20th. This is one of the hackathon results.

Background

My previous Hackathon project was way too ambitious, so I decided to pick something easier this time, which would also help reduce our support load a bit. A frequent pain point is that client admins set up a review timeline, start the process, but then forget about the timeline and get taken by surprise when an important date passes, like the “editing lockdown”-date or the “360 feedback gets released”-date

There are several ways to improve visibility of scheduled dates and events, and we’re approaching this from multiple angles already, working on a visual roadmap for the dashboard and reminder notes within the application too.

But if a SI admin forgets to look into SI altogether, then those won’t help.

Continue reading

Adventures in VC land: Our 2013 pitch deck

Dozens of VC firms reached out to us in 2013, so we sent our pitch deck around the world quite frequently. After a while we started sharing our deck with job applicants as well: We’re such a small startup, and many applicants had doubts about joining us. Access to our deck and our key metrics definitely helped with recruiting.

But we still insisted on confidentiality. Only when I was interviewed by Gruenderszene recently, it finally dawned on me that being secretive is actually quite stupid. There’s no real downside in sharing our numbers more broadly, except maybe for the additional recruiter calls we’ll get. But if just one additional good applicant throws her hat in the ring, that’s worth it. So here we go!

Our Pitch Deck

Continue reading