Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

6 Common Problems With The UX Process, And 6 Solutions!

How robust is your user experience design process? We all have our favored methods and techniques, but the general process is similar: Conduct research, prototype, then present to stakeholders and users.

We’ve delivered projects successfully, rectified problems and honed our ability to deliver in different scenarios. However, we all know that every project is unique, and every once in a while something will take you by surprise.

Every once in a while, something will take you by surprise
Every once in a while, something will take you by surprise.

Over the last three years, I have been the lead designer on a large web application project in the legal sector. When I started working with the client in 2011, the requirements document was 100 pages. Since then, millions of pounds have been invested to design and build this highly ambitious, game-changing piece of software.

Further Reading on SmashingMag: Link

In this article, I’ll discuss the variety of challenges that we faced and how we eventually overcame them. Many of these learnings can be applied to enhance the user experience design process in smaller projects.

Problem 1: Facing Up To The Feasibility Link

With a small project (such as a simple website), going right into your wireframing tool of choice and making a quick interactive prototype to communicate your ideas to the client is perfectly acceptable. In a more complex scenario, many of us will map out user journeys5 and perhaps define personas6 before getting to that stage. This is nothing new. But what happens when the user journeys are so complicated and their number so high that the feasibility of the project is uncertain?

In a web or mobile application, you might have many different workflows that cater to users who have many different roles within the system. Yet despite the complexity that may exist in some parts, we know that large chunks are likely to be feasible — the logging in, the registration form and the navigation elements that we are all so familiar with.

When wireframing, I have always taken the logical step of following the user’s journey, starting with the landing pages and then through to the ultimate goal. However, with so much ground to cover, cooking the side dishes simply doesn’t make sense if the main course is unachievable.

Feasibility studies in business often focus on market conditions and technical constraints, but determining whether a sound user experience (UX) can be delivered is just as important. If it is discovered down the line that the project is too ambitious, then a lot of effort might have been wasted.

Solution 1: Tackle the Challenging Parts of the UI First Link

During the discovery phase, identify the most challenging aspects of the user interface (UI), and then create wireframes for those particular parts. This fits in perfectly with familiar UX practices, such as mapping out the different types of users and their journeys through the system.

Addressing these challenges first will not only help the design progress faster, but will also help you estimate how much development time is needed.

Let’s consider a hypothetical scenario. You’ve been asked to design a website containing a feature that enables a user to invite people to design a friend’s birthday card, together in real time.

Consider the following journey:

A hypothetical user journey7
A hypothetical user journey. (View large version8)

Now let’s identify the challenges. We all know that the log-in and invitation parts are feasible. Even if we haven’t built it ourselves in the past, we’ve seen similar things in action elsewhere.

Having a group of users collaborate in real time? That could be chaos! We need to prototype that part first, otherwise the whole journey will be void. You might also want to consider the motif of the project9. Perhaps the big challenge is the motif, or perhaps it is something simpler. If that’s the case, then you should definitely include that in your early wireframes, too.

To summarize, while the question of feasibility can be difficult in big projects, we can answer it more quickly by creating wireframes for the difficult parts of the UI up front.

Problem 2: Presenting An Incomplete Journey Link

This problem is a side effect of the first solution! How do we account for the gaps we have left behind? To validate the work done so far, we need to share it with stakeholders and potential users.

Even at this stage of the project — the beginning of a crusade that could last months, maybe even years — the “Wow” factor is crucial. We need to get everyone involved and secure their buy-in.

Solution 2: Tell a Story to Fill the Gaps Link

Continuing with the birthday-card example, this is how we could introduce the website’s concept to our stakeholders and potential clients:

The user would begin the process by logging in and selecting “New card.” Once they have selected their friends from a list, they must await a response. When their friends have responded, they all enter the editor together, and this is how it works.

This might sound odd, but it does work well. And it has additional benefits:

  • Rather than a lengthy build-up, navigating all of the unremarkable parts of the UI, we kick off the meeting with the meat of the proposed solution. By cutting to the chase, we ensure that attention doesn’t drift by the time we get to the important stuff.
  • Getting sidetracked in a wireframe presentation is common. Looking back at our journey diagram, imagine if we had presented wireframes for steps 1 through 4 and then got stuck in a lengthy discussion about which form fields are required in step 3. What we really want is feedback on step 5, so let’s get there early, while everyone’s mind is still fresh.
  • By doing this, we also cut down on meeting times, and you’ll find yourself able to conduct more workshops within the time available.

