A question I often get asked when speaking with colleagues and peers is “how does design work at RightScale”? This normally leads to a lofty chat about process, inspiration and team structure (there’s generally a pint in there somewhere too). So I thought I’d take a little bit of time and write an overview of this in the hopes that someone will at least find it interesting enough to tell me I’m completely wrong.
Where to start?
So, who are you?
I’m Chris, and for the last year and a half I’ve been professionally colouring in for RightScale out of our Edinburgh office. My work generally centres around the Cloud Analytics application. For those not in the know (shame on you), it helps large-scale enterprise customers understand what they’re using and spending on their cloud-based infrastructure.
Phew… Now that’s out of the way, let’s get down to the nitty gritty.
Our process
As a unicorn product designer type person (sarcasm intended, I’m British after all) my two week sprint can be roughly split into three categories:
-
Bugs: We all hate em’, but you have to deal with them.
-
Technical debt: Sometimes things just need a good ole’ clean.
-
New features: The meat and potatoes of design.
Now the first two can be quite easily summarised. We as a team like to make sure that not only are we placing focus on new features that users interact with, but also that we don’t neglect our existing cruft - this is crucial. Clean home, clean mind. We make sure there’s always a bug and tech debt budget each sprint - it helps us ensure we’re taking the appropriate time for these tasks. As with anything though these budgets shift based on requirements.
New features often require the involvement of various people. A term I often like to throw at the team is that “everyone is a designer”. When I say that, I mean everyone plays an essential part in solving a problem and the road to a solution. Design is bigger than pixels and colours - it’s how a user interacts and completes a task and that requires a complete understanding of a problem, too much for a designer alone.
We like to kick off new features with a meeting including the product manager, engineers and designers - this will often happen months before we intend to implement but it gives people a heads up and basic understanding of the feature itself and to field any questions or suggestions. When ready we schedule the feature into a sprint.
When initially trying to work through an idea sketching really works for me. People often evangelise digital wireframing tools such as Balsamiq, but sat in front of a computer screen I’m often subconsciously thinking about technical limitations and more often than not, my own personal ability to implement what I’m working on. Sketching frees me from that. I use pen and paper as a mind dump - I sketch whatever I’m thinking before I have the time to overthink it. As you might have guessed, some of the results are interesting. But that doesn’t mean they’re any less valuable as an personal exploration. If you don’t already, I’d recommend giving it a go.
After this we tend to spend some time hashing out what’s technically feasible as a first pass. This part is important folks, don’t feel deflated when you’re told your multi dimensional graph that reacts to a user’s emotional state might have to be scaled back. It’s a designer’s job to think of the best possible solution, it’s a great designer’s job to realise how to then adapt that with engineers into a shippable feature. Of course this doesn’t mean the feature can’t be revisited later on or that the work you’ve done is applicable elsewhere.
With deliverables set we’ll sometimes start by building a quick functional prototype that we can use to validate concepts. This is pivotal, especially with more complicated or involved features. This usually involves a designer and dev locking themselves in a room for a predetermined amount of time - normally with a hug and high five at the end.
Concept agreed? everyone happy? Great. Time to build and ship.
Now the important thing to remember here is there should never any kind of hand off culture. We’ve managed to develop a culture where both designers and developers rely on each other organically, everyone knows each other’s strengths and weaknesses and works around that. This can manifest itself in multiple ways from deeply involved, where both designers and developers are hacking away at a branch, to simple pairing tasks throughout to ensure a feature is up to scratch and as anticipated.
Iterate
Just because we’ve shipped a feature doesn’t mean it’s finished. We strive to see how we can do better. Deeply analyse how users are reacting to features and how we can improve. This is an ongoing process and one of the most rewarding part of working on a product.
Staying sharp
Consider this a little brucie bonus.
Staying up to date and exploring outwith your comfort zone is an important part of being a designer. At RightScale we employ what we call iTime (Innovation Time). This is loosely based on Google’s 20% whereby each second Friday of the month we’re allowed the day to work on whatever we like. Currently I’m spending this time working on a conceptual mobile application. This exploration forces us to try new things that might not end up on our roadmap for a long time and affords us the flexibility to just tinker. We’ll often see the things we learn make it into the product showing just how valuable it can be.
Join us
If what you’ve read above tickles your fancy we’re currently looking for people to join our team. Apply online now or get in touch if you’d like to know more.