Category Archives: Leadership

Choosing to Live Deliberately

Recently, I’ve been given the opportunity to “live deliberately”. My friend Matt wrote a great post about his choice to relocate his business to Charleston and how he has found a tech community choosing to “live deliberately”. This idea has been on my mind and it’s finally time to do something about it.

Realizing & focusing on what motivates me: Good people and good projects are why I get up early in the morning.

This month marks my 4th year with SPARC. Helping grow a company and building a design team has been tremendous rewarding. Theres always a struggle between being both a leader and a designer, not one I’m always comfortable with. This experience has returned  tremendously to me, both personally and professionally. Sometimes you need to realize when the experience has stopped returning.

Several months ago, my amazingly thoughtful wife and I made a deliberate choice to move and raise our son at the beach. The new house is amazing and gives me a sense of quiet satisfaction every day. I also turn 40 tomorrow – some mindless mid-point in my life that means I’m in a different marketing demographic.

More and more, I’m taking pause to think about the what and the why. Taking time to go surf, live healthy(er), enjoy our new home and a sense of change. Versus feeling like I’m treading water and out of balance.

And focus. Focus on what type of work I should be doing versus what’s put in front of me. There have become far too few good projects and far too much busy work in-between. Work is always strenuous and not always “fun” – that’s it’s nature and accepted. But good people and good projects are why I get up early in the morning. There’s a way to be both a leader, and a doer, and make an impact in peoples lives.

Life’s short, and there are a lot of distractions. I’m taking the remainder of this year to find those good people, those good projects, and focus on living deliberately.

Agile Design for 18F Development Challenge

18F is an government contracting agency that acts more like a tech start-up than a traditional government agency.  They introduced a short timeline, design & development challenge around the OpenFDA API to vet future development partners. We used the challenge to demonstrate our ability to design and develop a viable software product with a small, experienced team in an extremely short timeframe. My role as design lead was to assess the OpenFDA and design the most impactful product we could create with a small, agile team in a short timeframe.

Quick decisions

When the development challenge was released, 18F gave no specification of “what” type of product they’d like to see except that it should leverage the OpenFDA APIs and US Digital Services Playbook. An open concept played to our strengths: our design team has helped 50+ entrepreneurs visualize their product concepts over the past 3 years.

Design studio approach: We start with a brainstorming sessions and broad set of concepts, then narrowed down the product functionality based on the technical feasibility of the API and impact and usefulness to the user. Our design team initially considered an app to track a list of commonly used food for a restaurant against the FDA’s published food recalls. Given further research, we pivoted the concept to drug safety as it’s impactful to a larger group of users and the FDA’s stated business goals of safety and openness.

Limiting Scope for a short timeline

So there were a lot of product ideas we COULD have done… including pulling half the company into the development of an idea.  Instead we scoped our initial concept to fit the effort level or a small dev team of 5 over a period of 3 days. The goal of the development prototype was to showcase our ability to rapidly design & build a product of value in a short timeframe.

Collaboration & Constant Communication

Photo by Chad Norman

We set up a war-room atmosphere. Sitting together encouraged collaboration and made communication easy. And since we all have real jobs to do at the same time, we implemented a basecamp project to keep everyone in the loop and get feedback from the team throughout the design process. My design process was tailored to match the rapid timeline:

User & Technical Research

  • Researching & definition around Business Goals
  • Technical research into OpenFDA API
  • Design Studio composed designers, developers and a scrum master to brainstorm and vet ideas based on business goals, technical feasibility, and usefulness to the User
  • User research
  • Refinement of initial concept

Rapid Prototyping

  • User flows & wireframes
  • User testing through clickable prototype in InVision
  • Feedback loop within Basecamp project
  • Rapid iterations of the wireframes based on feedback

Visual Refinement

Early Testing & Results

Early on, we have leveraged clickable static image prototypes to elicit feedback from people familiar and unfamiliar with the apps goals. This feedback helped to quickly test our assumptions, discover if the user experience was intuitive & simple, and iterate on the apps user flow/functionality.

In the first day of design we user tested 3 prototypes for feedback through a series of InVision clickable prototypes. Then iterate on design and functionality based on feedback.


Explaining the “why”

We could have published a very minimal app, but it wouldn’t be clear to the user why or how to use it. The marketing aspect of explaining “why” the app existed and how to use it are a big part of the overall user experience. This “about” statement required a surprising amount of iteration, but helped keep the app focused and reinforced it’s original goals.

The Med Pal application allows an informed consumer to research individual drugs for recent recalls or label changes through the OpenFDA API. Similar to subscribing for updates on social media, you may choose to “follow” a drug of interest and be alerted of changes when you revisit

According to FDA research, there are approximately 106,000 deaths per year attributed to adverse reactions to prescription drugs. One in five hospital visits are the result of a drug reaction. And adverse drug reactions are estimated to cost our country $135 Billion dollars a year.

Pivot our Mindset: “Twitter of Drugs”

Our original concept had been building a list of drugs you take, then revisiting it that list at a later time to see if something had changed. But the early prototypes proved building lists was a tedious user experience. Somewhere over a beer, it dawned on us that we’re simply “tracking” drugs of interest – in a social fashion, this is a lot like “following” a drug. You follow people on twitter and see their updates on an activity feed. Why couldn’t this be the same?

By mimicking the social media experience of “following”, we are able to make interacting with the app modern and familiar to the user.

Our finished v1 product published here:

med alerts search

And one more lap

The first iteration was on track to be published through GITHub when we discovered the challenge had been extended to allow more time for development. Being near the completion, we opted to publish and then treat the product backlog as a second release. This also allowed us time to pivot the original design and add new functionality of drug interactions.

Using the same techniques, we pivoted the product branding and layout. This streamlined the app even further. The new layout eliminated the need for a modal window, which had been a usability issue in the first release.

The v2 prototype is published here:

medpal drug view


This is a great example of how quickly a experienced, collaborative design & development team can evolve a software product from concept to release.

Agile Design: Crafting a User Experience Collaboratively

The collaboration between a front-end developer and talented designer is how amazing user experiences get built and refined.


Our team does periodic design reviews here at SPARC to review design quality and discuss the design process – what’s working well and what can be changed. Lisa and Harrison are both extremely talented team members on different ends of the design spectrum. Lisa’s crafts beautiful UI & can take a client’s brand and make it sing. While Harrison is a front end guru who helps translate Lisa’s ideas into a User Experience. They’ve worked several commercial projects together and have arrived at a solid working relationship. I’ll often observe them standing at Harrison’s monitor tweaking code and going back and forth. This behavior got me thinking about a few elements of our Agile Design process at SPARC that deliver results.

Separation of concerns: Design and Development 

I refer to a great designer who can design and develop with equal quality as a unicorn – because they don’t exist. Everyone on our team designs and writes code to differing skill levels, but Lisa and Harrison balance each other through the fact each has a specific are they excel at. As a designer responsible for both design & delivering the final code, I’ve found myself limiting the design knowing later I’ll have to build it. Your mind naturally thinks ahead to how it will be coded and not completely about the experience. It’s hard to separate these concerns.

There’s a huge advantage as a designer understanding code, it helps participate in the execution and understand what’s possible. Just as a developer needs to be empathetic to design to understand “why” something needs to work a certain way. But we’ve found being able to separate responsibilities on a larger project allows this pair to excel their specific work and then collaborate on a better end product.

Iterating design in code

One real advantage we’ve found is the ability to iterate in code. Often times we’re only talking about design “concepts” until they’re actually in browser. Our workflow is to move through our design phase quickly into implementing code. When implementing, we discover opportunities, things we missed, and are able iterate. Those iterations then flow back into the visual design.

We try and caution clients not to get hung up on the early visual designs – treat them as concepts, not a complete user experience. Once coded into a prototype or dev environment, you start to understand how the user will experience the app – in browser.

User Experience workflow
  • Wireframes and Visual Design are concepts or explorations
  • Design Implementation speaks to actual User Experience
  • The ability to iterate in code allows us improve the overall User Experience
Most designers operate under a series of assumptions, that change throughout the course of a project. Getting use to iterating in code keeps us agile to these changing assumptions.
  • There are gaps between static designs and interactive code
  • Static designs can only translate user experience 80-90%
  • Optimizing code is cheaper than iterating visual designs

Keeping it Consistent: Pattern Libraries

pattern library