By telling a story alongside our selected wireframes, we gain all of these benefits and solve the problem of presenting an incomplete user journey.

Problem 3: Wireframing Software Has Limitations Link

How detailed should a wireframe really be? Many web applications have rich animations and subtle interactions that most wireframing tools and sketches cannot simulate.

In addition, wireframes cannot maintain state. For example, how does the layout change when an administrator is logged in? If it is an e-commerce website, what do full and empty baskets look like? We might want to simulate both of these states in our prototype.

Without state, our applications are useless. Yet no WYSIWYG wireframing tool that I know of simulates it effectively.

You might argue that, if we are going to build logic like this into our wireframes, then why not just build the thing to begin with? The debate is interesting. Perhaps one day someone will invent a product that can achieve this; until then, we must settle for other methods.

Solution 3: Go for Higher-Fidelity Wireframes Link

In the early stages of the project, identify how much complexity is involved in the user interaction. Could your idea be easily understood by anyone as a series of static wireframes? If it is not obvious, then you will save time in the long run by creating a higher-fidelity prototype.

Doing this early on might sound like overkill (it can be more time-consuming, of course), but it has benefits:

  • In a project that requires complex interactions, every movement of the mouse and stroke of a key can involve small details that make a big difference in the overall experience. An animated prototype is easier to hand over to a large development team, so that everyone knows exactly how the website should work.
  • The prototype will also make your vision clearer when demonstrating to users and stakeholders.

3A: Create an HTML Prototype Link

If you have front-end development skills at your disposal, then building with HTML, CSS and JavaScript could be a worthwhile investment.

This method has some key advantages. JavaScript enables us to simulate state, and many frameworks will help us quickly create subtle animations and effects (including jQuery and Scripty2).

The disadvantage, of course, is that the whole process could be more time-consuming. There is also the minor issue of browser inconsistencies, which is best left to trouble over later on in the project!

3B: Create an Animated Prototype Link

Animated prototypes are also a good way to showcase your ideas. My tool of choice for this is Adobe Flash. While some would say that Flash has had its day as a web plugin, it is still a rapid animation tool. Drawing things in it is just as easy as in any other graphics application, and animating is as easy as dragging and dropping. The output might require a plugin to be viewed, but it does bypass those pesky browser inconsistencies.

Plenty of other tools can do it, too, of course. Microsoft’s Sketchflow10 produces very smooth prototypes, and Adobe InDesign11 is also capable of producing animated interactions.

Here’s one that I made earlier:

An example of an animated prototype.
An example of an animated prototype.

Let’s apply the animation to our birthday-card website. We know that our collaborative tool will have a lot of movement (multiple cursors could be moving around the screen), and a static wireframe will not capture it properly. So, let’s think about the subtleties of every interaction and capture them.

One good example of this is that hovering over the arrow to turn to the next page will make the page rise slightly. In normal page-turners, we could make the bottom corner curl up, but here we are working on a cardboard product, so let’s make it more realistic!

Small details like this really do contribute to the overall impression on your audience, and they also give developers a more detailed visualization of what they need to build.

3C: Use Annotations Link

While animations help us bridge the gap of interactivity, annotations provide further guidance on application state. It’s a simple solution, but it works in many scenarios. Just make sure that you agree with your development team on a consistent format for annotations (for example, red box + red text = annotation), or else someone might build one into the application!

Annotations are a simple solution that provide further guidance on application state.12
Annotations are a simple solution that provide further guidance on application state.

The methods above are just three ways to overcome the limitations of wireframing software. Prototyping in UX projects is a vast subject, one that I constantly monitor as tools and techniques evolve.

The end of this article lists some resources that provide a good starting point. In the meantime, let’s move on to problem 4!

Problem 4: Wireframes Are Harder To Complete Link

With so many different sets of wireframes being created for each workflow in a project, drawing the line and proceeding into the realm of color and style can be difficult.

Discussions are held for the duration of a project, meaning that the landscape is always shifting. In a web application in which user workflows intersect, one small change can have a snowball effect on your wireframes.

You can’t afford to wait for all stars to align before moving on. It might never happen. We must also mind the client’s budget and advance the project to the next stage when the time is ripe.

Solution 4: Just Start Designing and Accept the Consequences Link

Deciding when to start creating design mockups (or comps) can be tough when the wireframes are still evolving. We know we can’t wait, though — developers need to develop and, more importantly, a product needs to get sold.

Once you have reached the stage where every workflow (or user journey) has been at least partially wireframed, start creating the visual style by mocking up three to four contrasting screens from across the project.

Working on wireframes and styles at the same time might seem scary, especially because clients often change their mind at inconvenient stages of the process. However, change is inevitable in a big project, regardless of the path we choose. So much work needs to get done. Stepping stones that you traversed weeks ago will have shifted (or even sunk!) by the time you get back around to them. Don’t lose faith; keep circling, and eventually it will settle. Never expect to get it right the first time. Embrace changes for the better and move on.

Switching in between can be beneficial, too. In many situations, adding colors and styles to a layout has actually helped me to make improvements that weren’t obvious when working with the grayscale wireframe.

So, if you are working on a set of wireframes that is constantly changing due to evolving requirements, don’t let it hold back the whole project. Get on with the visual style, and keep the project moving forward.

Problem 5: Communicating Behavior To Developers And Testers Link

We have our design comps now. We have clickable prototypes, animated wireframes and even annotations to communicate the application’s state. However, if you are working on a large team, you can’t always expect everyone to be on the same wavelength. In fact, the larger the team is, the trickier it becomes to achieve consistency in the overall project. As designers, our knowledge is the glue that holds all of the UI artifacts together, and sometimes we have to go the extra mile to pass it on to our colleagues.

Solution 5: Provide A Behavior Guide Link

Many projects (and indeed organizations) have style guides, but a behavior guide might also be needed to complement wireframes:

  • Feedback loops
    These describe the style, position and interactivity of elements such as error dialogues and success messages.
  • Components
    These describe items such as navigation, form fields and modal dialogues.

Take the grid-view component below:


In our guide for this control, we would include rules on behavior such as the following:

  • the appearance of the selected row (blue here);
  • keyboard controls (for example, up, down, Tab, Enter).
  • instructions for scrolling and lazy loading (including perhaps a loading spinner animation, or even pagination styles, as a no-JavaScript fallback)

Following the agile method, something like this might be built as part of a particular feature. However, by describing this as a behavioral element, the development team can treat it as a feature in its own right, implementing it once, with the intention to reuse it in conjunction with other features.

Problem 6: Predicting All Of This From The Start Is Not Easy Link

In an ideal world, the client would have an infinite budget, and we could deviate from the normal process as much as we’d like. However, we all know that this is not the case. In reality, the client has signed up for a predefined plan of action, which has been mapped against the estimated costs of the project.

In this article, we’ve presented a number of ideas that don’t necessarily fit into a typical UX process. So, how can we (or our project or account managers) possibly detail them when writing an estimate?

Knowing little about the detailed requirements of an ambitious project is especially difficult.

Solution 6: Honesty and Flexibility Link

As with any client relationship, the normal process has to have some flexibility. The client has to trust that, while we are following a plan of action, additional tasks may arise. It’s about honesty, both in the way we speak with clients and in the way we write our contracts14.

One of the best ways to ease the pain of this uncertainty is to provide estimates as a range. Instead of saying that a given task will take 20 days, say that it could take 15 to 25 days, to retain the flexibility we need.

In a big project, this can create a wide variation in the total cost, which might make a potential client feel uneasy. However, this method of estimation provides them with a best-case and, more importantly, a worst-case scenario, which will help them plan their cash flow more effectively. The client must have the budget to realize their ambition; otherwise, they will be less likely to taste success.

For more on estimates, I’d recommend reading “Stop Writing Project Proposals15.”

Conclusion Link

I hope you’ve enjoyed our mystical quest for perfection in the UX design process. In this industry, every new project presents tasks that have the potential to alter our perspective.

This article wasn’t written to provide a definitive list of essential tasks. While I think that these tasks would be very useful in many projects, my hope is that they will help you to think differently. Not all projects can be constrained to an identical process; we must tailor the process to fit the challenges we are facing.

