InRhythm

Your partners in accelerated digital transformation

education

Building Relationships – Core Values as Corporate Culture

One of InRhythm’s core values is to “Build Positive & Trusting Relationships”. What better way to build strong connections between our employees than by bringing everyone together for a Meetup? On a warm Wednesday night we gathered our operations, UX, and development teams for a night of prototyping. The highlight had to have been watching the developers sit down with markers and paper to try to sketch out layouts. Each team came away with a new level of appreciation for the other and maybe next time we will get our designers writing some code.

Our awesome UX team taught the fundamentals of design and why prototypes are important on the job. Instead of starting a huge build on day one and stumbling through design pain points and changes, creating a workable mockup helps us understand our product at an earlier stage and get meaningful feedback from clients. We are no longer putting all of our energy into building something before we completely understand how it is going to behave.

We began the Meetup with marker and paper sketches and moved on to basic Sketch mockups. In many cases, like mine, we simply click and dragged basic shapes across the screen and pretended that it looked just like the demo version. We then had a quick demo of the incredible powers of creating interactive, clickable design through InVision. Watching a live demo of a prototype through the InVision mobile app was pretty mind-blowing as I had only ever experienced working with static designs previously.

Having the chance bring everyone together at InRhythm was fantastic and our Design team really knocked it out of the park. Come and see for yourself, our Meetups are now open to the public – looking forward to seeing you at the next one!

Written by Ricki Steiner

How Prototyping is Essential for Building Successful Products – a Meetup Sneak Peek

Before any final product goes live, there are countless sketches, whiteboard scribbles, test plans, and prototypes to guide us forward. We, as end users, don’t always see them, but those rough squiggles and drafts are invaluable even though they never see the light of day. Prototypes are an early version of a product, and as a drafting tool they are an increasingly essential part of any multidisciplinary team’s methodology. They’ve had a long history outside of the digital world, but for any digital product team their benefits are rich and varied. Teams can gain approval earlier in the process of building, determine and solidify design direction, understand and evaluate technical approaches and solidify content from one tool before any code is written. Agile promotes getting out of the office and in front of the customers – in order to validate that what we are building is valuable to them. Prototypes are one of the best tools in a team’s toolbox to help build enjoyable, functional and delightful products quickly, without confusion and with lower costs and time.

The UX team at InRhythm have been veterans of the various Prototyping Wars over the years. We’ve seen prototyping go through intense debate – what fidelity and software, when to build them, what to make interactive, what code we can leverage afterwards, and how to encourage them in the first place. Like many in current UX and Product Design circles, we’re enthusiastic, passionate cheerleaders not only for the value of prototyping, but in particular for the killer Tag Team of modern prototyping software, Sketch and Invision. To say they are game changers and life savers is not hubris – they are a revelation. We’re excited to be able to share what we’ve learned about the world of prototyping in more depth in our upcoming Meetup, and walk through how these tools make everyone’s lives easier no matter if you’re a product owner, designer, developer, stakeholder, other team member or end user.

There is a role in modern software development for moving towards code based prototypes using Bootstrap, Angular and other frameworks – perhaps we’ll all be prototyping in Framer one day. There should always be room in the family for the high fidelity, interactive ‘click through’ prototypes that Sketch and Invision create. When it comes to mobile, Invision and other tools like Pixate can create experiences so close to native code that you’d be hard pressed to tell the difference. No matter what fidelity or tool, getting a prototype in front of stakeholders allows for approval and testing with real users without needing the final, polished, finished, and tested product code, which can be expensive to retroactively go back and fix. Our UX team has worked with developers to build out the prototypes we’ve designed and developed, and can share how a mature approach to prototyping benefits everyone on the team.

When prototyping a flow of screens, the time to develop multiple screens or multiple design options can be easily done by a designer rather than a development team. Prototyping the right thing means giving more time back to the development team to focus on solving the important technical challenges rather than prototyping the obvious things that don’t need validation, or building out multiple screens and multiple flows. By using Sketch’s branding related features like ‘Copy CSS’ and Invisions ‘Dev Notes’ commenting tool, developers will get the instructions they need to pick up the pace after a prototype is validated. There is a source of coolness for our devs – by hiding notations layers or multiple pages via a simple ‘-‘ to a file name in Sketch. We can quickly go from ‘rough concept’ to ‘selected design’ to ‘prototype’ to ‘final design with notes to help devs’ all within the same document, rather than sending a never-ending stream of PDFs. With Invision Sync, working with these two tools becomes seamless and automated. Like a great product, you don’t have to think about it – it just works. Development has become a beautiful craft because we build upon the work of previous products – with modern UX prototyping software, building continues easily, scalably and without pain and heartache. The days of slicing .gifs, version control panic and PSDs with sad titles like ‘final_approved_last_change_USETHISONE.psd’ are dead – and it’s about time.

