I’ve been weight training for almost a year now. All my friends, family, and in fact, even I am surprised at my willingness to wake up early to go to the gym, consistently for a year now.
One of the primary reasons I’ve been able to make it a habit is because I’m following a progression routine. I look forward to making progress every session, to lifting more weight than I did last week.
That also backfires when I take a break for a couple of weeks. I know that I’ll have to drop the weights and start lower. That feeling of moving backwards is terribly demotivating.
It also applies to the exercises I add to my training. I hate adding exercises that I won’t make progress on. That’s one reason I haven’t incorporated running into the routine. I haven’t found a decent system of defining running progress in my limited gym time.
I don’t know when I will get there but I’m shooting for a 300LB squat this year. It’s a long way away but it’s the weekly progress that makes me keep going back to the gym.
I feel like I’m creatively burnt out. There’s only one way out of this – pick a new medium and start over.
As I was dusting off this blog, I realized I’ve done this before. This blog has a hundred plus articles. When the hell did that happen? Turns out this isn’t my first creative burnout.
I want to expand this blog this time around. As much as I love user experience-ing, I love working out, sitcoms, boardgames, zoning out, any chocolate dessert equally, if not more.
I love personality quizzes and every single one I’ve taken tells me I’m a ball of emotion. I need to keep verbalizing these emotions or they drive me nuts. I love my journal for this stream of consciousness writing, but it’s a whole other ball game when I know my thoughts are on the internet accessible to anyone. It forces some creative constraints on my thoughts, forcing me to think deeper about what I’m writing about.
I want to write here every single day for how ever long I can. My gut tells me it’s going to help my creative soul and make me a fountainhead of ideas.
I am fortunate to be working with skilled designers, designers who love collaborating, are great at what they do, and most importantly, designers who know how to lead. Recently, I have been thinking a lot about how ambiguity affects design. Specifically, how designers are often expected to come up with magical solutions to amorphous problems.
Writing a design brief is tricky business. You do not want the brief to be so specific that you are effectively reduced to a computer executing a piece of code. You do not want the brief to be so broad that you do not know what the end result looks like and the designers spend most of their time running around like headless chicken.
I believe that a good design leader helps other members of her team navigate the ambiguity of a design problem. Of course, that’s what a manager does, but I think this is one of the core skills of a design leader. I rate it high because ambiguity can have a severe, detrimental effect on the design team.
A poorly defined and constrained design problem can demoralize an entire design team and cripple their productivity. Sure, the proactive designers will tread down their own paths and try to create something, but as soon as they realize that the end result of what they are making might not matter, they will lose their enthusiasm fairly quickly.
A good design leader does the hard work of taking an ambiguous problem, placing constraints around it, and setting goals for the design team. These constraints can be artificial and can change fairly often. But, the design leader needs to set clear expectations and communicate this flux to her team.
Ambiguity can kill a design team. The design leader’s job is to fight through and figure out the ambiguity for her team. At the very least, she needs to set meaningful interim goals to keep them motivated and productive.
A lot of design is just thinking through the several edge cases a product would be subjected to. As a designer, your responsibility does not end at defining the vision of the product. You need to think about, talk through and visualize all the ways a user might use the product.
Of course, you cannot account for every single edge case. There will be some things you fail to account for and it will result in a slightly negative user experience. As a designer, you need to constantly comb your product to discover these unaddressed problems.
For example, Sumo Logic often comes up short with error messages. Error messages are specially tricky. They are the unsexiest part of user experience design and accounting for every single error condition can be a daunting task. Luckily, they can also be some of the easiest components to fix. It’s easier to fix copy than functionality.
I think it’s more valuable to define a process to fix these issues than go after them whenever you have time. Maybe, it’s the responsibility of designer in charge of a feature to do a thorough comb after the feature is developed. Maybe, the UX team schedules one day every month to collectively comb through the product, catch, document, and design for these bugs. Maybe, you assign a person to collect these bugs and slowly drip solutions into the product all the time.
I have been working in the industry for almost 3 years and I have a Master’s degree in HCI. It’s surprising that I still think about what skills make for a good interaction designer. Some of my friends are interaction designers, I read articles by interaction designers, I work with designers. I think I have a vague idea of what skills make for a good interaction designer.
This is an evolving list. I’ll keep adding it as I become more aware of what I do every day.
I think Interaction Design is not as craft heavy as some other design disciplines. As compared to say, graphic design or fashion design, interaction design tends to be more strategic. What I specifically mean by that is that interaction designers create fewer drool-worthy artifacts. Interaction designers have to be primarily skilled at translating the ambiguity of product requirements and user pain points into tangible product flows.
Interaction design tends to be more strategic… (they) create fewer drool-worthy artifacts
A product flow is a sequence of states in a product. Better yet, it’s a conversation between a user and the product. Interaction designers make the product a reality by making that conversation tangible and real.
Prototyping has to be the defining activity of an interaction designer’s job. Interaction designers create prototypes to convey their ideas. A prototype is an artifact that mimics the behavior of a product. It’s an artifact that fools the user into believing that he’s interacting with the real product. The goal of a prototype is to replicate the experience of using a product cheaply, and quickly.
I use a simple rule of thumb when creating prototypes. If you feel miserable about throwing away a prototype you’ve been slogging away on, you’ve spent too much time and effort into creating it. A prototype needs to be quick to produce and test. I would probably rate the ‘speed’ higher than ‘fidelity’ when it comes to judging the effectiveness of a prototype.
There are a whole bunch of tools out there today that let you prototype for almost every device and use case. The tool you end up choosing depends heavily on the problem you’re solving. A three screen sign up flow for mobile could be replicated easily with Invision and Sketch. Need some animation there? Try Pixate. Need to replicate a multi-state, multi-screen shopping experience? Try Axure or UxPin.
For an interaction designer, storyboarding is almost as important a skill as prototyping. I want to get better at drawing people, faces, and objects just so I can draw out a few panels depicting a user journey. A 3-6 panel storyboard has immense power. If that sounds hokey-pokey, try to build consensus around an ambiguous problem among 6 stakeholders across multiple departments and you’ll see that power in action. It’s much easier for a group of people in a meeting to process a 6 panel story than 50 lines of text describing those panels.
A storyboard can come in many forms, but I’m specifically referring to sketching out the interaction between users and a product in a given context. The most effective way to setup a 3-panel story is in the form of context, problem, resolution:
Rohan is traveling back home from work
He is bored and he wants to be productive
There is a dearth of prototyping tools for web based products. A new prototyping tool emerges in the market every day, but most of these tools are focused on mobile prototyping. I understand why these prototyping tools focus on mobile apps. Mobile is still a relatively new medium and everybody is still figuring out the best way to work with it. By focusing their prototyping tools on mobile apps, software developers are trying to corner a developing market.
Axure is an un-sexy product. The interface looks like it’s from the late 90s. It feels bulky and bloated to use. There are too many check boxes, buttons, there are too many decisions you’re forced to make. It’s not an easy product to master. Mobile designers want their tools to function like a mobile app – everything should be less than 3 clicks, the interface should have minimal text, you should have limited options with you to prevent “cognitive overload”.
I wish there was a tool simpler than Axure that let you prototype complex web applications. There is a need for a tool that basically lets you do what HTML and Jquery do but with a GUI attached to it. What it really needs is the ability to let people comment on the prototype. UXPin does an almost decent job of solving this problem, but I hate the fact that it’s a browser-based tool and that you cannot zoom into the interface. I just cannot get accustomed to the idea of “working in the browser”.
I need a mac based prototyping tool for the web that also solves the problem of sharing like Invision and collaboration like Sketch. Yes, it’s super easy to collaborate between designers using Sketch.
We have resumed interviewing for the position of a Senior Interaction Designer. When I was interviewing last year, I remember being clueless about how other designers interviewed or why I got rejected at certain places. I didn’t quite understand the difference between a senior and junior designer. I didn’t quite understand that a cultural fit with the team is as critical as the skills you bring to the table.
Speaking about cultural fitness, I wondered how hard that could be. I mean, who isn’t polite, funny, and fun in an interview, right? There was this one time when this candidate was eating lunch with the team and chatting with one of my colleagues. My colleague got distracted for a minute and turned around to talk with someone else. I think this candidate got annoyed at being cut off mid-sentence and sharply called out my colleague. The funny part was that no one on the table caught it consciously but when my colleague brought it up during the review, everyone remembered that incident.
It’s funny how subconscious impressions work. I struggle to remember an interview where the entire review team didn’t have a similar opinion of the person interviewed. There was this other time when I was interviewing a candiidate and talking with him was like pulling teeth. I couldn’t quite put my finger on why that was happening but the conversation wasn’t as fluid as I would’ve liked. This person had fantastic technical chops but I felt they would have a tough time communicating that to the rest of the organization. Design is as much about selling as it is about creating something in Sketch. Guess what everyone thought of this guy – that he was tough to talk with.
I had no idea how these seemingly insignificant things make a big impression on the interviewers. I’m sure there are other aspects to the design interview process that I haven’t considered yet. I haven’t had experience sitting in on design exercises and I haven’t ever grilled a candidate about their portfolio in depth. What I do know so far is that, specially design interviews, are as much about a cultural fit with the team as about design chops. Go forth and culture hard.
This was an unexpectedly long hiatus. I was visiting family in Philadelphia all of last week. It was a beautiful historic city with compelling stories written all over the old crumbling buildings. Honestly, that is based off of pure assumption and first impressions because I didn’t read any of those stories. The only thing of consequence I learned about Philadelphia history was that the Liberty Bell was super important and this city was once the capital. I spent the rest of my time there riding a bike, strolling, and eating.
I don’t have a good reason for not continuing to blog while on vacation except that I didn’t feel like it. Now that I’m back and on the train on my way to work, my hands started writing automatically. How powerful are habits!
I’m going to switch my writing schedule here. I think I’ve accomplished a milestone with this blog, I’ve made it a daily weekday habit. I have confidence in my ability to produce something design related at a moment’s notice, every single day. Milestone one check.
The next milestone would be to write blogs that are more thoughtful, considered, and fresh. This means taking more than 30 minutes everyday to write the blog. I have to think more about this but I think writing twice a week would be a better schedule. It would give me enough time to write, edit, and hopefully, promote the articles.
I wrote about my “minified personal design process” yesterday. Theory is great, examples are better. Unfortunately, I cannot write about the projects I’m working on at Sumo Logic. We are solving some tough design challenges and helping our Devops users sleep better at night.
Let me try using a non-work example:
Rohan recently deactivated his Facebook news feed. That feed was his go to source for information. He follows several blogs on Feedly but doesn’t enjoy consuming content there because the user experience is below par. He likes the idea of Twitter but hasn’t been able to adopt it completely. He thinks Flipboard has a great mobile experience but the process of managing sources is just miserable.
Rohan wants a web application that let’s him collect all his favorite information sources in one location. He wants a Facebook news feed like experience where he can just pop open the screen and browse content he’s interested in without having to poke around too much. He values the ease of managing these sources.
This is not a real world scenario. Assume people are paying for this service and you don’t have to worry about monetization or compensating the information sources.
To start off, let’s begin with focussing on Rohan’s onboarding experience i.e. how does Rohan get started with this service?
Coming up next, user stories and initial task flows.
Sometimes, when designing, it feels like you’re free falling and you’ve got nothing to hold on to. Having been through this process several times before, I know there is light at the end of the tunnel but it would be great to have personal markers to ensure that I’m at least falling in the right direction.
Of course, you want to proceed from quick and dirty low fidelity mocks to higher fidelity comps, validating the design at each stage. More importantly, you need to take intuitive leaps between each stage because each stage brings new constraints, and problems to light.
Here’s what my minified personal design process would look like –
Write a succinct user story
Write a step by step task flow
Sketch a flow with little boxes, key layouts in them, and connections between the boxes
Sketch 1 primary screen with key objects laid out, informed by information hierarchy
Sketch 2–3 screens or states around this
Move to the screen, use pre-made components, and create higher fidelity mocks
Use something like Axure or Invision to make a prototype
Wow that turned out to be more detailed that I thought. I’ll provide examples in upcoming posts.