At this moment in time, I would say that one of our largest endeavors over the past few months has been our ongoing adaptation of our design & development process to fit with the rapidly growing rate of hi-tech and mobile products. I am specifically referring to our internalization of the “product design sprint”. This sort of design thinking method of execution is certainly not new to humanity, but perhaps new to the recently formed and ever-expanding internet of things. Influenced by methodologies employed by Google Ventures, IDEO, and the Institute of Design at Stanford, our process here atCitrrus continues to morph as we come across new research and different problems to solve.
Embodying the journey It’s about the ergonomics. The user and their needs. There will always be uncertainty around the creation of a product. During it’s formation and throughout much of it’s existence there will be inevitable errors and malfunctions. But this is not the crux of the matter. The problems are not the focal point, the people are. To best prepare for and/or fix inevitable errors, malfunctions, and failures we have to understand the people using the product. Basing a product off assumptions will ultimately prove to be fatal because assumptions do not not thrive on feedback and continuous discovery.
Forced to “get over it!”
Our product design sprint is a very speedy and efficient way to get solutions on the table and products out to be tested. In order to make deadlines, deliverables, and gain results we have to simplify. To take a few steps back and look at the big picture. To give ourselves perspective and design hoilstically. We have to get over the pixel-perfection, the "features, features, features!", potential monetization, and the fear of failure.
It’s about the product of best fit - for the user
Problems don’t exist without a person (or user) to experience them (user need), and solutions are not real solutions if they are not exposed to the problem in need of one. And in order to assess the value of a solution, you need meaningful events and reactions to that solution (user validation). The earlier on in creation and development that prototypes are tested and products are used, the more opportunity we have to iterate on usability and asses the product’s value or impact. Once we’ve assessed the value, we can scale.
We utilize these quick sprints to gather gather a comprehensive knowledge of the problem via creative and analytic techniques (branding exercise worksheet, timed divergent thinking/sketching). We can then rapidly identify a minimum viable product (MVP), draw up a whiteboard full of potential solution(s), and push out utterly imperfect prototypes.
We’re learning about ourselves
A few key adjectives that describe our process would be: free, dynamic, multilateral, open-ended, natural, collaborative, adaptable, speedy, inspirational, creative, wild, and challenging.
What I really love most about our product design sprint is that it’s marked by large collaborative efforts from the entire team and the Client. In order to address the feasibility, viability, and usability of (sometimes outlandish) solutions, you really need all the brains on the board. From day one, we gather a bit of perspective from the front-end and back-end development side of things, product, ux, and creative. Everyone has something to add, we all have strengths outside of our titled role. Working with a fun, sometimes crazy, goal-oriented and optimistic team with a strong penchant for delivery really gets the project going at full speed. Efficient collaboration and timely execution are skills that really just take patience and experience to master.
Rooted in psychology
We believe in Behavior Driven Design & Development (BDD). BDD is human centered design with a backbone philosophy of ‘lean’ design thinking. Lean design is often marked by massive amounts of communication, collaboration, iteration, and feedback.
The big-picture goal of BDD is to expose vulnerability early on and often. In other words, we want to avoid long-term error by detecting and assessing problems as they are presented. With our product design sprints we are able to quickly conduct focused iterative testing and risk assessment. Exposing vulnerabilities can surely be emotionally difficult, but doing so early on in a product’s lifecycle greatly ensures future success.
Nix the docs
One of the most important things we always need to remember when sprinting is to focus. Speculation and documentation take too much time. This is a hands-on, highly interactive group activity that deals only slightly with individually created deliverables. We have to work together and trust everyone on the team to execute on time. We need to remind each other to be nimble, agile, communicative, and avoid over-analysis.
No matter how, wacky, unbelievable, or technically difficult the proposed solutions are, we get them out and we get results.
Note: If you were wondering, we do deliver documents. But the papers are not the focus nor the end all be all. They simply provide the means to capture the more important actions that take place.
As a designer, it’s like a breath of fresh air to step on the other side of things for a second. It’s just too easy to get wrapped up in what you do from only one perspective. Needless to say, I needed a break from user-related things and colors and stuff so I looked more into Jekyll the other night. It looks like a super cool, "lean" way to manage and completely control a minimalistic blog site.
I absolutely love how simple it is to efficiently create content in markdown and commit to publish. I prefer this way of creating and editing content over having to go through an entire user-facing wyziwyg. So, after some research I found Prose.io and completely fell in love — its a clean and fast way to create and edit your site docs in browser. Coming from a UX designer, the UI is damn good for a “developer’s tool”.
Trying to wrap my head around Jekyll and it’s components has not been easy though. It’s forced me to learn how to use the command line, install Ruby, and RubyGems — which was all pretty cool because my knowledge of coding consists only of self-taught objective oriented basics, html, and css.
I was able to set up Jekyll and stand up a horrendous/broken site in about 3 hours (hah) - I’m positive that the code is a complete mess but I’ll get to that later. Have a look and a giggle if you’d like http://ericajaclynstein.github.io/
Here are some resources that have really helped me to learn this thing: