More Code, Fewer Pixels

Ruby on Ales 2014

Cameron Daigle

#frontend-development

#design-thinking

More Code, Fewer Pixels

by Cameron Daigle

The video titled "More Code, Fewer Pixels" features Cameron Daigle presenting at Ruby on Ales 2014. In his talk, Daigle discusses innovative approaches to transitioning design concepts into functional code, emphasizing the need for a shift away from traditional design processes that rely heavily on static mock-ups. He highlights the importance of developing tools and methodologies that support an agile feedback loop, enabling quicker iterations and collaboration between designers and developers. Key points from the talk include:

Transitioning Design to Code: Daigle explains how Hashrocket moves away from the conventional waterfall model and towards a more iterative process, utilizing rapid prototyping to gather user feedback early.
Challenges with Client Interactions: He shares experiences of working with clients who often complicate the feedback process due to multiple layers of decision-making authority, affecting the agility of prototyping efforts.
UX Responsibility: User Experience (UX) is emphasized as a collective responsibility across the development team, fostering collaboration from requirement gathering to wireframing.
Collaborative Workflow: Improved efficiency comes from integrated workflows where designers and developers collaborate closely, allowing for better communication and clearer interpretations of client needs.
Tools Developed: Daigle introduces tools like the UI directory for maintaining design consistency and Phil for generating simulated data, which both streamline communication and reduce reliance on static designs.
Conclusion: The key message stresses the importance of evolving design and development processes to enhance collaboration, agility, and clarity, ensuring that software projects can adapt quickly to changes and user feedback.

Through these innovative strategies and tools, the aim is to create a more effective working environment that bridges the gap between design and development, leading to better outcomes in software products.

00:00:17.039 Camera, you're going to talk about more code and fewer pixels. I think this is great, except that I recently bought a 4K monitor. So, how am I supposed to program with fewer pixels? How do you read anything?

00:00:36.960 All right, yes, thank you, and welcome. My name is Cameron Daigle, and I'm a designer at Hashrocket. Here at Hashrocket, designers also write a fair amount of front-end code and a handful of JavaScript. This talk is about my experiences over the years at Hashrocket and prior, specifically focusing on what we've developed to facilitate moving an idea from pixels to code.

00:01:07.680 What we've developed are various tools to help keep changes out of pixels and away from the mock-up world, focusing instead on the actual code in the repository. Before diving deeper, I want to share how scary it was to get here. I had to fly in from Portland after flying to Dallas or Denver, and before that, I was flying from Jacksonville, Florida. This was the smallest plane I've ever been on, and I didn't like that at all; the little yellow circle on the map is me, the scared one.

00:01:44.800 Now, I want to talk about how things generally transition from pixels to code in our industry compared to how it happens at Hashrocket. Generally speaking, user-centered design is where we are in the industry right now, which has evolved from an older waterfall style process. According to Thomas Peterson, there is a typical analysis phase where requirements are discussed, followed by considerations for UI and UX along with information architecture. After forming the design visually, we then implement and deploy.

00:02:21.280 This outlined process, refined by revised cycles, follows through all phases: analysis, UI, UX, and implementation, with deployment happening as soon as something is functional. This approach, known as rapid prototyping, emphasizes getting something operational before complete design implementation, allowing feedback from users sooner in the process. However, my experience at Hashrocket shows that this structure does not always work effectively for us.

00:03:44.720 In consultancy or product shop environments, there is generally a chain of authority that involves multiple stakeholders, which complicates direct user feedback. I often design for clients who need to then show the work to someone else. It's rare that I find myself in a situation where my client is the final decision maker. In an ideal world, I would communicate directly with the individual making those decisions, but the reality is often more convoluted.

00:04:42.720 I strive for a rapid prototyping environment where I can deploy something to a server, have users interact with it, and learn from their feedback immediately. However, in practice, there is usually a client in the way who also has their customers to appease. Thus, when we work on a B2B application, we find ourselves navigating through many layers of authority and expectations that hinder our ability to prototype effectively.

00:05:54.560 This leads us to prioritize presenting polished initial prototypes that clients can confidently share without disclaimers about them being mere mock-ups. Clients rarely grasp partial design concepts; if I ask them to focus solely on a specific section of a mock-up, they might become distracted by elements I deemed incomplete. I often face feedback that reflects that distraction.