One of the biggest issues in a large app being developed by multiple people is keeping the look and feel, and the mark-up, consistent. This isn’t a new thought. Our front-end developers start from day 1 with adding a basic pattern library into the development environment of the app. This helps the developers find the correct code snippets, and our team style the app in a consistent manner.

We develop most things in Bootstrap – it offers a clean, organized library of components to use as a base. From there, we narrow it down to the elements we’re actively using (less is more) and have a page dedicated to displaying the styled examples.

And people get bored. After staring at something too long, most clients or designers get tired of it and want to make changes. Having a maintained pattern library makes visual updates easy and consistent.

Evolving our Agile Design Process

Collaboration. Separating concerns. Actively maintaining a pattern library in design and code. These are a few of the workflow habits that make our Agile Design process & team successful. Being able to be hands on with the code, in open collaboration between designers and developers, allows us to deliver a refined user experience to our customers.

User Experience: the barrier-to-entry for better healthcare software

As a design team, we have unknowingly become an expert in designing the user experience for healthcare software.

Intended or not, many of our  projects focus on some aspect of the healthcare space. Checklist apps for service providers. Back-office software to eliminate wait times and help veterans. Commercial software for a major healthcare providers patient records and business. Myself and many of our development team came from a company that creates healthcare enrollment software. We understand 835 forms and ICD-10 codes. We understand how to move a user through a 14 page form and make them not hate it… too much. Over the dozen related projects, we’ve accumulated domain knowledge in a space that’s complex and confusing.

And building this software varies greatly from our other projects. There’s never anything easy. Never. Nothing in healthcare is as simple as it sounds. And everyone’s business process is different.

We were reviewing one such project with the design team yesterday when it struck me:

User experience is the barrier to entry for effective healthcare software.

Not just software, the industry itself is overwhelmingly complex. And why? I can figure out my sons medical bills from a minor operation – 4 months later I received 4 additional bills from different providers with no context. And that’s one simple operation. Healthcare systems seems to revel in their complexity. How does any of this benefit the consumer or the user of the software? And how does continuing to design for this complexity help create a positive user experience?

IF the goal of “design” is to take something complex, understand it, and make it simple for the user  – are we doing this? Are we creating a positive user experience, or are we just adding one more layer to the cake.

So now that we’ve recognized the opportunity, where do we go with this thought? Focus back on the user experience. How can we improve their experience? How can we reduce complexity of a complex system? Make it smarter. Make it easier to navigate. Make the experience of completing a form more enjoyable. As designers how can we understand and remove these barriers to entry? How can we create a better healthcare experience through better software?

Always be creating value – Or my evolving role as design director in a start-up.

I have the best, and scariest, job in the world. When I’m doing my job right, everyone else is busy and I have nothing to do. And this isn’t to say there’s nothing to be done, I just haven’t discovered the next design project yet. My job is to insure everyone else is productive & happy, before I worry about myself. My job is to put my self out of a job. And then repeat that process over and over again.

As we approach the holiday season, there’s a lot of change in our office. Like physically: we’re moving furniture to accommodate another 60 friends. And we’re in the process of doing our annual reviews, which leads to a lot of introspection about your year. I could tell you 20 things my team has done successfully this year, but very few I’ve done. My conversation sounds a little like:

“We identified a design opportunity. I gathered the necessary requirements, set the creative direction for the project and delegated to Matt. I backed off & he went full bore and created some amazing logos … “

Did I create anything? Not really, I simply facilitated a member of the team doing amazing work. How much value did I add if I didn’t actually “produce” much of anything?

So my definition of “value” has been changing these past 3 years – from a one-man-band designer to leading a design team. It’s scary stuff as some days, I’m the first one I’d fire. But seriously, as a designer who’s done work-for-hire contractor positions before, you know you must always be creating value. Once you’ve finished the projects you were hired for, you’d find yourself sitting there waiting to be let go… “No more work, we’ll re-hire you in a few months when we need something.” It’s can be really scary shit to not have something tangible in front of you to constantly justify your perceived value. “I’m working on such and such project…”

And defining yourself too narrowly by your craft or what you produce falls into that trap as well.

The shift from execution to strategy leaves you wondering how much value you are creating?

