The shift from designing and building full screens to reusable components has begun, and it’s not just for small startups looking to be nimble and quick. Enterprise applications, often considered to be large and slow moving, should take note of these modular concepts to embrace cost savings, ease of maintenance, and speed of development.

Modular design components help break a product down to it’s base level to create a cohesive product for a user. This architecture reduces duplication of development efforts and eases the burden on QA. …

Well, duh.

A Dark Pattern is a user interface that has been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.

Tricking users isn’t a business model. You should care about your users–not just see them as money making machines of opportunity.

This extends outside of user interface and digital products — this also occurs in brick and mortar service based businesses — commonly found in globo gyms and corporate communication companies. …

Anyone who has been at the helm of a project redesign knows that even the simplest of changes can bring about many internal conflicts. This is exponentially more difficult in large scale enterprises when working through a responsive redesign project.

Responsive redesigns require organizations to rethink their existing processes and let go of preconceived notions of how websites are structured and built. Responsive projects, when done correctly, force organizations to prioritize their content and features based on user needs. This can cause political rifts amongst project stakeholders who may feel slighted due to their content being reprioritized.

Responsive redesigns also require developers to think differently about how they build sites. Developers can be reticent to change their processes. Developers need to focus on performance, the quality of the experience on all devices, and building things in a way that utilizes progressive enhancement. …

I co-host Design, Build, Test, Repeat with Eric Bailey , a podcast that discusses design and building user interfaces for web applications.

Shameless plug; our first episode, 00 Introductions, can be heard below:

A few things I’ve learned from preparing, recording, uploading, and setting up the podcast:

Prep work

Eric and I wanted to keep our podcast fairly informal, so we created a rough verbal outline of things to chat about before the show. Due to this, our preparation work was fairly minimal, as our conversation is natural and not scripted. …

The future is here.

No longer do you have to rely on FTP or manually pushing code. This makes development life so much easier. You can run automated tests, ensure QA has the latest versions, make smaller iterations with greater ease, and get your code to production faster than ever before.

If you’re still relying on manually deploying files, now is the time to change.

Static Site

Running a static site — try Github pages. Github gives every user and repo the ability to host a site. If you’re using the user sites, create a repo called

<username>.github.io

and every time you push to `master`, it’ll update the site automagically. …

Starting a new project.

You begin thinking of all the wonderful things you’re going to design and build. All the interactions and features; the in-person user testing and A/B testing; the workflows and models; the new technology stack and style guide. It is a wonderful and amazing time.

Then, just a few short weeks later, the repo is a disorganized mess of oddly named branches from various developers. The feature tickets from the sprint are filled out differently, based upon each Manager’s writing style. Pull requests range from being empty to three page novels. Folks constantly asking the whole group in Slack for the staging URLs. Standups that take longer than 10 minutes, because people like to talk. Design mockups ending in arbitrary version numbers with the word, ‘Final’ appended to it; before that too is versioned. ReplyAll emails asking for help on a bug without a screenshot, OS information, or steps to reproduce said bug. …

Finding users for user testing, isn’t always an easy task. Companies with existing users can send out emails, send a tweet or may already have an established user group. What if your product doesn’t exist yet, and therefore doesn’t have any users? You’ll have to try and find potential users. How the hell do you do that?

Task Based vs Product Based

Try using a Craigslist post. Ask a series of questions that help describe user tasks that you’re trying to test and solve. Don’t mention specific applications, instead ask task based questions. If you were working on an email based product, instead of asking, “Do you use Gmail everyday?”, ask, “Do you send emails to 10 or more people a day?” or “Do you spend more than 1 hour a day responding to emails?”. You can tailor these questions to reach the level of user you’re looking for. In addition, offer a $100 gift card as payment for the user’s time. …

Product Development is expensive.

Yet some clients want to jump right into building a feature. Without validating the User needs–requirements are written, sent to Development, and pushed to Production (with a lot of additional steps in between).

That process costs a lot of money.

Features should be validated, prototyped and tested before being built for Production. Not only for a better User Experience, but also for a greater monetary return on the Product lifecycle. Every dollar invested in User Experience yields a return between $2 and $100 . …