00:07:04.479 To illustrate this point, consider a hypothetical scenario: if a company manufactures hammers, should they only show it on paper, have clients hold a cut-out paper hammer, or produce a prototype for testing? Clearly, the answer is to provide the actual hammer for trial, as it's essential for showcasing true functionality. Conversely, in software development, focused solely on creating a minimal viable product can lead to disappointment when the end product doesn't meet aesthetic expectations, leading to questions like, 'Why doesn't this look as I envisioned?'. It is essential that the product both functions well and looks as expected.

00:08:27.679 Another key point I want to emphasize is that user experience (UX) doesn't end at deployment. UX is everyone's responsibility in the development process. For smaller teams without a dedicated UX designer, collaboration becomes vital. At Hashrocket, our process incorporates gathering requirements and wireframing—all exercises in collaboration—and when we sketch ideas, we generate story cards that break down features into manageable chunks.

00:09:16.159 We proceed to a phase called 'weapon fuel,' where designers create mock-ups using either new branding or existing designs that resonate with the client. This collaborative workflow allows us to efficiently implement and deploy projects, enabling a cyclical process to refine further as needed. When requirements shift, our response spans the entire process back to user experience considerations, impacting layout or design.

00:09:45.040 We prioritize communication and usability during every step to ensure what we deliver aligns with the client's expectations. Whether it’s detailed wireframes or interactive prototypes, we strive to create deliverables that allow clients to visualize the product effectively, bridging the gap between concept and reality.

00:10:57.120 The evolving relationship between designers and developers must be geared toward reducing handoff issues, resulting in better-designed products and fewer unnecessary changes.

00:11:17.400 When I joined Hashrocket in 2010, our processes were not as integrated, causing disconnection. Designers operating separately from developers created confusion and misinterpretation. This conventional approach hindered our overall workflow, making it challenging to share design intent with developers.

00:11:45.079 Now, however, our workflow emphasizes collaborative sessions where designers and developers work as a unified team during the wireframing sessions. This approach has drastically improved our efficiency and project outcomes. The same designer remains involved throughout the project, maintaining continuity.

00:12:17.675 With this procedural change, designers help interpret client requirements into initial sketches, which simplifies the sign-off process and enhances clarity. This way, designers not only handle visual layouts but also produce much of the front-end code, fostering cross-functional skills within the team.

00:12:59.039 As we improve our process, we focus on improving communication to reduce ambiguity at the handoff stage. Each process phase involves tangible deliverables, which are critical for seamless transitions and maximizing understanding among team members. Different roles can be essential, so we ensure the right contributors actively participate at each level.

00:13:49.600 As projects progress, adjustments are integrated, and both designers and developers collaboratively review the work in progress. Development then only follows upon mutual team consent of the finalized design mock-up.

00:14:37.440 At Hashrocket, we have developed tools that facilitate effective handoffs and bridge communication gaps between designers and developers. We have refined tools to ensure both designers and developers can stay informed about project changes and updates without redundancy.

00:15:25.440 One key tool we use is called the UI directory, which helps to keep the designers and developers on the same page. Designers can reference the directory to grasp the overall layout as development progresses and maintain consistency.

00:16:02.159 We also utilize another library called Phil, which allows us to simulate real data without confusion. Phil wraps around Faker, producing usable random data that enhances testing and development without cluttering our repositories.

00:16:59.639 Furthermore, we developed Stagehand to help us simulate various UI states. This tool permits designers to toggle aspects of the UI without direct interaction, enabling them to visualize functional changes and critique UI without modifying the actual application.

00:18:10.799 The main purpose of these tools is to keep our teams efficient and flowing with their best ideas without reverting back to static PSDs for every change. The methodologies we aim to establish are focused on efficient handoffs and clear communication throughout our workflows.

00:19:06.639 In conclusion, every tool allows us to maintain agility, lessen confusion, and foster collaboration among team members. It's crucial to understand how the tools fit into your unique workflow and ensure they support your process, rather than dictate how you work.

00:19:52.639 As we refine our approaches to software development, we must choose tools that facilitate our goals of clarity, quick pivots, and efficient communication. Delivering a product involves understanding your expertise and allowing flexibility while facilitating effective teamwork.

Ruby on Ales 2014