And really, what is “strategy”? Strategy is simply any technique that leads to tangible results. Advertising agencies are based on their ability to convince clients on the value of their intangible strategy. There’s probably a distracting rant built into this line of thinking, but it’s exactly where I find myself. Packaging “intangibles” to generate tangible design results is now part of the value I create.

So what’s my next “project” look like? Last week was an office space redesign. Now that it’s underway, I’ve moved on looking for the next challenge.  Somewhat like captaining open water between the islands that are one project to the next. You can see it on the horizon, but not always sure how you’ll get there and what you’ll find when you do.

Nothing good gets designed in a day

Working quickly is a part of life. Juggling multiple projects & requests from within our company, we often have to respond quickly. And there are times speed is necessary over quality. As a designer you accept this, get your co-worker the graphic or presentation they needed, and move on thinking next time it’ll be “better”. It’s not a deep thought, but…

Nothing good ever gets designed in just one day.

That’s not to say some of my best work hasn’t been quickly. But for a designer, I think there is a point of digestion that needs to happen before you can really execute. It has to do with design thinking, or even divergent thinking when approaching an issue. The ability to understand a problem and then walk away for a while.

Our working environment can be chaotic – designers may juggle multiple long term design/dev projects, and in between get hit up to help support our growing corporate brand. A lot of time, the best value we can add is visually illustrating a complex development process for our business development team. Those graphics help our proposals shine above others and translate very complex concepts into something  that can be easily understood.  Seems simple, but we’ve invested hundreds of hours in our graphic library over the past 4 years.

First step is to simply listen & gather the requirements you’ll need. Finding the person and a whiteboard is one way. Another way could be simply to find the image assets you’ll need , start a new illustrator doc. This will take you 10 minutes, but this start lays the ground work for coming back at the design problem with a clear head .

How long do you pause? Could be a day, could just be a couple hours. The important part is actually taking a break. Because when you come back, I find myself both mentally prepared but also ready to enjoy solving the design problem. And when you think about it, why else do something unless you enjoy it?

As a designer, you need the ability to know your process and how to get best results.

creative processAnd that extends to your team – knowing how they works helps delegate projects and avoid poor quality responses during a fire drill.  Sometimes watching how they work tells you more about how you should be a leader. There are a dozen of us, all with different strengths and a different person. Lisa is one I can relate a lot to – she can crank out visual or UI design all day, and quickly. But when she’s spent time to digest the problem, and then iterated on it several times, the results truly get portfolio worthy.

Another designer Matt took home our graphic inventory over the weekend – something he’d contributed to before – and elevated the design pattern by rethinking it. Understanding, taking a break, and then coming back at the problem helped him elevate the  style we’ve been using going forward in our proposals.

Which brings me to my next moment of Starbucks introspection, what am I putting in a portfolio? And what work as a team are we proud enough of to keep? We have a pretty good throughput supporting multiple products, service teams and our corporate brand. Our process is loose, but achieves results. But what of those results would we share at our next job interview? Or online in behance?

And how much of that lack of quality comes down to the time constrains we work under?

Ok, too many deep thoughts getting broken up by the cackling old ladies of starbucks. But think about it next time someone does a “drive by” and requests a new graphic… it’s only going to take an hour to knock out. Or can it be something better to understand the problem, gather the requirements and give it a break before barreling headfirst into solving the problem visually? The best things I’ve ever designed we’re never done in a day.

Successful software starts with a Design Assessment

Lack of a cohesive product design is the quickest killer of a software project. If you have an idea, you need a design assessment before you ever write your first line of code. And here’s why.

0) What is a design assessment?

sparc SDLC 2

A design assessment is a 3-4 week pre-development process that gives perspective to an entrepreneur’s idea prior to building software.

This process focuses on understanding the goal/vision and working towards being able to show it through a prototype. Often an entire project is too detailed for this short of a timeframe, so we focus on key user-flows. Identify several key features users need, and work towards flushing those out.

A typical assessment can be as quick as 3 weeks with these key phases:

  • Discovery & Research
  • User Experience Design
  • Prototype & Deliver

A typical SPARC assessment team needs the following roles, with one person fulfilling several roles:

  • design strategist
  • user experience designer
  • visual designer
  • UI developer
  • requirements expert
  • project manager
  • software engineer as a technical consultant