Since this is an InRhythmU Meetup, you can expect a little theory but also practice – we’ve created a number of exercises so you can get hands-on with the tools. We hope to provide you with a chance to ask practical questions on how prototyping works, how to make it as useful as possible for both you and your team, and how our experiences with clients has helped evolve prototyping to meet their needs. We’ll walk you through both Sketch and Invision, and spend time on how they work together. We look forward to an action packed session, so bring your open mind, laptop, thirst for learning and curiosity to create. It will be a ‘pull up your sleeves and have a good time learning’ kind of night.

Written by InRhythm UX Team

A Sneak Peek of InRhythm’s NYC Meetup on Node.js

On July 15th the crowd gathered at IRHQ for a Meetup on Node.js. Our senior NY consultant guided everyone through an exercise using Node and then we transitioned to hands-on coding. During the workshop we built an SMS-driven customer service tool using PM2, Gulp, React, WebSockets, ES6 Map, LevelDB, Deploying to Heroku, BrowserSync, Twilio(SMS), and more. We gained a good sense of how to build realtime apps with Node.js, set up a live/responsive build process, and deploy to virtual servers for prototyping. There was a lot of discussion surrounding how Node can be applied to solve business problems. The night was a success and we are excited for many more Meetups to come! Take a look!

Oh What a Night – Node.js Meetup Recap

Last week our Engineers gathered together for an instruction on Node.js with Sandro Pasquali, author of Mastering Node.js. It was a great night filled with study, hands-on coding and creative exploration. All our participants walked away having built a customer service platform upon an SMS messaging layer; a full application in about 120 minutes. Beyond Node, we made use of websockets, Gulp, React, ES6 and more. We’re excited for our next Meetup which will be focused within the UX arena. See you all there!

 

Who runs the world? Code, Code: What Development Can Teach Us About Creativity and Being Prepared for the Future

I recently read a LinkedIn post by Dan Robinson on the negative effects of social media and sharing designs and it has caused me to wonder if designers can learn more from developers than the value of coding as a skill. Maybe us designers can learn a little something about what it means to have a strong community to draw inspiration from. In his post, Robinson explores issues of self esteem and what inspiration, if any, designers can and should take from others. He highlights a common concern that we may be ‘comparing ourselves to death’ not only as individual human beings with social media and how we compare to others, but also as UX and visual designers because of constant exposure to what others are doing. Harold Bloom was an early analyst of the role of influence and peers on creativity, including his 1973 work called ‘The Anxiety of Influence’, and how the issues of feeling confident in designs will always plague designers, who often are self reflexive in their outlook to begin with.

Being a designer isn’t just about finding solutions – it’s about critiquing a state to improve it for the future, and as a result, criticism is often the default for many of us. Social media, and communities of practice, have value in learning the craft of design, and designer communities like Behance andDribbble help as a place to explore and share concepts and drafts. But, there is a downside to all of this sharing – Dribbble’s concept of a ‘shot’ often leads to designs which only look beautiful in a small, 400×300 pixels canvas. Good designers can become wracked with self consciousness if their design doesn’t look anywhere near as perfect as a final product on Dribbble. Ironically enough, the less glamorous design could be the right solution for a client and their customers even if it doesn’t win any design awards for Best Use of Flat Design on Buttons, or get voted up as noteworthy.  When we do see the perfect final version, we don’t get a feel for all the struggles which occurred behind the scenes. We don’t see the designs which were thrown out, and more disturbingly, few requirements or constraints (business or technical) are stated in a case study that accompanies that final image. Often there’s no case study at all – just an image, and people may see these final designs as solutions worth emulating. When designing more complex, enterprise transactional applications, is a simple, elegant, stylized shot found on Dribbble really the best source of inspiration? Should redesigns that focus on polish and the continual sharing of final products really be leading designers to late night bouts of existential anxiety?

