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.