One of our most successful assessments was for GWIG – Go Where I GO. GIWG is a product that allows a user to recommend a business to a friend. During the assessment, I filled the early roles of Strategy & UX, with our commercial services Director acting as PM & light requirements. Later into the assessment, we scaled the team with another designer, Matt Brooks, who invested in the idea and began taking the early user flows and adding visual design detail to them.

One simple strategy when working with a new client – keep the assessment fun & make the process painless for them. During GWIG, we added characters from the movie old school to the prototype. Having Gordon Pritchard tell the story was a lot more interesting than a John Doe. And as designers, a good sense of humor was a great motivator.

1) Tailor the results to the Client’s needs

We’ve done dozen’s of assessments this past year. Each assessment has a different goal the client is looking to achieve.

  • For a entrepreneur with an early stage idea looking to raise capital, we often deliver the assessment as a pitch deck for them.
  • For an established product looking to re-design, we deliver detailed requirements & design comps at the results.
  • For a client looking to go straight to development, we create a clickable prototype in HTML. By using production-ready front-end code, the prototype is also first step of development.

In each scenario, the results are tailored to match the clients needs.

2) No wasted effort

When we pitch clients a design assessment rather than jumping straight into building a product, we occasionally get some confusion of if this is an extra step.

One is “What, you don’t want all my money upfront?”

The second is “I don’t want to pay for an extra step, I want to start now.”

Our response is: you’d have to do this anyways. A design and requirements session is required before you can get started building software. It’s part of the process. The only difference with an assessment is we’re compartmentalizing these elements before jumping into a development cycle. It’s expensive to have a development team sitting around waiting for work, it’s even more expensive to have developers building the wrong thing.

With a design assessment, you’re only paying for the part of the process you need now. All of the work is transferable to the next phases of the project.

3) Design is the first step in visualizing your product

When Charlie from GIWG first approached us, he had a napkin sketch of a logo and an idea. He left a lot of room for us as designers to listen to his goal, and design the user experience around those goals. He also appreciated our take on simplicity in the UX. Once we moved past wireframes and began layering on elements of visual design, he was able to begin seeing his vision come to life. It’s incredible what a good collaboration of vision & design can produce.


4) Results you can take on the road

Most entrepreneurs test there idea by discussing with others. There are many components of a solid business plan, but being able to see the final product flushed out is the strongest litmus test. Nothing elicits feedback like being able to see yourself using the finished product.

5) Constantly test your idea and iterate

Design assessments are never meant to be the finished product. Through discussing with others, or living with the prototype for a short time, you’ll see it’s strengths and weaknesses. The design decisions you arrive at during the assessment are not meant to be final, so don’t treat them as such. They’re simply the first iteration – a first testable version of your product that you can learn from and improve upon.

In the 12+ assessments we’ve done, we’ve never gone straight to code with a finished design. We’ve continued to iterate & improve on the original design. It’s this cycle of learning & improving that creates a successful user experience & well designed product.

To Conclude

Using the design assessment process to visualize that idea brings the short-term results of being able to visualize the idea, build a relationship, and test that idea. And the long-term result is better quality software and an easier development process.

Insourcing & leading a creative team

We’ve had a brief pause lately to focus back on our team & what our strategy for growth is. The “design team” at SPARC has been in existence over 3 years now, with me learning to lead while building the team from the ground up. It’s been the most rewarding experience of my professional career to be able to foster such a unique group of creatives and facilitate achieving results.

As we’ve grown, there has always been a question of scale – how big do we let the team get? We’ve gone from three to as many as 14. During this process of growth we’ve been very careful who we hire and that the timing with business is correct. We’ve always had the intent of keeping the team as small & agile as possible, but still large enough accommodate the different types of work that comes in. We handle everything from User-Experience for enterprise software, to front-end development within a scrum team, to branding for our commercial clients. The designers we bring onto the team have to have the range to accommodate many different disciplines associated with “design”.

This latest pause has given me time to research a little more about the term “insourcing” and what it means to lead an in-house design group. While our team is more oriented towards software development & UX than in-house “creative services”, I found a lot of good gems in this article by the Chief Creative of Capstrat.

The reason companies in-source are pretty easy:

1. To save money. The simple, traditional in-house view: value = cost

2. To better control an organization’s image… and to save money The insource perspective: value = cost + brand + expertise + familiarity