How do other creative professions in technology – particularly, developers – deal with anxiety from creativity and comparing their work to others? What can designers learn from developers on how to feel confident with the sharing of their work? From the outside, developer communities appear to be less anxious and ultimately better prepared for the changes of being a professional knowledge worker due to a number of key practices about creativity which have developed as accepted standards. It’s not that designers and other professions don’t have the equivalent practices, but there may be a focus more on processes and practices in the building, and comfort in the ‘draft’ state rather than a focus on a final, finished, polished product. Some of the best developer practices when it comes to creativity include (in no particular order):

  • Pair programming as a practice: A core part of Agile development is developers pairing together to solve a problem. It’s not always a more experienced dev with a beginner – there’s an active sense of people who can be equally experienced working together through the best way to code. You can have two developers well versed in Ruby, who differ in how they construct code. There are often multiple ways to frame any solution, with no clear obvious direction. With pairing, you work through the options, put together multiple minds and find that best solution as you evaluate the options in real time. I’ve paired with designers before, and there is an active movement towards Pair Design as an initiative, but as a rule, it’s rare as an established, encouraged practice. There’s no reason why it should be, especially if multiple designers are working at the same company to help achieve consistent brand standards across products with multiple UIs. Smart companies have an active internal designer community, but in the education of designers, we rarely talk about pairing with individual designers as a practice – it’s usually one designer, and one product. Having an extra mind and set of eyes can help you see things that were missed the first time. I’ve worked with developers who sit with each other – different pairs on different days, and it’s what works for many of them.  Contrast that with the cliche of the Genius Designer silently sitting in the corner working away in his black beret. Perhaps pair designing might bring some of those solitary folks out of their shell and they will recognize the value of learning by collaboration. Maybe this will diminish the Genius Designer myth, too.
  • Communities of practice expressed in products, not just discussion: Developers have code repositories where hacking, experimentation and continual iteration are welcomed in addition to the usual forums for communication. Their tools are built out, languages created, and snippets shared on GitHub or other sites where the purpose is about sharing as much as an active finished product. Granted, it’s easier to share a code snippet than the outputs of a design especially concerning NDAs, and again, designers actively work to share their equivalent tool libraries, templates and pattern language libraries. With developers there’s a narrative that is unconsciously spoken – if you don’t like something and want to fix it, then just fork it, and make it your own. Customize it, hack it, tweak it, build it. We’re starting to see that with designers and developers building third party tools to work with Sketch and other applications, effectively building an ecosystem around the act of creating.  The sheer volume of activity on Github alone indicates that developers have beat designers to the punch, embracing the ‘building is part of being a community’ mission. Creativity for developers is building – constantly, and encouraging others to build off what they’ve done. Any hackathon is an expression of creativity and it can be astounding to watch that creativity happen. When we say ‘creative’, how often do we default to a painting, novel or dance performance? Perhaps we can see hackathons as another kind of performance where the code and collaboration are a dance that can be just as beautiful to watch.
  • Constant evolution of languages: This is a touchy subject, as the amount of coding languages and frameworks is exploding, and at a certain point there may be too many of them for any one developer to keep up with. Still, the amount of active development of new languages demonstrates how developers are constantly pushing the boundaries of what they can do with code, and exploring new ways to do it. Everything we once could do in Flash and Flex is now being replicated with CSS3. Our languages will continue to multiply as our interactive experiences online evolve, and as the devices and ways to experience a product continue to proliferate. As a career in development, it can be exhausting to constantly learn new languages, but as a form of art and creation, it shows people creating. Photoshop was a standard for so many years, and designers are only now in the last couple of years successfully evolving their languages and tools to meet the needs of these more complex and sophisticated products.  In creating new languages, the practice is less about comparing yourself to others’ output than creating something new for the sake of trying to solve a problem.
  • A commitment to continuous learning: As more languages, tools, and standards evolve in how we build products, the only constant in responding to change is adaptation and a commitment to learning. Continuous integration isn’t just about checking in your code – it’s about how we learn and keep learning, keeping our eyes open for what to learn, building upon your existing knowledge and seeing where the past and present apply to the future. Everyone – designers, developers, product, sales and more – has to commit to constant openness to learning and evolving one’s skills. But with development, that learning is embraced at a hyper accelerated rate. You may not need to be an expert in everything, but you need to have an awareness of what matters in technology, and for some concepts, at least a recognition that you have a gap which learning can address, and if you need to know about something quickly, the best source of learning is to start mastering it. Thanks to the always-in-flux nature of Web and development languages and practices, you always have to be actively learning – and there’s a potential for developers to be doing so online quickly.  It’s no surprise that there are more varied ways of learning development and computer science outside of traditional education – the rise of online education points to evolving how we learn, and that evolution speaks to how development addresses creativity, too. No surprise – the rise of the Maker movement has a strong tech focus at its core, and the message of the movement is a positive one. Anyone can be a Maker no matter their education or skills, as long as they’re willing to try creating.

No matter what the medium, creative people will always be strivers, dreamers, the people who crave more, who ask why – and often why not. No matter what the medium (paper and pen, keyboard, paintbrush, or whatever comes next in the future) striving is one of the passions which drives us to improve our craft and seek out new ways to design or develop the products and services that change lives.  The trick for creativity is to remember it’s not a race to compete with the Jones’s and the Dribbbles – it’s to start embracing your inner creative spirit and hacking for the sake of hacking.