The principle concept of weekly user testing is creating testing patterns that need testing today, easier. Instead of finding a pattern that needs to be tested, and then trying to schedule users for the test, realizing it’ll be about 3 weeks away, and then focusing on that 3 week deadline; you create a weekly testing schedule that allows for immediate testing and validation.

Test like we build — in small, iterative tests. Schedule the same half day block each week, and make it reoccurring. The project I’m working on, we’re currently testing on Tuesday afternoons. We spend most of Monday figuring out what needs to be tested and how to test it. We’ll create a simple script for the test, and test 3 to 4 users in 20 to 30 minute sessions. …


Image for post
Image for post

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.

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. …


Image for post
Image for post

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. …


Image for post
Image for post
Always Be Closing (https://i.ytimg.com/vi/Yz246_Pjjkc/maxresdefault.jpg)

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 .


From the beginning, we’re conditioned that failure is a terrible thing by associating it with negative outcomes. Schools tell us, “Fail this test, and you won’t advance into a better school”. This enforces fear of failure being a primary contributor behind not wanting to fail; instead of wanting to succeed. Not wanting to fail and wanting to succeed, are two very different thought processes.

As children, we are rarely told, “Do something, and when you fail, learn from that failure, and apply it to your next attempt”. Instead we hear, “Do something, and do not fail”.

We should be encouraging fast and small failures in our kids. Allowing them to understand that failure is okay, failure will happen, and to learn from failure. We should support fast and small failure, so kids can learn incrementally, without devastation, and without fear. They’ll understand that success, and wanting to succeed, is built upon learning from failures, and not from being afraid to fail. …

About

Mike Kivikoski

#UX #UI #Designer, #Developer, #Educator, #Speaker — Intro to #Development @OReillyMedia http://oreil.ly/1mI8FqY — Evolving #Web #Apps http://bit.ly/1OEyT7M

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store