Couple other great thoughts about the value of insourcing, many of which helped us successfully launch products such as Teamphoria in a short time:

Insourced employees create value because they:

  • Have a personal commitment to the greater purpose of the organization
  • Earn the trust and confidence of executive decision-makers
  • Understand key business drivers
  • Know the culture and can facilitate faster decision-making
  • Aid in speed to market

The last element of the article was the subject that has become my new passion of late, leadership:

The perfect internal creative leader:

  • Fosters a safe creative environment.
  • Knows when to take risks.
  • Has a sense of urgency
  • Is a spotlight-shunning consigliere.
  • Has high standards and a strong moral compass
  • Is a tireless evangelist.

In the very beginning, our team focused a ton on growing SPARC’s brand and image. Since then we’ve gotten an amazing advocate for our brand in Chad and move towards focusing on designing user-experiences for our clients. We’ve moved from an “overhead” services-focused team towards a billable asset to the company. Some level of design is included in every contract we work on. And design as a competency has top-level visibility within our organization.

To sum it up, as Adobe and Fast Company just pointed out, every designer is happiest when they know they’re fulfilling a need. Thanks for reading! 


The career of a modern designer.

finding direction

Sitting in a kick-off meeting, little tedious, sometimes steals your energy. Simultaneously reading email, IMing, listening to the client, giving feedback. Occasionally thinking how lucky I am to be in this room, in this conversation, & what/who we’re designing the software we’re creating.

Don Draper now builds software for a living.

Clicking through the email subscriptions and discovering a conversation about why they’re doing software vs. advertising. nice. These are the small points of validation when you think your life/career works more like a series of winding rivers, and less like a decision.

There are some great gems in this article about WHY software needs design. & how people with creative backgrounds can influence in a positive (designed) way that people interact with software. Smaller software tailored to the user, not enterprise. Making it technically “work” is no longer the need, making it usable is now the hard part.

“…Charles Phillips, puts it: “using enterprise software sucks.” It’s ugly. Cumbersome. Difficult to use. And impossible to love. “When engineers started to build these incredibly complex systems in the early ’90s, their biggest concern was: how are we going to make it work?” …. Now that business technology can deliver those basic user needs, it’s time to ask: How can we make business software work beautifully?”

Great food for thought for those of us who get up in the morning sometimes not knowing what the day brings, but feel purpose & drive towards a longer goal. Making things work beautify is the same in User Experience as it was in Advertising. When it works, you know it.

Creating an “Architecture of Participation”

design team tabletime at sparc

This past Thursday I was fortunate to hear Bill Taylor of Fast Company speak at the Charleston Chamber of Commerce annual event. There were a lot of components to his talk that sounded like the culture we’ve created Sparc. The phrase that caught my attention was the “Architecture of Participation“. There have been many times that I’ve thought of gathering the right people in a room as being an “architect” of people. My friend Taylor seems to be an expert at that. Or when my developer buddy Josh “architects” a solution by knowing what technologies play well together & essentially get shit done. This type of “architect” means as a leader, you facilitate problem solving by leveraging your team for the solution. That’s why we have a team, right? I think we were already doing this well, but sometimes having a word for it helps bring these quiet practices to light; formalizes them.

What interests me in the Architecture of Participation is how it calls out a leadership style I’m very comfortable. Traditional leadership has relied on the leader to identify & solve a problem on his own, then project the solution onto the people below them. The concept of leadership through participation means that rather than working in a vacuum, I can leverage the smart people around me. In the end, they’re typically the ones implementing the solution – this helps them “own it” as well. The Architecture of Participation simply means I facilitate the conversation & then let people be good at what they are already good at. Coming from a creative background, we (my team) is already skilled at working as a team – nothing new here. Learning & creative process intentionally leverages diverse skillsets, so why not problem solving on a leadership level?

I moved forward w/ a plan this past week to create “advocates” within our design team. Motivated individuals who can help lead the team in one aspect of design. This scales me, and offers the opportunity for these smart people to own a focused element that we need as a team. The advocates focus on aspects such as design quality, user experience or front-end development. Things our team need, but I can’t always facilitate the conversation 100% of the time on.

It’s a great thing to work with talented people. By creating an Architecture of Participation, we enable more creative solution & allow the smart people we work with to scale the team as a whole.