Embrace (and plan for) the breakage of your design processes. When faced with problems, we learn more about ourselves and, ultimately, learn how to become better designers. Your UX design process should not always be a smooth train ride. Think of it as an off-road adventure!

Recap Link

  • Break your project into manageable chunks, define the user journeys, and then prototype the hard stuff first.
  • When presenting your wireframes, focus on the challenging parts of the UI, and tell a story to fill in the gaps. This will save you time and gain you more valuable feedback.
  • Animate and annotate your wireframes. Use little details to strengthen and enhance your proposed solutions.
  • Don’t wait for perfect wireframes to create the visual style. Get on with it, and embrace the crossover of changes between the two. Change is inevitable.
  • Document typical behavioral patterns and feedback loops to achieve consistency when working on a large team.

Further Reading Link

(al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17

↑ Back to top Tweet itShare on Facebook

Chris is the founder of Daymedia, a digital agency that has welcomed a variety of challenges for companies such as Volvo, Jet2, and Onzo. He has been working as a designer and developer since 2005, having started his career at Xerox Global Services. He is passionate about design, jaffa cakes, and helping local charities via CodeRaiser.

  1. 1

    Andy Birchwood

    May 7, 2014 3:27 pm

    By far the most common problem I encounter is UX designers who don’t do any research. Sad but true.

    • 2

      Yep I agree, I didn’t really mention research in the article (It’s a vast subject, and there are other articles that cover it far more comprehensively) but it is something I come across a lot also.

  2. 3

    Daniel Schwarz

    May 7, 2014 3:34 pm

    Brilliant article, very insightful, and definitely useful. However, I find the first 5 steps a bit redundant…although you do mention that in step 6. Probably some of my best ideas when building my site came after what I called “the final design” – in actuality it’s never the final design and I’m always tweaking it, and always looking for feedback. I think that’s the best way to build the best UI (for that I use, it’s really awesome).

    Of course it’s harder to make these tweaks if it requires a massive change in the core structure of the site, which is hen steps 1-5 are crucial. Thanks, and well done on the article!


  3. 5

    My preferred approach to prototyping is implementing HTML/CSS/Javascript via Bootstrap 3 and AngularJS. You can use the absolute basics of AngularJS to build a quick single page app, and thus track state across multiple pages. I find I can mock up an entire workflow very quickly and do real user testing against it.

    In the end it’s faster (for me) than any other approach, with a bonus of potentially usable markup in the end (if the project is bootstrap based).

    • 6

      Andy Blount

      May 27, 2014 9:35 am

      I recently started doing a very similar thing with great success. I used knockout and sammy.js to create a single page app in the same way that you did with angular.

  4. 7

    Rob Schlegel

    May 7, 2014 4:53 pm

    Regarding #3, I find Axure works very well.

    • 8

      Simon White

      July 16, 2014 9:56 am

      I second that, Axure can create complex states (especially version 7) with dynamic data sets and variables that can be passed from page to page. You can even simulate search results with a real data set from Excel. See repeaters (

      The only drawback is that it gets even more complex, and sooner or later you might be better doing HTML/CSS/JS instead, where some components might end up being recyclable. With Axure you have to take the hit, the final product may look very nice but will have to be recoded from scratch afterwards.

      That being said, sometimes high def prototyping can save time even if you do have to build everything again. Depends on the project.

  5. 9

    This is the way we’re doing our current project. I wireframed out the hard part first, and worked backwards. The challenging part is not foreseeing specific user stories, and then having to backtrack and add them into the project. This is the first time I’ve done it this way, but the project isn’t over, so I’m sure the life lessons will come rolling in after we’ve delivered the completed application.

  6. 10

    I think another good solution to Problem 5 is creating Use Cases for developers and Test Cases for testers. What do you think?

    • 11

      Yes, definitely :) Whilst writing this article I actually worked with a business analyst who took care of this on the project we worked on.

      The requirements were huge, so there were a large number of scenarios to cover, and we constantly had to iron out inconsistencies between the wireframes and use cases. This certainly helped refine both the wireframes, and the use cases themselves.

  7. 12

    Curt Alupis

    May 8, 2014 12:58 pm

    That sounds like a hugely ambitious project Chris, sometimes UI projects can just be too big…

    • 13

      Indeed. Although we did get there in the end :) It was a huge effort from all the team to get it to the stage where it was ready for development. The problem that the project is addressing has been well known for some time, but perhaps the scale is one of the main reasons that no other (good) solution exists as of yet.

      Would love to say more but I am under NDA :)

  8. 14

    Thanks for sharing your experiences in this informative and practical article.

    A huge benefit to me is being able to work with a product owner and lead developer who can grasp proposed UX concepts from sketches.

    I initially sketch high level lo-fi concepts and work quickly to refine and iterate on these sketches. Core functionality, UX strategies and UI behaviours are all discussed and analysed before I even look to my wireframing tools.

    In section 4 you mention working dually on wireframing and UI, this is something I find really helpful, maintaining both aspects of the same project in tandem. Scrum facilitates this design workflow wonderfully as being able to bring all activities in a designers workflow to bear in a single sprint helps improve design processes.

  9. 15

    With #3, I recommend using Axure

    Wireframes in Axure can pass state across pages, and can also be set to offer different interaction cases to the viewer.

    For example, the username entered into the login form can be carried across and inserted into the [username] element on the following pages, and the [login] button when pressed would popup two options of “login success” and “login fail”, letting the viewer choose which outcome to show next.

    • 16

      In addition to having the ability to make the wireframe stateful you can also make it device aware with Axure’s new feature. You can wireframe out a mobile and desktop site on in the same wireframe.

  10. 17

    Matthew Trow

    May 12, 2014 6:01 pm

    Wire framing – I tend to prefer 3A, the html prototype.
    Having used Axure and Balsamiq extensively in the past, I’ve found adding and editing interaction can be overly complicated.

    With html frameworks, the start of the wireframing prototypes is definitely more time intensive, but the benefits start to pay off later in the process.

    A few benefits:

    * Programmers can use prototype HTML/CSS/JS code as a framework whilst the rest of the team concentrate on the UX build. The clear benefit is having the team all working together at the same time, with programmers being able to feedback areas where the prototype needs work. This works best on projects with tight deadlines.
    * Sometimes, a fair chunk of the prototype code can end up in the build with only minor modifications.
    * Developers are creating wireframes in the language of the web, rather than an approximation of it – often this serves to flag up issues that would otherwise only be discovered later.

    Before any of this is done, however, there’s no match for quick sketches – good old pen and paper is an essential part of any wireframing process.

    • 18

      I agree… axure is a good tool, but for simulating state I much prefer to go down the HTML+JS route :)

      I’m also a big fan of the pen, and I tend to share a whiteboard folder with the team containing photos of all our sketches and scribbles. Very useful for looking back and keeping mental bookmarks, it often helps me recall detailed conversations I have had with colleagues and clients.

  11. 19

    Going deeper and deeper into the software making I can only say that good ux designer will replace webmasters and graphic designers, but there are very few good ux designers. Don’t do wireframing, make actual project instead – it is cheaper and you will get better effects.

    • 20

      Different things work for different people, that’s what makes the subject so interesting :) I still think wire framing has it’s place, even if it is just to get the basic layout bottomed out before building a HTML prototype.

      It’s always going to be quicker to drag elements around than write code, no matter how fast you can type, or what frameworks you may have at your disposal.

  12. 21

    Glenn Veugen

    May 14, 2014 4:30 pm

    Interesting read. As I am not in a leading position yet, not all points are very relevant to me yet. But I can definitely relate with issue #5, as I am struggling with it as well now. Within our organisation, we are having difficulties aligning with our development team, which is located at the other side of the globe. I don’t even know how big it is, and find it hard to create one solid approach for writing documentation. We are still exploring and moving into the right direction, but just wanted to say I can definitely relate, and I feel it becomes even harder when you’re working with remote and multi-cultural teams. But the challenge is what keeps our jobs so interesting ;)

  13. 22

    Great article. As a developer who has only recently been using more structured UX design approaches, this really validated how I’ve been going about projects lately.

    For times when HTML/CSS/JS prototyping is relevant and communicating behavior is important, I use Fenix Web Server ( It serves simple web pages, but it also has a one-click option to temporarily share your computer as a public web server. I primarily work remotely, so it’s nice to click a button and immediately share a link. For me, it simplifies the process of demonstrating a prototype/example with real code. Some things, like attention seekers, are just easier to code than to mock up in tools like Balsamiq. Sharing this kind of work has been straightforward with Fenix.

  14. 23

    Brooke Browne

    May 16, 2014 9:49 pm

    I’m a huge fan of – it allows for states and screens with every interaction type you can think of. I’m currently doing two projects, with one having a very substantial dynamic form that spans 4 screens, each screen has various states to account for all the variables with each selection. Pretty awesome.

  15. 24
    • 25

      Markus Seyfferth

      May 20, 2014 10:16 am

      Thanks Nico, can you please try it again? Can’t find any 403 error here.

  16. 26

    Use Axure for #3 problem. It is a great tool for prototyping.

  17. 27

    Glad to see higher-fidelity wireframes mentioned! Its really a great approach that will become standard in my humble opinion.

  18. 28

    Smashing magazine seems to repeatedly publish articles about UX by (no offense) people with a narrow point of view who are clearly out of touch with the way most ux professionals work. The lack of a mention about Axure for example is a case in point. Sorry, but get a bit tired of people preaching about how to do UX when they really are designers, coders, project managers, marketers, etc and have tacked ux onto their skills set this year because it is fashionable.

    • 29

      No offence? Really?

      I am a designer. I have been a designer for over 8 years. Smashing Magazine do a great job of validating all their articles.

      I didn’t mention Axure, but I also didn’t mention Sketch, Antetype or any of the other 100s of tools that are available. The omission of one tool is not a good basis for criticism of my skills.

      So… who is the narrow minded one here again? ;)

  19. 30

    Richard Verne

    June 19, 2014 4:50 pm

    A good article and I agree with many of the comments regarding Axure. Personally, I prefer to leave coding to the coders as they know more and work more efficiently than i ever could in these situations. That said, I always, always, always start by defining users. Stakeholder interviews, analytics reports (if available and/or applicable), weblogs to review internal searches, free keyword search trend reports from Google, website or application analogs to ID common design patterns and anonymous LinkedIn searches all help me build assumption personas. Each persona includes an idealized scenario sprinkled with actual tasks and suggesting a task flow. All this involves are words, pictures and light diagramming. It’s fast, cheap and often results in uncovering unknowns that can tank a project if unaddressed early on. Plus, the team is literally on the same page about who will use what they build.

  20. 32

    You made a good point about high fidelity prototypes. Any app which has more than Login and Home screen, should go for high fidelity prototype to solidify the idea into seemingly movable app parts. For me SketchFlow works great because navigation, transition, and animations in pages are easy to implement. Components come handy and you quickly realize you are making more components than pages and green and blue lines go into a lots of cris-crosses. In a prototype I am working on, there are 14 pages and 35 components, and I am midway completing the whole set of functionality. Feedback and annotation are also easy to implement in SketchFlow. Beautiful part is ability to jump into XAML code and make changes quickly if Design surface does not support the functionality. For low fidelity prototypes, Pencil is a good option.

  21. 33

    The problem I usually face when working with UX designers that want to prototype something is cost. The cost of prototyping is often only marginally less than building out the feature.

    Do you suggest prototyping with real people using wireframes?

  22. 34

    First off, thank you,

    Needless to say a brilliant article, and well written. Lately I have been struggling with two things, (1) an outstanding visual design, without any gap of creativity and innovation (2) an outstanding user experience, without any confusion.

    It seems as though, the more creative and innovative a product the more serious we have to take the thought process you clearly articulated.

    ‘Creating Wireframes for the most difficult aspects of the UI first’, is something I have done before but never considered as important until you brought it into my attention.

    I liked how you said ‘could your idea be easily understood by anyone as a static prototype?’ it is often difficult to make an idea clear as water while still holding a creative out of the box element, this I think is the balance one should strive for, clarity and simplicity when a product is shown.

    In conclusion, what I agree the most here is to create ‘higher-fidelity prototypes’ this is the goal one should aim for, and work tirelessly to achieve.

    On another note, I could not agree more with annotations and behavior guides, that is something I preach and practice when designing.


↑ Back to top